Megaeth 是什么？

MegaETH 是一个与 EVM 兼容的区块链，首次将 Web2 级别的实时性能带到加密世界。我们的目标是将性能推向硬件极限，弥合区块链和传统云计算服务器之间的差距。

MegaETH 提供了几个显著的特性，包括高交易吞吐量、丰富的计算能力，以及最独特的，即使在高负载下也能达到毫秒级的响应时间。有了 MegaETH，开发者可以不受限制地构建和组合最苛刻的应用。

为什么世界需要另一个区块链？

区块链框架的进步大大降低了创建新链的门槛。因此，最近涌现出大量的新链。例如，L2Beat 已经记录了超过 120 个 Layer-2 生态系统中的项目。

然而，简单地创建更多的链并不能解决区块链的可扩展性问题，因为每个单独的链仍然对其托管的 dApp 施加了很大的限制。例如，下表显示了当今主要 EVM 链的每秒目标gas和区块时间。

表格：2024 年 EVM 链的gas参数比较 (来源: Paradigm)

该表清楚地表明，现有的 EVM 链在几个方面面临着重大的限制。首先，它们都表现出较低的交易吞吐量。例如，虽然 opBNB 在同行中以 100 MGas/s 的极高gas速率脱颖而出，但与现代 Web2 服务器的功能相比，仍然相形见绌。作为参考，100 MGas/s 每秒仅转换为 650 次 Uniswap 交换或 3,700 次 ERC-20 转账。相比之下，现代数据库服务器已经在 TPC-C 基准测试中超过每秒一百万次事务。

其次，由于计算能力稀缺，复杂的应用程序无法上链。例如，一个计算第 n 个斐波那契数的简单 EVM 合约，在 n=10^8 时消耗大约 55 亿gas，这需要整个 opBNB 链以 100 MGas/s 的速度计算 55 秒。相比之下，用 C 编写的类似程序只需 30 毫秒即可完成相同的任务，即使使用单个 CPU 核心也已经快了 1833 倍！现在想象一下，在一个利用多核处理来释放另外 100 倍计算能力的区块链上，会有什么样的可能性。

最后，对于需要高更新率或快速反馈循环的应用程序，较长的区块时间是不可行的。除了 Arbitrum One 之外，表中的所有链都会每秒或更长时间更新其状态。然而，像自治世界这样的复杂的完全链上 dApp 需要高 tick 率（例如，小于 100 毫秒的区块间隔）来模拟实时战斗或物理。此外，除非订单可以在 10 毫秒内下达或取消，否则链上的高频交易将是不可能的。

幸运的是，对于 EVM 链来说，这些限制都不是不可克服的。随着我们的技术进步，现在是构建一个实时区块链来释放这些潜力的时候了。更正式地说，实时区块链是一种能够在其到达时立即处理交易，并实时发布结果更新的区块链。此外，它必须支持高交易吞吐量和大量的计算能力，以在用户需求高峰期保持实时体验。

节点专业化：以性能为中心的设计的范式转变

多年来，区块链的可扩展性一直是一个活跃的研究领域。那么，我们如何才能突然实现超越当前最先进水平几个数量级的性能提升呢？答案出乎意料地简单：通过将安全性和抗审查性委托给以太坊和 EigenDA 这样的基础层，人们可以探索巨大的设计空间来实现积极的性能优化。

为了更好地理解这个想法，让我们首先检查一下今天的区块链是如何运作的。每个区块链都包含两个基本组件：共识和执行。共识决定了用户交易的顺序，而执行则按照既定的顺序处理这些交易以更新区块链状态。

在大多数 L1 区块链中，每个节点都执行相同的任务，而没有专业化。每个节点都参与一个分布式协议以达成共识，然后本地执行每个交易。这种设置在性能和去中心化之间施加了根本的权衡。每个 L1 必须决定在多大程度上可以提高普通用户运行节点所需的硬件要求，而又不损害区块链的基本属性，例如安全性和抗审查性。

对于区块链的去中心化来说，普通用户能够运行一个节点至关重要。

–Vitalik Buterin

但是，对于全节点来说，什么样的硬件要求是可以接受的，没有明确的答案。不同的 L1 在性能与去中心化的光谱中定位自己非常不同。例如，下表显示了几个 L1 的推荐硬件配置。

相比之下，L2 代表了区块链设计中的一种范式转变，它消除了对其节点采用一刀切硬件要求的需要。这是因为 L2 区块链本质上是异构的：不同的节点专门用于更有效地执行特定任务。例如，常见的 L2 利用特殊的排序器节点来确定交易的顺序。此外，ZK-Rollups 中的证明者节点通常依赖于 GPU 和 FPGA 等专用加速器来降低生成证明的成本。MegaETH 通过引入一类新的节点（称为副本节点）将节点专业化提升到了一个新的水平，这些节点完全放弃了交易执行，从而将它们与传统的全节点区分开来。

因此，MegaETH 中有四个主要角色：排序器、证明者、全节点和副本节点。排序器节点负责排序和执行用户交易。但是，MegaETH 在任何给定时间只有一个活动的排序器，从而消除了正常执行期间的共识开销。副本节点通过 p2p 网络从该排序器接收状态差异，并将差异直接应用于更新本地状态。值得注意的是，它们不会重新执行交易；相反，它们使用证明者提供的证明间接验证区块。全节点像往常一样运行：它们重新执行每个交易以验证区块。这对于桥接运营商和做市商等高级用户来说至关重要，可以实现快速最终性，但需要更高的硬件要求才能跟上排序器的速度。最后，证明者使用 无状态验证方案 异步且乱序地验证区块。

下图说明了 MegaETH 的基本架构及其主要组件之间的交互。EigenDA 是一个构建在 EigenLayer 上的外部组件。

图：MegaETH 的主要组件及其交互。

节点专业化的一个关键优势是能够独立设置每种类型节点的硬件要求。例如，由于排序器节点处理大量的执行工作，因此最好在高端服务器上运行它们以提高性能。相比之下，副本节点的硬件要求可以保持较低，因为验证证明在计算上并不昂贵。此外，虽然全节点仍然执行执行，但它们可以利用排序器生成的辅助信息来更有效地重新执行交易。这种设置的含义是深远的：正如 Vitalik 的 Endgame 帖子中所述，节点专业化确保了无需信任和高度去中心化的区块验证，即使区块生产变得更加中心化。

下表概述了 MegaETH 中每种类型节点的预计硬件要求：

我们从表中省略了 ZK 证明者节点，因为它们的硬件要求在很大程度上取决于证明堆栈，并且在不同的提供商之间可能会有很大差异。各种 VM 实例的每小时成本来自 instance-pricing.com。值得注意的是，节点专业化使我们能够拥有比普通 Solana 验证器贵 20 倍（且性能高 5-10 倍）的排序器节点，同时保持全节点的成本与以太坊 L1 节点的成本相当。

工程化实时区块链

节点专业化的概念既优雅又强大。自然地，这引出了一个问题：MegaETH 背后的秘密仅仅是一个强大的中心化排序器吗？答案是否定的。

虽然将中心化服务器类比成一个有用的思维模型来理解 MegaETH 的潜力，但这大大低估了这个阶段背后的研究和工程复杂性。创建一个实时区块链涉及的不仅仅是采用一个现成的以太坊执行客户端并提高排序器的硬件水平。

例如，我们的 性能实验 表明，即使配备了 512GB 内存的强大服务器，Reth 在最近的以太坊区块上的实时同步设置中也只能实现大约 1000 TPS，这大约相当于 100 MGas/s。在这个特定的实验中，Reth 的性能受到每个区块中更新 Merkle Patricia Trie (MPT) 的开销的限制，其计算成本几乎是执行交易的 10 倍。有关更多详细信息，我们请读者参考我们在 EthDenver'24 上的演讲：理解以太坊执行客户端性能。

图：Reth 的实时同步性能

总之，虽然节点专业化为性能改进释放了巨大的机会，但设计和实现一个超优化的区块链仍然是一个尚未解决的挑战。

我们的设计理念

像任何复杂的计算机系统一样，区块链在多个相互作用的组件中都有许多潜在的瓶颈。孤立地解决任何瓶颈很少能带来显着的端到端性能改进，因为要么 (1) 它还不是最关键的限制因素，要么 (2) 最关键的瓶颈只是转移到另一个组件。我们一次又一次地看到太多的项目专注于优化特定组件。虽然他们可能会在孤立的微基准测试中展示出令人印象深刻的加速，但这些结果通常无法转化为使最终用户受益的端到端性能提升。

在 MegaETH，我们从一开始就决定在我们的研发过程中应用一种更全面和有原则的方法。我们的设计理念可以概括如下。

首先，我们始终“先测量，后构建”。也就是说，我们总是首先进行深入的性能测量，以识别现有系统的实际问题。基于这些见解，我们然后设计新技术来同时解决所有问题。

其次，我们努力设计系统以达到硬件限制。我们更喜欢接近理论上限的全新设计，而不是对现有系统进行渐进式改进。我们的目标是不为加密基础设施的进一步性能改进留下太多空间，以便该行业最终可以将资源转移到其他阻碍采用的挑战。

下面，我们将介绍设计和实现高性能实时区块链的主要挑战。

交易执行

下图说明了用户交易通过系统的过程，并将作为解释稍后讨论的技术挑战的参考。

图：用户交易的旅程（RPC 节点可以是全节点或副本节点）。

我们将从排序器开始，因为它是许多人最熟悉的组件。排序器负责排序和执行交易。EVM 经常被指责为执行性能相对较低，这导致了许多在以太坊 L2 中用其他虚拟机替换 EVM 的努力。

然而，这种定型观念根本不正确。我们的性能测量表明，在历史同步设置中，revm 已经可以在最近的以太坊区块上实现大约 14,000 TPS。机器配置与前面介绍的实时同步实验相同。

图：Reth 的历史同步性能。

虽然 14,000 TPS 对于大多数 L2 来说已经足够了，但对于像 MegaETH 这样的实时区块链来说还不够。传统的 EVM 实现面临三个主要的效率低下问题：1) 高状态访问延迟，2) 缺乏并行执行，以及 3) 解释器开销。由于节点专业化，我们的排序器节点配备了充足的 RAM 来容纳整个区块链状态，目前以太坊的状态约为 100GB。这种设置通过消除 SSD 读取延迟来显着加速状态访问。例如，在上面的历史同步实验中，sload 操作仅占运行时的 8.8%。因此，我们将专注于以下另外两个挑战。

图：花费时间最多的前 30 个操作码。

并行 EVM 最近已成为一个热门话题，许多团队专注于将最初为 MoveVM 实现的 Block-STM 算法移植到 EVM。虽然可以肯定地说并行 EVM 是一个已解决的问题，但有一个问题：在生产中可实现的实际加速本质上受到工作负载中可用并行性的限制。

不幸的是，我们的测量表明，最近的以太坊区块中的中位数并行性小于 2。即使我们人为地将区块合并成大批量，中位数并行性也仅增加到 2.75。通过检查原始实验数据，很明显，长依赖链在当今的以太坊工作负载中很普遍。如果没有进一步的技术来解决冲突并增加并行性，并行 EVM 的好处将仍然相对有限。

图：从区块 20000000 到 20010000 可用的并行性

正如前面在斐波那契示例中讨论的那样，即使是像 revm 这样相对较快的 EVM 解释器仍然比原生执行慢 1-2 个数量级。与此性能差距相呼应，人们对使用 AOT/JIT 编译来加速单线程 EVM 执行重新产生了兴趣，多个团队正在进行竞争性工作，例如 revmc、evm-mlir 和 IL-EVM。

虽然这些项目在几个计算密集型合约上显示出有希望的结果，但它们的加速在生产环境中非常有限。一个原因是当今大多数合约的计算密集度不高。例如，我们分析了在历史同步期间花费在每个操作码上的时间，发现 revm 中大约 50% 的时间花在“主机”和“系统”操作码上，例如 keccak256、sload 和 sstore，它们已经在 Rust 中实现。因此，这些操作码无法从编译中受益，从而将生产中的最大加速限制为 2 倍。

图：按历史同步中的操作码类别划分的时间分解。

到目前为止，我们只讨论了所有高性能 EVM 链通用的挑战。实时区块链的要求至少引入了另外两个挑战。首先，我们需要以高频率（例如，每 10 毫秒）持续生成区块。其次，我们的并行执行引擎必须支持交易优先级，即使在拥塞高峰期，也允许处理关键交易而不会出现排队延迟。因此，尽管 Block-STM 是一个通用的良好解决方案，但它不适用于我们的低延迟环境。

状态同步

状态同步是使全节点与排序器同步的过程。它是高性能区块链设计中最具挑战性的方面之一，但它经常被忽视。

