🔴｜以太坊转折：为什么说原生 Rollups 才是更优解？ ———————————————————— 原生 Rollup（Native Rollups）可以被视为分片的一种回归，但与过去的尝试完全不同。下面我将以7个部分来给你讲述： 1）分片（Sharding） 2）什么是 Native Rollups 3）原生Rollups 有什么好处？ 4）重新执行是个啥？ 5）走向“实时证明” 6）延迟“state root” 7）延迟执行 1）分片（Sharding）🔻 曾是 2017-2020 年间的热门话题，当时包括 Harmony、Zilliqa 和 Elrond 在内的多个团队都在各自的区块链中实现了分片。 分片的基本思路是 将网络划分为多个较小的、并行运行的链（Shards），使其能够同时处理交易，这是一种对分布式系统进行扩展的简单方法。在以太坊 2.0 时代，分片也是社区认真讨论的话题之一。然而，以太坊最终决定 不在 L1 直接实现分片，主要基于以下四个关键挑战： 1️⃣ 传统分片模式要求协议从上而下 强制规定 具体的分片数量，每个分片都是 单片式链（Monolithic Chains），遵循预定义模板，缺乏可编程性，实际上只是复制了多个相同的 L1。 2️⃣ 由于当时 零知识证明（ZK）技术尚不成熟，分片的安全性主要依赖于 乐观证明（Optimistic Proofs），这要求系统化地管理欺诈证明逻辑，增加了复杂性。 3️⃣ 在 L1 级别直接实现分片会 显著增加协议复杂性，特别是在 管理快速预确认（Fast Preconfirmation）和慢速最终确认（Slow Final Confirmation） 机制方面，以及 不同安全级别的分片之间的协调。 4️⃣ 在 L1 级别推进大规模扩展，会 增加中心化风险。如果直接在底层协议实现分片，任何潜在问题都会影响整个网络，而不像现在的 L2 方案那样，风险可局限在单个 Rollup 之内。 2）啥是Native Rollup？🔻 咱们得先搞清楚，Rollup 这东西有三个模块：数据、排序和执行。Native Rollup，就是直接用以太坊自家的执行环境来跑它的执行模块。简单来说，可以把它们看成是第一层（L1）上可以编程的执行分片。 想让Rollup用上L1的执行功能，听起来有点绕。说白了，就是得在以太坊 EVM 里再跑一个EVM。这样，L1就能知道Native Rollup每个区块的状态变化是啥样。要实现这点，得有个预编译（Precompile）来帮忙，把这想法变成现实。 EXECUTE预编译是啥？ EXECUTE预编译就是弄一个机制，让一个EVM环境能检查另一个EVM环境的执行结果，同时保持一样的执行规则和状态转换逻辑。 EXECUTE 需要三个输入： 🔹pre_state：执行前的状态根（32字节） 🔹post_state：执行后的状态根（32字节） 🔹witness_trace：执行轨迹，里面装着交易和状态访问的证明 预编译会做一个断言：它会检查从“前状态根”开始，按着执行轨迹跑一遍，最后能不能得到“后状态根”。如果状态转换函数没问题，它就返回“真”。 这个轨迹得让验证者能拿到（比如通过数据块或调用数据），好让他们自己再跑一遍，确认状态转换没毛病。注意，这预编译不收证明当输入，也就是说，协议不硬性要求某种证明系统，证明是通过P2P八卦频道传的，每个证明类型开个新话题就行。 Gas费咋算？ 以太坊资源有限，Gas就是用来量化这些资源的。EXECUTE预编译也有自己的Gas模型，来管计算资源： ——基础费用：预编译收个固定费用（EXECUTE_GAS_COST），再加上执行轨迹用的Gas量乘以Gas单价。 ——累积Gas限制：用了个类似EIP-1559的机制，来计量和定价一个L1区块里所有EXECUTE调用的总Gas消耗，具体有： 🔹EXECUTE_CUMULATIVE_GAS_LIMIT： 一个区块里所有EXECUTE调用能用的最大Gas量。 🔹EXECUTE_CUMULATIVE_GAS_TARGET： 目标Gas用量，用来合理定价。 这可以看成是“限制-目标”Gas模型，有点像数据块（blobs）的DA定价方式。 4）原生Rollups 有什么好处？🔻 ——安全性更强： 现在的 Rollup 设计需要一个“安全委员会”来更新链，因为代码里可能有漏洞。而原生 Rollup（Native Rollup）就不用操心这个了，它直接靠以太坊的“社交共识”（大家一起商量决定）来管理。原生 Rollup 的运营者不用自己修 bug，因为以太坊社区会帮你搞定。 ——跟 Layer 1 更简单地联动： 普通 Rollup 想跟 L1同步操作，已经很接近实现了，但有个条件：L1 和 L2 的区块得同时由同一个“建造者”来打包。而原生 Rollup 不需要这个条件，它可以直接用一个叫“EXECUTE”的工具，检查另一个原生 Rollup 的状态，不用额外信任谁。如果只是“读”数据，比如 Rollup A 想看看 Rollup B 的最新状态，它可以直接引用 B 的“状态根”（state root），再提供一个证明，确认数据没问题。 ——兼容性强： 随着以太坊主网的 EVM 升级，原生 Rollup 能自动继承所有改进，不需要自己再费劲去适配。这保证了它能长期跟以太坊的规划保持一致。 5）重新执行”是个啥？🔻 在原生 Rollup 里，“重新执行”（Re-execution）是第一步的实现方式。简单说，就是验证者自己跑一遍交易记录，确认状态变化是对的，而不是依赖什么复杂的 SNARK 证明。只要设置一个合理的“EXECUTE_CUMULATIVE_GAS_LIMIT”（执行的总燃气限制），验证者还能应付得下这种重新执行。 6）走向“实时证明”🔻 有了“重新执行”，验证者得自己处理所有交易，这会限制吞吐量（处理速度），因为有“EXECUTE_CUMULATIVE_GAS_LIMIT”这个上限。如果用“实时证明”（Real-time Proofs），验证者只需要检查证明，不用自己跑一遍交易，这样限制就能大大放宽。 现在趋势是奔着“实时证明”去的，所以我们得为原生 Rollup 争取更多“证明时间”。为了多挤出点时间，得调整以太坊现在的区块处理结构。 现在的结构是这样的： 一个区块（Block N）有交易提议后，验证者得在 12 秒内（分成三个 4 秒阶段）完成以下步骤，才能进入下一个区块： 🔹执行所有交易  🔹计算状态变化  🔹计算“状态根”（state root）  🔹计算收据和日志 只有这些都搞定，区块才能被验证和确认。按现在的流程，要跟 L1 同步，证明得在 4 秒内完成。但现在的 ZK（零知识证明）技术还没成熟到能在 4 秒内证明一个以太坊区块，所以得给证明留点弹性。 7）延迟“state root”🔻 每个区块头里有个state root，代表执行完所有交易后的状态。这是个性能瓶颈，因为建造者和验证者得先算出这个“state root”，才能提议或验证区块。这计算量很大，占了建造者 40-50% 的时间，有些客户端处理区块时甚至占了 70%。 有人（Resnick 和 Noyes）提议把“state root”计算从关键路径挪开，放到客户端空闲的时候。也就是说，区块 N 不再包含自己交易后的“state root”，而是包含前一个区块（N-1）交易后的“state root”。这会让它延迟一个区块，但能降低链的延迟，还能多争取一整个时间槽（slot）来做证明。 8）延迟执行🔻 “延迟执行”（Delayed Execution）比光延迟“state root”更彻底。有了这个，区块的验证和确认就不用等着交易执行的重活儿了。 先做“静态验证”，只检查基本的东西，比如交易格式和签名对不对。等共识达成（验证+确认），再去执行交易、算“state root”。 这有几个好处：  🔹共识效率高：早点验证区块。  🔹证明时间多：整个确认期加空闲时间都能用来生成证明。  🔹延迟低：缩短关键路径。 不过这个升级会改整个链的结构，也会影响其他升级（比如 FOCIL）。细节就不说了，可能的冲突可以看这里。 #ETH #加密货币