为以太坊2.0扫清障碍，V神提出新的以太坊向后兼容方法

作者：Vitalik Buterin

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

当前以太坊设计中的向后兼容性所面临的挑战之一是区块链历史记录的访问需要对 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包括三个要素：

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

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

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

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

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

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

当我们使用 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直接对分片数据进行操作。

—-

编译者/作者：Kyle

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。