为了理解为什么状态同步具有挑战性，请考虑像 ERC-20 转账这样的简单交易。让我们做一个粗略的计算来确定同步每秒 100,000 个 ERC-20 转账所需的带宽。每个 ERC-20 转账会修改三个值：发送者的余额（地址 20 字节 + 值 32 字节）和 ERC-20 合约下的两个存储槽（每个 64 字节）（地址 20 字节）。因此，对状态差异进行编码的直接方式的成本约为 200 字节。以每秒 100,000 次转账的速度，这转化为 152.6 Mbps 的带宽消耗，这已经超过了我们的带宽预算。相比之下，这甚至比直接传输 177 字节的原始交易数据 更昂贵。

更复杂的交易会产生更大的状态差异。例如，一个 Uniswap 交换会修改三个合约中的 8 个存储槽，此外还有发送者的余额：即64B * 8 + 20B * 3 + 52B = 624B。以每秒 100,000 次交换的速度，带宽消耗现在为 476.1 Mbps！

此外，仅仅因为全节点具有 100 Mbps 的网络连接并不意味着它可以以 100% 的网络利用率进行同步。这有几个原因。首先，互联网提供商通常会夸大实际的可持续带宽。其次，同一节点上的应用程序必须共享连接。第三，必须为新全节点保留足够的空间以进行引导并加入网络。如果全节点始终以 100% 的网络利用率运行，则新加入的节点将永远无法赶上顶端。最后，对等网络协议不可避免地会引入自身的开销。

那么，我们可以舒适地分配多少带宽用于状态同步？假设平均可持续带宽为 75 Mbps，并且我们将其中的三分之二用于其他应用程序和引导新节点。这给我们留下了 25 Mbps。在这种情况下，要同步每秒 100,000 次 Uniswap 交换，需要对状态差异进行 19 倍的压缩率！

在你的白皮书中忘记了状态同步？

更新状态根

包括以太坊在内的大多数区块链都使用树状的经过身份验证的数据结构（如 MPT）在每个区块后提交其状态。承诺（称为状态根）对于为轻客户端提供存储证明至关重要。因此，即使使用节点专业化，也仍然需要全节点维护状态根，就像排序器节点一样。

如前所述，在 Reth 中更新状态根目前几乎比执行交易贵 10 倍，因为此过程的 IO 密集程度非常高。例如，下图说明了更新二进制 MPT 中的叶节点所涉及的 IO 模式。

图：更新二进制 MPT 的状态根时读取（绿色）和写入（红色）的节点。

在 MPT 中，每个叶子存储一个键值对，该键值对是区块链状态的一部分，而每个内部节点存储一个中间哈希，该哈希提交到其底层子树并包含指向其子节点的指针。要在修改叶子后更新状态根，还必须更新从根到该叶子的路径上的所有内部节点，这还需要读取其子节点以重新计算哈希。例如，更新上图中的叶子a总共需要读取 3 个节点并更新 4 个节点。请注意，必须先读取内部节点才能对其进行更新；否则，无法确定如何获取其子节点。

通常，在具有n个叶子的 k 元 MPT 中更新单个键值对需要分别读取和写入O(k \log_k n)和O(\log_k n)个节点。对于具有 160 亿个密钥（即 1 TB 区块链状态）的二进制 MPT，这大约转化为 68 次读取操作和 34 次写入操作。幸运的是，我们通常可以缓存二进制 MPT 的前 24 层，因此只有最后 20 次读取和 10 次写入操作可能会导致随机磁盘 I/O。

为了更好地理解这个挑战，让我们重温每秒 100,000 个 ERC-20 转账的示例。由于每个 ERC-20 转账会修改三个值，因此状态 trie 必须支持每秒更新 300,000 个密钥。对于一个简单的二进制 MPT，这将转化为大约 600 万次非缓存数据库读取。即使我们假设可以通过单个磁盘 I/O 提供这些数据库读取中的每一个，600 万 IOPS 也远远超过了当今任何消费者 SSD 的功能——而且此计算甚至没有考虑写入操作。

减少磁盘 I/O 的一种常见优化策略是将子树中的多个 trie 节点分组在一起，并将它们存储在一个 4KB 磁盘页中。例如，NOMT 将每个深度为 6 的无根二进制子树放入一个磁盘页中。理想情况下，这会将每个更新密钥的非缓存数据库读取次数从 20 次减少到 2 次，从而导致大约 600,000 次 IOPS。但是，需要注意的是，由于软件开销，乐观的粗略计算与实际实现的性能之间的差距可能很大。根据 Thrum 的基准测试，具有 1.34 亿个密钥的 NOMT 目前每秒最多可以处理 50,000 个叶子更新。虽然这代表着比现有状态 trie 实现的显着改进，但它仍然比我们期望的吞吐量低 6 倍，同时操作的区块链状态比上面的示例小 128 倍。

