Gravity发布Litepaper：高性能EVM公链的未来蓝图

自从2024年8月Gravity Alpha主网🚀开启以来，这个网络的表现简直炸裂，已处理超2.75亿笔交易，每日交易量高达260万笔，交易费用更是轻松突破3000万G！随着Litepaper的发布，Gravity这条高性能EVM链的未来蓝图让人期待不已✨。接下来，我们将深入探索Litepaper，看看Gravity如何为现实应用构建一个卓越的高性能Layer-1区块链架构。

Gravity是Galxe打造的高性能、EVM兼容Layer-1区块链。它的诞生源于Galxe自身的需求，毕竟Galxe可是全球最大的链上分发平台，连接了一个庞大的多链生态，用户数量已超2500万。在这不断发展的过程中，Galxe已经演变成一个去中心化的超级应用，集成了Quest、Passport、Score、Compass和Alva等创新工具，提供忠诚积分、活动NFT、代币奖励、zk-身份验证和跨链智能储蓄等多种服务。随着用户的增加，高交易量成了Gravity建设的动力，忠诚度积分系统支持每秒51.2笔交易，而代币奖励活动则可支持32.1笔每秒的交易。这使得我们在去中心化Galxe后端时必须转向EVM区块链，同时确保用户体验的最佳化。

随着Galxe全面链上化，交易量的增长是必然的📈。预计需求将达到每秒5000万gas，而为了满足更广泛的生态需求（如跨链结算、忠诚度积分交易和NFT市场），可能需要每秒5亿gas的处理能力。因此，Gravity的目标是支持每秒1 gigagas的吞吐量，以应对资源密集型应用的扩展需求。

现有解决方案中，许多平台通过以太坊实现可扩展性，但L2 Rollup的挑战不可避免地导致交易延迟，这对像Galxe这样需要即时交易确认的应用而言，简直是噩梦💤。虽然一些DApp尝试用信任模式或外部监控来缓解延迟，但这些方法却引入了额外的复杂性和风险，对于核心应用来说，显然不是最佳选择。 在这样的环境中，Gravity 诞生了。它的核心是并行 EVM，通过开发 Grevm，这个开源的并行 EVM 执行系统，成功缩小了 L2 和 L1 之间的性能差距。此外，Gravity 模块化了 Aptos 的架构，整合了经过验证的组件，比如 Quorum Store 和 AptosBFT 共识引擎。依托 AptosBFT 的成熟架构，Gravity 避免了从零开始开发的复杂性和潜在风险。最终，Gravity 不仅构建了一条提供全链体验的高性能 L1 区块链，还推出了首个流水线区块链 SDK，极大简化了开发者和用户的交互流程。

超强性能！Gravity 提供了前所未有的可扩展性、去中心化能力和几乎即时的交易速度，结合了 L1 和 L2 的优势，实现了每秒 10,000 笔交易和亚秒级的终结性。同时，借助 EigenLayer 和 Babylon 等再质押协议，Gravity 在启动阶段确保了强大的安全性，降低了长期依赖单一资产的系统性风险。

未来计划，Gravity 将沿着以下路线图前进：

1. 推出 Devnet 阶段 1，测试实时性能；
2. 启动 Longevity Testnet，验证网络长期稳定性；
3. 从 Gravity Alpha 主网过渡到完全运营的 Gravity 主网，为去中心化技术的广泛应用打下基础。

以下是 Gravity Litepaper 的全文编译。 Gravity 是由 Galxe 打造的超强 EVM 兼容 Layer-1 区块链，专为大规模应用和多链生态而生。🚀 其亮点包括每秒 1 gigagas 的吞吐量、亚秒级的交易最终确认，以及基于再质押协议的 PoS 共识机制。Gravity 依托两个核心开源组件：

1. Gravity SDK：这是一款基于再质押的流水线 AptosBFT PoS 共识引擎。
2. Gravity reth：一个采用并行 EVM Grevm (Gravity EVM) 驱动的执行层。

这些工具为 Web3 应用程序提供了构建替代 Layer-1 和高效 Layer-2 的能力，尤其在 EVM 链上大放异彩。本文将深入分析 Gravity 的工程设计和技术创新，展示如何通过流水线架构、先进的共识算法、并行执行技术以及优化的存储机制（通过增强 reth 和改良 Aptos 共识引擎）来满足高性能需求。

