Clearing the way for Ether 2.0, V-God proposes a new backward-compatible approach to Ether

V-God has proposed a pre-compilation method to solve one of the biggest problems facing the current backward compatibility of Ether.

Clearing the way for Ether 2.0, V-God proposes a new backward-compatible approach to Ether

One of the challenges facing backward compatibility in the current Ethernet design is that access to blockchain history requires EVM validation of Merkle proofs, which also assumes that the blockchain will always use the same format and the same cryptography. Future sharding designs increase the importance of this even more, as Rollup fraud proofs and proofs of validity will require pointers to sharded data.

This article proposes a more future-proof approach: instead of requiring proofs of history and sharding to be verified in EVM, we can add pre-compilation that performs the abstract task of verifying specific types of proofs. If the format is changed in the future, the precompilation logic will automatically change. Pre-compilation could even have conditional logic for verifying one type of proof for pre-transition slots (slots) and another type of proof for post-transition slots.

Historical block data
def verifyHistoricalBlockRoot(
slot: uint256,
value: bytes32,
proof: bytes
)
This precompilation will try to interpret the proof in one of two ways.

If this proof is empty, it will directly check if the value is a historical block root saved in the correct location. If the slot is too old, it will fail.

If this proof is a Merkle branch, it will verify it as a Merkle branch based on the correct entry in history_roots

def verifyHistoricalStateRoot(
slot: uint256,
value: bytes32,
proof: bytes
)
Verifies the state root, using the same logic as the root of this block.

def verifyHistoricalStateValue(
slot: uint256,
key: bytes32,
value: bytes32,
proof: bytes
)
Verifies the value in the history state. This proof consists of three elements.

state root

A proof that the state root is correct

Patricia or Verkle or other proof that the value is actually located in the location key in the state tree (this assumes that the proposed scheme of mapping all account contents to the 32-byte key is permanently stored)

def verifyHistoricalTransaction(
slot: uint256,
txindex: uint256,
tx: bytes,
proof: bytes
)
Verify that tx is actually in the txindex of the block for the given slot. The proof reads as follows.

blockroot

Proof of the correctness of the block root

Prove that the given tx is actually a transaction at the given location

def verifyHistoricalReceipt(
slot: uint256,
txindex: uint256,
receipt: bytes,
proof: bytes
)
Verify that the receipt is actually a transaction received at the txindex of the given slot. The proof reads as follows.

blockroot

Proof of the correctness of the block root

Proof that the given receipt is actually the receiveipt at the given location

Slice data
def verifyShardBlockBody(
slot: uint256,
shard: uint256,
startChunk: uint256,
chunks: uint256,
data: bytes,
proof: bytes
)
proof data = body[32 * startChunk: 32 * (startChunk + chunks)] , where body is the body of the given slot for the given slice. The proof will include.

Proof of Kate proof for a subset of blocks

If the slot is too old (more than 128 epochs?), a Merkle proof of the block root at slot + 96, followed by a Merkle proof from that slot to the location in the slice commitment array, showing a finality commitment

When we use the BLS-12-381 Kate commitment, the precompilation also verifies that the data is a list of 32-byte chunks, where each chunk is less than the curve subgroup order. If no slice chunk is saved at the given location, the precompilation acts as if a commitment to zero-length data is saved at that location. If the value at the given location is not verified, the precompilation always fails.

def verifyShardPolynomialEvaluation(
slot: uint256,
shard: uint256,
x: uint256,
y: uint256,
proof: bytes
)
If we consider the slice block at the given (slot, shard) as a polynomial P, where bytes i32 … i32+31 is the evaluation at w**i, this verifies that P(x) = y. The proof is the same as the data subset proof, except that Kate’s proof is proving the evaluation at some point (possibly outside the domain) rather than proving a location subset of the data.

If we do not use BLS-12-381 in the future (e.g., using a 32-byte binary field proof), the precompilation takes SNARK as input, verifies that the data consists entirely of values smaller than the order of that curve, and verifies the evaluation of the current field data.

This precompilation is useful for cross-polynomial commitment scheme proofs of equivalent protocols and can be used to allow ZK Rollup to operate directly on sharded data.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/clearing-the-way-for-ether-2-0-v-god-proposes-a-new-backward-compatible-approach-to-ether/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2021-06-09 00:19
Next 2021-06-09 00:28

Related articles