区块gas限制

到目前为止，我们已经讨论了加速区块链节点执行的各种任务所面临的挑战。但是，有一个问题：即使有人设法开发出一种出色的技术，可以在大多数情况下将特定任务的速度提高 10 倍，但这并不一定意味着区块链可以运行得更快。

原因是区块链的最大速度受到称为区块gas限制的人为上限的限制，该上限已嵌入到共识中。区块gas限制定义了单个区块中可以消耗的最大gas量。除了区块时间之外，区块gas限制还充当节流机制，以确保系统中的任何节点都可以可靠地跟上网络的其余部分，前提是它满足最低硬件要求。

区块gas限制对于确保区块链的安全性和可靠性至关重要。设置区块gas限制的一个经验法则是，它必须确保可以在区块时间内可靠地处理此限制内的任何区块。未能满足此标准将使网络容易受到恶意攻击者的攻击。换句话说，必须保守地选择区块gas限制，以适应最坏的情况。

例如，回想一下，并行 EVM 的实际加速高度依赖于工作负载。虽然可以在历史工作负载上实现平均 2 倍的加速，但很大一部分区块包含长依赖链，因此加速效果最小。因此，如果没有像 Solana 的本地费用市场那样的某种多维gas定价机制，它可以更昂贵地定价对有争议的热点状态的访问，那么基于并行 EVM 实现的平均加速来提高区块gas限制是不可行的，更不用说其最大加速了。

类似地，JIT 编译合约的加速在很大程度上取决于合约的性质。虽然计算密集型合约可能会看到 1-2 个数量级的加速，但当今的大多数合约仅体验到适度的改进。此外，JIT 编译会引入当前gas模型未捕获的开销。例如，编译本身会消耗 CPU 周期，保留生成的本机代码会占用内存或磁盘空间等。因此，在 gas 模型被修改为 (1) 考虑编译开销，以及 (2) 正确地重新调整不从编译中受益的操作码的价格之前，我们无法积极地提高区块gas限制以启用计算密集型应用程序。

支持基础设施

最后，用户不会直接与排序器节点交互，而且大多数人不会在家中运行全节点。相反，用户将交易提交给第三方 RPC 节点，并依赖 dApp 的 Web 前端或区块链浏览器（例如 etherscan.io）来确认交易结果。

因此，区块链的实际用户体验在很大程度上取决于其支持基础设施，例如 RPC 节点和索引器。无论实时区块链运行得多快，如果 RPC 节点无法有效地处理高峰时段的大量读取请求，无法快速将交易传播到排序器节点，或者如果索引器无法足够快地更新应用程序视图以跟上链，那都无关紧要。

以有原则的方法扩展区块链

我们希望现在很清楚区块链是真正复杂的系统，具有许多移动部件，并且改进区块链性能需要的不仅仅是孤立的技术，例如并行 EVM 或 JIT 编译。所有成功的高性能 L1 区块链（例如 Solana 和 Aptos）都在其系统的几乎每个方面都进行了令人印象深刻的工程努力。

这就是为什么 MegaETH 从一开始就致力于一种全面和有原则的研发方法。通过尽早进行深入的性能分析，我们确保始终专注于解决将为用户带来实际收益的问题。在整个过程中，我们很高兴地意识到，对于前面讨论的所有挑战，我们都有一些很酷的东西可以提供。虽然具体的解决方案不在本文的范围之内，但我们期待在未来更详细地介绍它们。

将实时性能带给数十亿用户

实时区块链将模糊 Web2 服务器和区块链之间的界限。借助 MegaETH，最终用户将体验到前所未有的实时性能，而开发人员将能够不受限制地探索他们最雄心勃勃的想法。经过十年的试验，我们终于可以在链上接近 Web2 规模的应用程序。

我们非常感谢迄今为止我们的支持者，并且非常高兴能分享更多关于我们可以提供的内容。下次见。

通过点击“接受”，你同意在你的设备上存储 cookie，以增强网站导航、分析网站使用情况并协助我们的营销工作。查看我们的 Cookie 政策 以获取更多信息。

[COOKIES POLICY](https://www.megaeth.com/cookies-policy)

拒绝

接受

• 原文链接： megaeth.com/research...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～