现在谈扩容。
这里分为两个层面:短期和长期。
关于短期扩容,我已在其他地方详述。主要包括:
多维 gas 有一套分阶段推进的路线图。
首先,在 Glamsterdam 升级中,我们将“状态创建”成本与“执行和 calldata”成本分离。目前,SSTORE 操作将 slot 从非零改为非零消耗 5000 gas,从零改为非零消耗 20000。Glamsterdam 的一次 gas 重新定价会大幅提升这部分额外成本(例如提升至 60000);我们这样做的目标(叠加 gas 上限提升)是让执行能力的扩展远超状态容量扩展,原因我之前已有详细阐述(
https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052)。因此,在 Glamsterdam 升级后,SSTORE 操作将收取 5000“常规”gas 和(例如)55000“状态创建 gas”。
状态创建 gas 不计入约 1600 万交易 gas 上限,因此可以部署比现有更大的合约。
一个挑战是:EVM 如何支持多维 gas?EVM 的操作码(如 GAS、CALL 等)假设只有一个 gas 维度。我们的方案如下:我们保持两个不变性:
我们的做法是,创建 N+1 个“gas 维度”,默认 N=1(状态创建),额外维度称为“reservoir(蓄水池)”。EVM 执行时优先消耗专用维度,否则消耗 reservoir。例如,若账户拥有(100000 状态创建 gas,100000 reservoir),使用 SSTORE 新建状态三次后,剩余 gas 分别为(100000, 100000)->(45000, 95000)->(0, 80000)->(0, 20000)。GAS 返回 reservoir,CALL 传递 reservoir 中指定的 gas 量及所有非 reservoir gas。
后续将切换到多维定价,即不同维度可采用各自浮动的 gas 价格。这将带来长期的经济可持续性和最优性(详见
https://vitalik.eth.limo/general/2024/05/09/multidim.html)。reservoir 机制解决了该文结尾所述的子调用问题。
接下来,长期扩容分为两部分:ZK-EVM 和 blobs。
对于 blobs,计划是持续迭代 PeerDAS,最终目标是能够理想地处理约 8 MB/秒数据。这已足以满足以太坊自身需求,无意成为全球数据层。目前,blobs 主要服务于 L2。未来,计划将以太坊区块数据直接写入 blobs。这对于无需亲自下载和重执行即可验证超大规模以太坊链至关重要:ZK-SNARKs 消除了重执行需求,PeerDAS 在 blobs 上让用户无需下载即可验证可用性。
对于 ZK-EVM,目标是分阶段提升依赖程度:





