为分片采用扫清障碍 V神提出新的以太坊向后兼容方法

当前以太坊设计中的向后兼容性所面临的挑战之一是区块链历史记录的访问需要对 Merkle 证明进行 EVM验证，这还假设区块链将永远使用相同的格式和相同的密码技术。 未来的分片（Sharding）设计更是增加了这一点的重要性，因为Rollup的欺诈证明和有效性证明将需要指向分片数据的指针。

这篇文章提出了一种更加面向未来的方法：我们可以添加执行验证特定类型证明的抽象任务的预编译，而不是要求在 EVM 中验证历史和分片的证明。 如果将来更改格式，预编译逻辑将自动更改。 预编译甚至可以具有条件逻辑，用于验证过渡前插槽（slot）的一种证明和转换后插槽的另一种证明。

历史区块数据

def verifyHistoricalBlockRoot( slot: uint256,     value: bytes32,     proof: bytes )

这种预编译将尝试以两种方式之一解释该proof：

如果这个proof为空，则直接检查该value是否为保存在正确位置的历史区块根。 如果slot太旧，它将失败。

如果这个proof是一个Merkle 分支，它会根据 history_roots 中的正确条目将其验证为 Merkle 分支

def verifyHistoricalStateRoot(     slot: uint256,     value: bytes32,     proof: bytes )

验证状态根，使用与该区块根相同的逻辑。

def verifyHistoricalStateValue(     slot: uint256,     key: bytes32,     value: bytes32,     proof: bytes )

验证历史状态中的值。 这个proof包括三个要素：

状态根

表明状态根正确性的证明

Patricia 或 Verkle 或其他证明该value实际上位于状态树中的位置key中的证明（这假设将所有帐户内容映射到 32 字节key的提议方案已永久保存）

def verifyHistoricalTransaction(     slot: uint256,     txindex: uint256,     tx: bytes,     proof: bytes )

验证 tx 实际上是否在给定slot的区块的 txindex 中。 证明内容如下：

区块根

表明区块根正确性的证明

证明给定的tx实际上是给定位置的交易

def verifyHistoricalReceipt(     slot: uint256,     txindex: uint256,     receipt: bytes,     proof: bytes )

验证receipt实际上是给定slot的 txindex 处的交易接收。 证明内容如下：

区块根

证明区块根正确性的证明

证明给定收据实际上是给定位置的receipt

分片数据

def verifyShardBlockBody(     slot: uint256,     shard: uint256,     startChunk: uint256,    chunks: uint256,     data: bytes,     proof: bytes )

验证 data = body[32 * startChunk: 32 * (startChunk + chunks)] ，其中 body 是给定slot中给定分片的主体。 该证明将包括：

证明区块子集的 Kate 证明

如果slot太旧（超过 128 个 epoch？），则在slot + 96 处的区块根的 Merkle 证明，然后是从该slot到分片承诺数组中的位置的 Merkle 证明，显示一个最终性承诺

当我们使用 BLS-12-381 Kate 承诺时，预编译还将验证数据是 32 字节chunk的列表，其中每个chunk都小于曲线子组顺序。 如果没有在给定位置保存分片区块，则预编译就像在该位置保存了对零长度数据的承诺一样。 如果给定位置的value未确认，则预编译总是失败。

def verifyShardPolynomialEvaluation(     slot: uint256,     shard: uint256,     x: uint256,     y: uint256,     proof: bytes )

如果我们将给定 (slot, shard) 处的分片区块视为多项式 P，其中字节 i*32 ... i*32+31 是 w**i 处的评估，这将验证 P(x) = y。该proof与数据子集proof相同，除了 Kate 证明正在证明某个点（可能在域外）的评估而不是在证明一个位置子集的数据。

如果我们将来不再使用 BLS-12-381（例如，使用 32 字节二进制字段证明），则预编译会将 SNARK 作为输入，验证数据完全由小于该曲线阶数的值组成，并验证对当前字段数据的评估。

这种预编译对于等价协议的跨多项式承诺方案证明‌很有用，可用于允许 ZK Rollup直接对分片数据进行操作。

作者：Vitalik Buterin

原文：https://ethresear.ch/t/future-proof-shard-and-history-access-precompiles/9781