引言

Gravity 的开发源于 Galxe 在运营过程中面临的挑战。Galxe 是一款领先的 Web3 应用，提供忠诚度积分、活动 NFTs、代币奖励、零知识身份验证以及多链智能储蓄等服务。随着 Galxe 的迅速成长，其忠诚度积分系统平均每秒处理 51.2 笔交易，而代币奖励活动则平均每秒处理 32.1 笔交易。在逐步去中心化 Galxe 的过程中，将这些用例迁移到 EVM 区块链，并确保流畅的用户体验，成为了一项艰巨的任务。因此，开发一条高性能 EVM 区块链，满足 (1) 高交易吞吐量和 (2) 几乎即时的交易确认，显得尤为重要。💡 在这种背景下，选择现有的 Layer-2 解决方案或开发新的 Layer-1 是个关键决策。💡 Layer-1 利用共识算法实现最终性，而 Layer-2 则通过 Rollup 协议来解决这一问题。二者之间有取舍：Layer-1 通常会因共识算法的局限牺牲部分吞吐量，但能实现更快的交易确认。例如，基于 AptosBFT 的共识算法能在亚秒级确认交易，而乐观 Rollup 的挑战期可能长达七天。尽管零知识证明能加速这一流程，最终确认仍需数小时。鉴于 Gravity 需要亚秒级的最终确认（特别是在其全链意图协议下），我们决定构建 Layer-1。

虽然 Layer-2 在与以太坊的通信上有原生优势，但像 Gravity 这样的 Layer-1 可以通过 Gravity 意图协议和跨链桥，实现与以太坊及其他区块链的深度互操作性。这种设计不仅能与以太坊无缝协作，还增强了整个 Web3 生态的连通性。

此外，再质押协议（restaking）大大降低了构建 PoS Layer-1 区块链的难度。Gravity 利用 EigenLayer 和 Babylon 等协议，整合了以太坊和比特币的质押资产及其广泛的验证者网络。这为 PoS 共识提供了经济保障，使 Gravity 的去中心化与安全性达到了与以太坊相媲美的水平。

总之，Gravity 被设计为一个高性能、EVM 兼容的 Layer-1 区块链，以满足现代 Web3 应用的可扩展性与性能需求。虽然它的初衷是服务 Galxe，但 Gravity SDK 和 Grevm（Gravity EVM）提供的灵活框架，适用于构建任何 Layer-1 和高效 Layer-2，功能类似于 Tendermint/Cosmos SDK。

我们需要 1 gigagas/s 的吞吐量 ⚡

对于区块链来说，吞吐量是最重要的性能指标，通常用每秒交易数（TPS）或每秒 gas 使用量（gas/s）来衡量。以 Galxe 的忠诚点系统为例，它需要至少达到 400 万 gas/s 才能稳定运行。这一数据是基于每笔忠诚点交易平均消耗 80,000 gas，同时每秒能处理约 51.2 笔交易而得出的。 这一预测有了 Gravity Alpha Mainnet 实践数据的强力背书。作为我们测试的 Layer 2 网络，Gravity Alpha Mainnet 的忠诚点交易显示，吞吐量稳稳地能达到 400 万 gas/s，这验证了之前估算的准确性。

尽管链上操作的高成本可能会让需求稍微降温，但 Galxe 的扩张趋势表明，需求在高峰时段可能会激增至当前水平的两到三倍。再加上其他应用场景的加入，比如 NFT、代币奖励，以及未来零知识证明支持的全链任务，如果 Galxe 完全链上化，预计吞吐量需求将飙升至 5000 万 gas/s。假设 Gravity 链上的 gas 使用遵循帕累托分布（就像 Uniswap 一直消耗以太坊 10% 的 gas），为了满足跨链结算、忠诚点交易和 NFT 市场等更广泛的生态需求，理想情况下吞吐量应达到 5 亿 gas/s。因此，区块链需要具备每秒 1 gigagas 的处理能力，以适应资源密集型应用的扩展需求。

要实现如此高的吞吐量，引入并行 EVM 是关键。我们开发了 Grevm，这是目前最快的开源并行 EVM 执行系统，具体性能在后续章节里会详细介绍。

亚秒级的确认时间

除了吞吐量，交易确认速度对用户体验也至关重要。现代用户已经习惯了像 Web2 那样几乎即时的响应，这对区块链来说依然是个挑战。以 Galxe 为例，类似完全链上的游戏对低延迟有较高要求。目前，大多数 EVM 区块链的交易确认时间从几秒到几天不等，远远不能满足这样的需求。我们选择了 AptosBFT 共识算法，以实现亚秒级的确认时间。

虽然 L2 Rollup 理论上能提升吞吐量，但它们的挑战期会导致交易延迟，这对需要即时确认的应用（如 Galxe）来说非常不利。尽管一些 DApp 尝试通过信任模式或外部监控来优化，但这会增加额外的复杂性和风险，对于关键应用并不理想。Gravity SDK 通过设计五阶段流水线，将共识和执行流程并行化，缩短了 L2 和 L1 的性能差距，具体设计将在后文详述。

基于再质押 (Restaking) 的 PoS 安全

gravity sdk 为以太坊的扩展提供了安全的新方式，不仅限于 L2 rollup，而是通过再质押保护的 L1 架构，聪明地平衡了性能、互操作性与安全性。核心模块融合了 EigenLayer 和 Babylon 等再质押协议，带来经济信任支持，确保构建稳健的权益证明共识。

得益于以太坊的 450 亿美元质押资产和 85 万验证者，再加上通过 Babylon 连接的 6000 亿美元比特币资产，gravity 从一开始就奠定了坚固的安全基础，避免了新区块链常见的启动问题及安全隐患，同时有效降低了单一资产带来的系统性风险。💪

gravity chain 架构

gravity chain 主要由两个部分组成：gravity sdk 和 gravity reth。gravity sdk 是基于 Aptos 链改进的区块链框架，Aptos 是当前最先进的基于 HotStuff 共识算法的 PoS 区块链，其流水线架构极大地提升了吞吐量和资源效率。gravity reth 则是基于 reth 的执行层，采用块流反应器（BSR）形式，负责接收来自共识层的提议区块。通过优化 reth，gravity reth 实现了并行执行、批量异步状态提交计算及存储效率提升。这两个组件通过 gravity 共识引擎接口（GCEI）和 reth 适配器紧密结合，由流水线控制器动态管理每个阶段的进度。

这个设计将区块执行与区块共识分开，使执行层作为区块提议的消费者。我们对 reth 的优化，使其与块流反应器（BSR）管理的流水线区块提议流程完美契合。

gravity chain 的交易流程如下：

1. 交易通过 gravity reth JSON RPC 接口提交，完全兼容以太坊。

2. 随后，交易进入 gravity sdk 的内存池并在网络中传播，验证者对交易进行批量处理并生成 quorum store（qs）证书。

3. 每轮的领导者提出包含区块元数据和从内存池及 qs 中选取的有序交易的区块提案。

4. 提案被标记为有序后，将进入执行层。

5. 执行层的 grevm 并行处理交易，生成执行结果，并将新状态传递至状态管理模块。🚀 状态根计算完成后，状态模块会将其传递给共识引擎，以便达成状态根的一致性。🧩

一旦状态根经过最终确认，存储模块则负责将状态根和区块数据进行持久化保存。💾

接下来的部分会深入探讨每个组件的工作原理。

Gravity SDK：开源流水线区块链的创新实践

Gravity SDK 是一个模块化的开源区块链框架，基于成熟的 Aptos 区块链进行开发。它的目标是将 Aptos 的架构模块化，借助经过验证的组件，比如 Quorum Store 和 AptosBFT 共识引擎，创建首个流水线区块链 SDK。

选择 Aptos 作为基础的理由有：

• 顶尖架构：Aptos 是基于 HotStuff 家族共识的先进 PoS 区块链，技术实力超群。
• 极致性能：Aptos 每秒能处理高达 16 万笔交易，最终确认时间低于 1 秒，效率爆表！⚡
• 实战可靠性：经过生产环境的检验，Aptos 展现了卓越的稳定性和高效性。
• 避免重复造轮子：借助 Aptos 的成熟架构，规避了从零开始开发的复杂性和潜在风险。而那些试图超越 Aptos 的项目，往往理论与实践脱节。
• 协同增益：随着 Aptos 的发展，Gravity SDK 能无缝集成新特性，比如随机数 API；同时，模块化架构和创新安全机制也能反哺 Aptos。

