添加面向未来的状态和历史访问预编译,以便在未来承诺方案发生变化时,rollup不需要更改其代码。 这会将rollup数据空间增加到每个slot约 2 MB(每个分片 250 kB * 4 个分片,加上步骤 1 中扩展的 calldata)。 第 3 步:N 个分片,受委员会保护 这一步将活动分片的数量从 4 个增加到 64 个,分片数据现在将进入子网,因此此时 P2P 层必须已经足够稳固,可以拆分成更多的子网。数据可用性的安全性将基于诚实多数,依赖于委员会的安全性。 这会将rollup数据空间增加到每个slot约 16 MB(每个分片 250 kB * 64 个分片),我们假设此时 rollup 已经从执行链中迁移出来。 第4步:数据可用性抽样 (DAS) 到了这一步,我们会添加数据可用性采样(DAS)以确保更高级别的安全性,即使在发生不诚实的多数攻击时也能保护用户。数据可用性采样可以分阶段推出:首先,以非绑定方式允许网络对其进行测试,然后作为接受信标区块的要求,甚至可能在其他客户端之前在某些客户端上进行。 一旦完全引入数据可用性采样,分片部署就完成了。 分片环境下的Optimistic和ZK rollup 分片世界和现状之间的一个主要区别是,在分片世界中,rollup数据实际上不可能成为将rollup区块提交到智能合约的交易的一部分。相反,数据发布步骤和rollup区块提交步骤必须分开: 首先,数据发布步骤将数据放在链上(放入分片中),然后提交步骤提交其header,以及指向基础数据。 Optimism 和 Arbitrum 已经为rollup区块提交使用了一个两步设计,因此这对两者来说都是一个小的代码更改。 而对于ZK rollup而言,事情有点棘手,因为提交交易需要提供直接对数据进行操作的证明。他们可以做一个 ZK-SNARK 的证明,证明分片中的数据与信标链上的承诺相匹配,但这非常昂贵。幸运的是,还有更便宜的选择。 如果ZK-SNARK是基于BLS12-381的PLONK证明,那么他们可以直接将分片数据提交作为输入。BLS12-381 分片数据承诺是 KZG 承诺,与 PLONK 中的承诺类型相同,因此它可以作为公共输入直接传递到证明中。 如果 ZK-SNARK 使用一些不同的方案(甚至只是 BLS12-381 PLONK,但具有更大的可信设置),则它可以包括自己对数据的承诺,并使用等价性证明来验证证明中的承诺和信标链中的承诺是否承诺了相同的数据。 谁将在分片环境下存储历史数据? 增加数据空间的一个必要条件,是删除以太坊核心协议负责永久维护所有达成共识的数据的属性。数据量太大,不需要这样做。例如: (责任编辑:admin) |