自以太坊选择了以汇总为核心的路线图以来，整个社区都认为汇总将成为以太坊扩展性问题的解决方案。然而，直到今天，汇总在计算能力方面仍然不及某些高性能的一层网络。
这可能是因为汇总团队不仅要处理执行问题，还需要应对各种证明系统、桥接等事务，以推动以太坊的扩展。
但现在，一种新的汇总类型正在崛起，旨在释放汇总的真正潜力：Gigagas 汇总。在我们之前的系列中，我们探讨了基于以太坊的汇总、加速汇总和原生汇总。在本文中，我们将研究 Gigagas 汇总，了解其试图解决的问题以及其运作方式。
汇总的性能挑战是什么？L2 的主要性能问题集中在 DA（数据可用性）问题上。然而，随着 @eigen_da 等外部 DA 解决方案的进展以及 blobs 的引入，DA 不再是瓶颈。相反，我们现在面临多个新的限制。
其中一个最大的问题在于 EVM 的实现通常是单线程的，这意味着它一次只能使用一个 CPU 核心，即使现代 CPU 具有多个核心，可以同时处理不同任务。因此，性能上限受单个核心的时钟频率限制。
过渡到并行执行是一个复杂的过程，需要对 EVM、状态管理和交易结构进行必要的修改。同时，@VangelisAndr 最近的研究表明，以太坊 64.85% 的交易可以并行化，想象一下在 L2 上可以并行化多少交易，从而进一步提升性能。
另一个挑战是提高 L2 的区块 gas 限制以实现更高的吞吐量，这可能会影响证明机制。如果欺诈证明需要提交整个区块，它们可能会与以太坊自身的区块大小限制冲突。L2 的区块生产方式不同于 L1，在排序器和执行客户端中提供了优化和并行化的机会，使其摆脱传统 L1 的概念。
一个重大挑战是实现共享排序，以增强 L2 之间的互操作性，同时保持去中心化。然而，这种方法仍然较新，主要的汇总可能会抵制将排序控制权交给第三方，因为增加可组合性的好处尚不明确，并且可能影响性能。
以太坊使用修改版的 Merkle-Patricia Trie（MPT）来管理和验证其键值数据。EVM 并未规定状态应如何存储，因此节点客户端可以尝试不同的解决方案。目前，LevelDB、PebbleDB 和 MDBX 等实现正在使用中，但它们缺乏经过认证的键值存储的固有属性，例如加密完整性证明。这增加了信任假设，复杂化了欺诈证明，并增加了验证状态变化的开销，影响效率和安全性。
对于大多数汇总，性能通常以交易数量而非 gas 计算。然而，在深入探讨 gigagas 汇总如何解决可扩展性问题之前，我们需要先了解为什么 gas 比 TPS 更具意义，以及为什么我们应该关注它。
为什么我们要衡量 gas？在汇总和以太坊本身的性能测量中，通常使用每秒交易数（TPS），但更精确的度量方式可能是“每秒 gas”。这一指标表示网络每秒的计算能力，其中“gas”代表执行交易或智能合约等操作的计算成本。
然而，TPS 忽略了不同交易和操作的复杂性及资源需求差异，使其成为一个不完整甚至具有误导性的网络性能指标。一个网络可能处理更多交易，但计算成本较低，而 TPS 无法真实反映系统的实际容量。
采用每秒 gas 作为标准性能指标可以更清晰、更准确地衡量区块链的吞吐量和效率。@paramonoww 撰写了一篇文章，探讨了为什么 TPS 是一个不合理的指标。
关注 gas 很重要，因为它反映了网络能处理多少工作量，从而更清晰地展现可扩展性和效率。gas 价格影响网络经济，包括交易费用和奖励，这反过来会影响用户行为和网络安全。因此，每秒交易数提供了一个大致的概览，而每秒 gas 则能深入展现区块链的真实性能。
既然我们理解了 gas，那么什么是 gigagas 以及 gigagas 汇总呢？
什么是 gigagas 汇总？Gigagas 以每秒十亿 gas 单位来衡量带宽，相比 TPS 提供了更优越的容量测量方式。Gigagas 汇总本质上是旨在管理每秒 1 gigagas（即 10 亿 gas 单位）的汇总。虽然这一概念直观易懂，但其实现却极具挑战。目前，即使采用中心化排序，也没有任何以太坊汇总能接近这一基准，整个生态系统的处理能力仅约为每秒 6000 万 gas（60 Mgas）。
来源： rollup.wtf
Gigagas 汇总将通过以 gigagas 计量交易处理能力来扩展吞吐量，使得庞大的交易量或复杂操作能够更快速地执行。它们将通过数据压缩、证明生成和主链数据提交方面的创新来提高效率，旨在实现最小开销和最大吞吐量。
目前，多个团队正在积极研发 gigagas 汇总。例如，@Abundance_xyz 正在构建完整的 gigagas 汇总技术栈，而 @rise_chain 正专注于构建 gigagas 汇总，并对 EVM 及其生态进行大规模修改和优化。接下来，我们将深入探讨 gigagas 汇总的运作方式，重点关注 RISE。
Gigagas 汇总是如何运作的？RISE 是一个 L2 平台，旨在解决以太坊汇总的性能问题。尽管已有诸多进展，但当前的 L2 方案仍无法达到 Solana 的速度。RISE 通过并行 EVM、连续执行以及基于 RethSDK 的全新状态架构来提高吞吐量，目标是实现每秒超过 1 Gigagas 的带宽。
RISE 的架构包含一个完全开源的并行 EVM 执行引擎 pevm，该引擎通过区块流水线支持连续执行。在状态访问方面，RISE 采用版本化默克尔树（Versioned Merkle Trees）来优化性能，并使用专为 EVM 链状态设计的自定义数据库 RiseDB。
RISE 技术栈构建于 Reth 之上。在数据可用性方面，该架构需要高带宽，并采用模块化设计以适应不同的数据可用性解决方案。此外，RISE 采用 based sequencing 来去中心化区块生产。如果你不了解 based 汇总，可以查看本系列的第一篇文章，其中探讨了其优缺点。
在典型的 L2 方案中，由于共识、执行和默克尔化的顺序处理方式，区块时间仅有约 8% 用于实际执行。这种方式效率低下，共识可能占用 40-80% 的时间，而默克尔化最多占用剩余时间的 60%。RISE 的连续区块流水线（Continuous Block Pipeline, CBP）通过并行执行、连续交易处理和并发状态根计算来改进这一流程，使得几乎 100% 的区块时间都用于交易执行，相较于传统方法大幅提升效率。
以太坊使用两层状态系统，并采用默克尔帕特里夏树（MPT）来确保数据完整性。然而，由于 MPT 结构和底层数据库的 LSM（Log-Structured-Merge）树特性，会导致高读写放大效应，使状态查询涉及大量 I/O 操作。MPT 通过扩展节点减少冗余，但仍然面临 SSD 低效利用、较高的压缩开销以及 CPU 在 I/O 等待期间的低利用率等问题。
RISE 通过采用版本化默克尔树（Versioned Merkle Tree）来解决这些问题，该方案使用版本化密钥提高存储效率。此外，RISE 还采用 LETUS 方法，结合增量编码（delta encoding）和日志结构文件（log-structured files）来减少放大效应，从而实现更高效的存储管理和数据检索。
每个汇总都会变成gigagas 汇总吗？并非所有汇总都会转变为 gigagas 汇总，其中有多个原因。并非所有应用都需要如此高的性能，而 gigagas 技术的复杂性和成本可能对于交易需求较低或用例较简单的项目而言并不值得。
一些汇总更关注易用性、隐私性或特定行业应用，而不是纯粹的吞吐量。此外，在可扩展性与去中心化之间需要权衡，一些项目可能更倾向于保持去中心化结构，而不是追求 gigagas 级别的性能。渐进式扩展可能更为现实，避免了对系统进行大规模变更的需求。
向 gigagas 级别过渡可能会影响现有集成，或在没有必要的情况下增加用户交互的复杂性。是否选择成为 gigagas 汇总，很大程度上取决于项目的资源、战略目标及其在链上生态中的定位。
结论Gigagas 汇总在以太坊扩展性方面迈出了重要一步，通过对汇总技术栈的多项改进，解决了传统 L2 汇总面临的核心瓶颈，如单线程执行、默克尔化管理以及状态存储效率低下等问题。
然而，要实现 gigagas 级别的性能，需要相对复杂且具有变革性的架构调整。同时，这也涉及取舍，例如在可扩展性与去中心化之间的权衡。因此，并非生态系统中的每个汇总都必须成为 gigagas 汇总。
除此之外，gigagas 汇总的出现将为以太坊社区提供重要机遇，展示以太坊真正的强大潜力。
在本系列文章中，我们深入探讨了以太坊扩展的不同类型：第一部分介绍了 based 汇总，第二部分探讨了 booster 汇总，第三部分分析了 native 汇总，最后在本篇文章中介绍了 gigagas 汇总。虽然本系列到此结束，但关于 rollup 的探索远未停止，敬请期待后续关于以太坊最新创新的系列文章和深度分析！
免责声明：
本文转载自【2077 研究】，所有版权归原作者所有【2077 研究】。若对本次转载有异议，请联系 Gate Learn 团队，他们会及时处理。免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。Gate Learn 团队将文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。