基于 Gravity SDK 的区块链通过 Gravity 共识引擎接口（GCEI）与流水线共识引擎连接。尽管 GCEI 兼容多种执行层，Gravity SDK 目前主要支持 Gravity reth。关于 GCEI 的详细信息将在后续章节中进行讨论。

Gravity Consensus Engine Interface (GCEI)

GCEI（Gravity Consensus Execution Interface）协议是共识层与执行层之间的通信桥梁。它规范了这两层之间的交互，确保通过流水线控制器使共识与执行流程保持同步。🔗 主要区别在于流水线化的共识引擎，传统区块链 SDK 和 Gravity SDK 的执行层需要实现为一个 区块流反应器（Block Stream Reactor），这要求它能够不断处理提议的区块流。同时，状态承诺与交易执行必须异步进行，执行层得给共识层发送回压信号，以便灵活调整区块提议的速度。

因为 Gravity SDK 的流水线特性，执行层还得应对提议区块中不可执行的交易。内存池不能访问最新的世界状态，导致无法严格验证交易的有效性：执行可能还未完成。值得注意的是，执行结果不应阻碍后续区块的生成。经过并行化的区块共识与状态共识后，执行层成为了提议区块流的反应器，能在后续阶段自由返回执行结果。

GCEI 协议规范定义了两组 API：

• 共识层 API：由 Gravity SDK 实现，用于执行层响应共识引擎提出的区块并提交状态承诺。

• 执行层 API：需要由执行层实现。共识引擎使用这些 API 进行交易提议前的尽力验证、流化提议的区块，并通知执行层最终的状态承诺。

从交易生命周期来看，GCEI 协议涵盖了以下内容：

1. check_txn（执行层 API）

   • 输入：接收一个交易（GTxn）。
   • 输出：返回交易的发送方地址、nonce 和 gas 限制。
   • 用途：该方法用于共识引擎在将交易提议到区块前进行尽力验证，可以对同一交易多次调用，比如在进入内存池时、被提议到区块前以及状态承诺确定时。

2. submit_txn（共识层 API）

   • 输入：从执行层接收一个交易（GTxn）。
   • 输出：返回 Result<()>，表示交易是否成功添加到内存池。
   • 用途：执行层用此方法将交易提交到内存池，随后共识引擎通过网络传播该交易，并在收到一批交易后形成 Quorum Store。

3. recv_ordered_block（执行层 API）

   • 输入：接收一个 ordered_block（类型为 BlockBatch），包含排序后的交易和区块元数据。
   • 输出：返回 Result<()>，表示执行层是否成功接收并接受该区块。 用途：一旦共识引擎提议了一个区块，就会被送往执行层进行交易执行。这种方式让执行层能够接收并处理提议的区块。

4. update_state_commitment（共识层 API）

• 输入：某区块编号的状态承诺（StateCommitment）。
• 输出：返回 Result<()>，表示状态承诺是否被本地共识引擎成功接受。

用途：在执行层计算出状态承诺后，发送到共识层进行最终确认，确保与其他验证者达成 2f+1 的轻量级共识。如果状态承诺的共识与提议的区块差距过大，流水线控制器会调整区块提议的速度。

5. commit_block_hash（执行层 API）

• 输入：接收一组 block_ids 向量，表示需要提交的区块。
• 输出：返回 Result<()>，指示操作是否成功。

用途：当状态承诺最终确认后，共识层会通知执行层将区块哈希提交到区块链存储中。

区块链流水线

Gravity SDK 通过五阶段流水线架构来最大化硬件资源利用率，以实现更高的吞吐量和更低的延迟。流水线在不同区块之间交错执行任务，流水线管理器利用反馈机制确保区块链稳步前进。前三个阶段属于共识层，而后两个阶段属于执行层。

各阶段解释如下：

1. 交易传播：这个阶段高效地在验证者之间传播交易，确保交易能够及时且可靠地被包含在区块中。设计上解耦了交易传播与共识机制，借鉴了 Narwhal & Tusk 和 Aptos 的理念，验证者连续共享交易批次，充分利用网络资源并发运行。当一批交易获得 2f+1 权重签名（形成可用性证明 PoAv）时，确保该批交易由至少 f+1 诚实验证者存储，所有诚实验证者均可检索这些交易用于执行。

2. 区块元数据排序：此阶段在网络内建立一致且公认的交易和区块元数据顺序。共识机制（AptosBFT）遵循双链规则（2-chain rule）来提供拜占庭容错区块。区块随后将流入执行阶段，准备进行并行处理。 · 阶段 3（BSR）：并行交易执行🚀：这个阶段是执行层的一部分，交易在这里并行处理。执行的结果会被传递到状态承诺阶段，像接力赛一样，谁也不能掉链子。

· 阶段 4：状态承诺📝：在这一阶段，交易执行后状态的变化会被确认，并为区块的最终确定做好准备。状态承诺和交易执行是异步的，确保下一个区块的执行不被当前区块的状态承诺拖慢。

· 阶段 5：状态持久化💾：这个阶段将已确认的状态变化保存到区块链存储中。最终状态根和相关数据会被存储在 Gravity Store 里，这个存储用的是超级优化的引擎，设计目的是快速且可靠。同时，会通知内存池和 Quorum Store 删除未来无法包含的交易，确保数据的及时更新。

Staking 和 Restaking 模块🔒

构建一个安全的权益证明（PoS）Layer 1 区块链可不是小事，特别是当你只能依赖链上特定代币进行质押时💥。这种方法在初期可能会遇到经济安全性不足的窘境，比如代币价值波动大或者验证者参与度不高等。为了解决这些问题，Gravity SDK 提供了一个灵活的 Staking 和 Restaking 模块，旨在通过本地和外部的质押机制来增强网络的安全性。

Gravity SDK 的一大亮点是引入了 EigenLayer ( https://www.eigenlayer.xyz/ ) 和 Babylon ( https://babylonlabs.io/ ) 等 Restaking 协议。这些协议允许验证者将其他成熟网络（如以太坊和比特币）的资产重新质押，充分利用现有的安全保障💪。通过允许验证者抵押这些网络的资产，Gravity SDK 能够提升网络的经济安全性，而不必完全依赖本地代币。这种方式不仅增强了链的稳健性，还促进了验证者生态系统的多样性🌈。Staking 模块的设计以模块化为核心，Restaking 组件高度灵活，能够轻松适应区块链生态系统的演变，跟上潮流。 该模块具备支持 Restaking 资产的能力，同时也能够质押自定义的 ERC20 Token，比如以太坊上的 G Token。🔗 验证者通过质押这些可用的 Token 参与共识，增强网络安全。验证者的投票权是基于其总质押价值计算的，涵盖自定义 Token 和 Restaking 协议中的资产。这一计算方式依据链的具体设置，允许每条链根据自身需求灵活调整质押和再质押的规则。

🌟 Epoch 管理器在共识引擎中与 Staking 模块密切合作，用于评估下一轮验证者集合的权重。它从执行层获取质押值，确保共识过程能准确反映最新的质押动态。在这个框架内，跨链资产（例如来自以太坊的质押资产）需先桥接到执行层才能参与计算验证者的总质押值。桥接机制由执行层负责，便于灵活处理跨链通信。可能的方案包括 PoS 桥、链状态的零知识证明，以及自启动的跨链消息传递。

🔍 更多的技术细节、API 设计以及 Staking 和 Restaking 机制的详细说明将在后续文档中提供。

微小发报道：Gravity Reth - 区块流反应器 EVM 执行层

在 Gravity SDK 结构中，整合以太坊虚拟机（EVM）执行层带来了独特的挑战，尤其是在充分利用其流水线共识引擎能力时。为实现无缝集成并最大化架构潜力，我们需对开源以太坊客户端 reth 进行多项关键优化。这些优化将 reth 转变为 Gravity reth，专门为流水线共识引擎量身打造的优化 EVM 执行层。

💡 传统区块链架构按顺序处理区块，确保每个区块在提议下一个之前完全验证和执行。然而，Gravity SDK 采用了流水线共识机制，分离区块处理的各个阶段以提升性能。这一转变引发了复杂性：

⚠️ 意外交易：在流水线链中，因前一个区块的执行尚未完成，内存池无法获取最新的世界状态。因此，提议区块中的交易在提议时可能无法执行，因为缺乏最新状态的情况下，其有效性无法被严格验证。 为了避免流水线卡壳，执行结果不能成为后续区块生成的绊脚石。执行层得能异步处理提议区块，并且在后续阶段返回执行结果而不妨碍共识过程。说白了，对于 EVM 来说，这就意味着得重新定义 blockhash，摆脱对区块头中 stateRoot 字段的依赖。

为了解决这些棘手的问题，我们引入了四项核心优化：

1. 区块流反应器（BSR）：BSR 就像个调节器，目的是把 reth 调整为 Gravity SDK 的流水线区块提议流程。它让执行层能持续消费提议区块流，充当异步处理区块的“反应器”。BSR 与共识引擎建立了动态反馈循环，结合适当的回压信号。这些信号根据执行层的吞吐量和延迟实时调整区块提议和状态提交的速度。如果执行层因复杂交易或资源限制而滞后，回压机制就会降低区块提议速率，确保系统稳定。

2. 状态提交与交易执行解耦：这项优化的重点是将状态提交的计算和交易执行分开。通过这一解耦，我们实现了状态提交计算的异步化，让后续区块的执行不必等当前区块的状态提交完成。我们重新定义了 blockhash，去掉了对区块头中 stateRoot 字段的依赖，确保状态根计算不会拖后续区块的生成。

3. 存储层优化：在流水线架构下，快速缓存和持久化多版本状态值与状态提交至关重要。第三项优化专注于增强存储层，以满足这些需求而不造成瓶颈。通过优化存储机制，我们确保状态数据能够迅速写入并高并发检索。这包括构建多版本存储引擎和支持从数据库到存储 API 的异步 I/O。

4. 并行 EVM：最后一项优化是将 EVM 内的交易执行并行化。我们开发了 Grevm，这是一种并行 EVM 运行时，通过并发执行交易大幅提升交易处理速度。Grevm 利用交易模拟中获得的数据依赖提示来优化并行执行，减少交易重新执行的次数，从而提高吞吐量。

Grevm（Gravity EVM）- 并行 EVM 执行

Grevm 是个开源项目，托管在 GitHub 上（如果现在还没有开源，未来肯定会开源）。想要了解更多信息，请查看它的 README 这里。

• Grevm（Gravity EVM） 是一款基于 revm 的开源并行 EVM 运行时，灵感源自于 BlockSTM。这家伙可不是普通的家伙，它通过引入模拟结果中获得的交易数据依赖图来提升性能，真的是聪明得不得了！😏

• 在基准测试中，Grevm 被评为最快的开源并行 EVM 实现，速度惊人！对于无冲突交易，它的速度是顺序执行的 4.13 倍，达到了 26.50 gigagas/s。想象一下，如果模拟真实世界 100 μs 的 I/O 延迟，Grevm 的速度是顺序执行的 50.84 倍，吞吐量也高达 6.80 gigagas/s。这一切的魔法都来自于并行执行与异步 I/O 操作的完美结合，让 I/O 操作高效重叠，简直是加速秘籍！⚡️

• Grevm 的核心理念是利用交易之间的数据依赖性，通过推测的交易读/写集来优化并行执行。虽然这些提示不一定完全准确，但通常足够实用。以以太坊主网为例，历史 Gas 使用情况显示，大约 30% 的交易是简单的以太币转账，另有 25%-30% 是 ERC20 代币转账，这些交易只需读取和写入有限的账户和存储槽，模拟结果的准确性相当高。

• 基于这些见解，我们为 Grevm 设计了一个三阶段并行执行框架，作为 Block-STM 模型的后续工作，结合了从交易模拟中获得的数据依赖提示：

  1. 阶段 1：提示生成与状态预加载——模拟交易，收集依赖提示并预热内存缓存。这个阶段可以在不同时间点进行，具体取决于区块链的设计，比如新交易到达内存池时，可以马上模拟以提前准备依赖提示。

  2. 阶段 2：依赖分析——将模拟阶段收集的依赖提示转化为表示交易间依赖关系的有向无环图（DAG），这可用于规划后续并行执行中的交易调度。 阶段 3：并行执行的冲突解决✨
     使用基于依赖 DAG 的改进版 BlockSTM 算法来并行处理交易。调度程序不再死板地跟随区块中交易的序列号（如 1, 2, 3, ..., n），而是优先依据 DAG 排序，旨在最大程度减少冲突和重新执行的需求。

异步批量状态提交🚀

状态提交一直是区块链流水线中的一个主要瓶颈，主要因为默克尔化的天然顺序性。每个子树的计算必须在最终状态提交前完成，这常常导致显著延迟。虽然现有方案（例如 reth 的账户级并行化）引入了某种程度的并行性，但依然存在大量优化空间。在 Gravity reth 的区块流反应器（BSR）执行层背景下，状态提交的共识与交易执行实现了解耦，允许状态提交计算以异步方式进行推迟和批量处理，不再阻塞执行。

为了解决这些挑战，提出的框架引入了以下关键创新：

1. 异步批量哈希计算：通过状态提交共识与交易执行的解耦，该框架实现了状态提交的异步计算。状态根的更新采用批量处理（如每 10 个区块更新一次），以降低状态根计算的频率。这种批量处理方式通过聚合共享的脏节点，进行高效哈希计算，最大限度地减少频繁更新的开销，降低总体计算成本。对于小区块，批量处理显著提升了并行性；对于大区块，则有效降低了总体计算成本。

2. 完全并行化：该框架将并行化扩展至整个状态树，而不仅限于单一账户树。对于标记为「脏」的节点，采用并行状态计算算法，将树划分为独立的子树，进行并发处理。最终结果在顶层聚合，以高效计算最终根。这种方法确保大型区块能够充分利用多线程，有效提升吞吐量。

3. 替代快速状态根：为了适应以太坊的区块头和 BLOCKHASH 操作码（需要访问最近 256 个区块的状态根），我们重新定义了状态根。不同于依赖于最终状态提交（在交易执行期间不可用），状态根的计算基于区块变更集与之前状态根的哈希值组合。这种方式使状态根的计算速度更快，无需等待完整的状态提交完成。 Gravity Store

为了应对高性能区块链对大规模数据管理的需求，Gravity Store 作为一款优化的多版本存储层诞生了。它基于 reth 的设计，通过将状态提交存储与状态数据存储分开，有效缓解了状态膨胀的问题，并降低了数据读写的开销。不过，Gravity reth 的执行层还需要进一步支持并行处理和异步状态提交，这给技术带来了新的挑战。

为了解决这些问题，Gravity Store 提出了高效的多版本树结构，专为 BSR（Block Stream Reactor）架构量身定制。这种树结构能够管理多版本的状态更新。与传统方法不同，Gravity Store 会将修改过的节点标记为「脏节点」，实现哈希计算的延迟处理与批量执行。这种设计可以快速创建新版本、高效查询指定版本的数据，并清理低于指定高度的旧版本，从而显著提升区块链状态管理的性能。

我们还在开发独立的存储引擎 Gravity DB，目标是为区块链应用提供优化的存储层，支持完全异步的 I/O 操作。该引擎设计灵感来源于 LETUS ( https://dl.acm.org/doi/abs/10.1145/3626246.3653390 )，这是一个面向区块链的高性能日志结构化通用数据库引擎。我们的首席开发人员 Richard 作为 LETUS 的主要作者之一，近期将通过博客文章详细介绍其设计。

**

总结

**

Gravity Chain 是一款高性能的 EVM 兼容第一层区块链，专为现代 web3 应用的可扩展性和性能需求而设计。结合 Gravity SDK、管道化的 AptosBFT PoS 共识引擎，以及由 Grevm 驱动的 Block Stream Reactor 执行层 Gravity reth，Gravity 实现了每秒 1 gigagas 的交易吞吐量、亚秒级的交易确认时间，以及基于再质押机制的 PoS 安全性。这些技术组件的设计为 web3 应用提供了创建自定义替代 L1 区块链或更高效 L2 解决方案的坚实基础，特别适合优化 EVM 链的使用场景。

本文来自投稿，不代表微小发报道观点