EOS EVM 的定位是成为最广泛采用的 EVM 之一，并为 EOS 吸引新一波以太坊开发者。 

撰文：EOS 网络基金会

EOS 以太坊虚拟机（EVM）已经开展了一年多时间，整个生态系统的贡献者都涉及其中，目前开发工作已经进入启动前的最后阶段，3 月 27 日计划推出最终测试网，主网 Beta（0.4）版本将在 2023 年 4 月 14 日启动。

EOS EVM 简述

EVM 指的是以太坊虚拟机。在以太坊生态系统中，它是一系列的智能合约，允许开发者部署和运行使用 Solidity 编写的去中心化应用程序（dApp）。EOS EVM 是对以太坊 EVM 的模拟，并位于 EOS 智能合约中。

EOS EVM 将提供与该领域其他 EVM 同等的功能，但具有更快的速度、性能和兼容性优势，这些优势归功于 EOS EVM 的架构设计和 EOS 原生系统的强大特性。

EOS EVM：以太坊推动者

当 EOS 首次推出时，许多人将其称为以太坊杀手，但这从来都不是 EOS 的目的，并且这一想法不会随着 EOS EVM 的推出而改变。取而代之的是，EOS EVM 将成为以太坊的推动者，允许 Solidity 开发者通过 EOS EVM 在其项目中获得无与伦比的可扩展性。

由 Antelope.io 驱动的 EOS 原生系统的全部功能仅仅只被探索了非常小一部分。因此，在该层上建立下一代的 Web3 应用程序拥有许多新的发展机会。但是这个发展机会是一把双刃剑。目前缺乏适当的工具、教育资源和基础设施，可以让 DApp 开发者在原生系统上快速启动和运行。

另一方面，以太坊的本地语言 Solidity 已经成为 Web3 行业的基石。自 2015 年以太坊最初发布以来，有大量的开源工具、教程、项目和开发者在以太坊生态系统中不断成长。因此，对于一个新的开发者来说，通过访问 Solidity 库，很容易学习 Web3 开发的技巧，并更快开始构建。

随着 EOS EVM 的推出，开发者可以兼得鱼和熊掌，将 EOS 技术堆栈的强大性能与以太坊社区的可访问资源相结合。因此，在 EOS 上实现 Solidity 开发是推动网络被大规模采用的下一个重要步骤。

EOS Native 在大规模采用中所扮演的角色

尽管目前的重点是 EOS EVM，但 EOS Native Layer 仍然是生态的旗舰产品。随着 Leap v4.0.0 的即将发布，EOS Native 将与 EOS EVM 一起继续创新。

EOS Native 是用 C++ 编写的，这是一种在传统开发者中非常受欢迎的语言，拥有速度和强大的库优势。它经常被用于对性能有严格要求的技术项目，如操作系统和游戏。

由于这种底层架构，基于 EOS Native 构建的智能合约更加高效、强大，并且经常受到从 Web2 或其他传统计算机科学领域进入 Web3 领域开发者的青睐。随着 GameFi 的兴起，EOS Native 仍然是一个实现大规模采用的强大载体平台，它使那些已经在 Web2 环境中构建的游戏开发者能够根据需求，无缝集成 Web3 元素。

随着 EOS Native 基础设施优化工作的持续开展，以及目前来自以太坊生态系统的工具在 EOS EVM 上的推出，可以预见 EOS 生态将出现在任何其他生态系统中都不可能的出现的创新机会。基于此，EOS 正将自己定位为一个积极的正和开发环境。对于 Web3 的资深人士或刚刚进入该领域的人而言，这是一个协调资源和协同创新的完美场所。

EOS EVM 技术细节

EOS EVM 的幕后开发工作中发生了很多事情，以确保它最大限度地提高性能和易用性。下面我们将要介绍过去一年中实施的一些创新设计选择。

Silkworm 架构设计

EOS EVM 的推出时间表曾发生过一些变化，而导致这一变化的原因之一是实施 Silkworm 作为 EOS EVM 的执行客户端，这是一个主要架构增强优化。Silkworm 是 Ethereum 节点的 C++ 实现，符合 Erigon 的规范，它被用于支持 RPC 并提高该领域的兼容性。

它的设计目标是成为最快的以太坊客户端，同时不牺牲代码的性能或可读性。 以下是 EtherWorld 的一篇文章，其中介绍了 Silkworm 强大功能的一些要点：

• Silkworm 更容易理解，因为其代码库是新的，并且不包含任何主要的遗留功能。
• 它在开发者社区保持中立客观。
• Silkworm 采用 Apache-2.0 许可协议进行许可。 此许可证是 Permissive，这意味着它的限制最少，可以在大多数项目中使用。
• Silkworm 使用 evmone 作为其 EVM 解释器，这是已知的最快、完全兼容的 EVM 实现。
• Silkworm 使用 MDBX，它是最快的嵌入式键值存储，具有完全 ACID 交易。

采用这种架构设计的主要原因之一，是以一种可扩展且与生态系统其他领域完全兼容的方式为 RPC 请求提供服务。开发者和用户需要一些方法来访问 EVM 环境的最新状态，以便查询链上数据或生成新的交易，这就是 RPC 发挥作用的地方。

EVM 合约首先在 EOS 区块链上处理 EVM 交易。之后，它由一个单独的基于 Silkworm 的 EVM 节点从 EOS 区块链中提取出来，进行重新处理，以便该节点保持其对 EVM 环境状态的看法与合约应该看到的内容同步。此状态允许 RPC 节点为来自客户端（例如 MetaMask 钱包）的标准 RPC 请求提供服务。通过将 RPC 节点与处理 EOS 区块链的 Leap 节点分开，RPC 节点的新实例可以作为一种手段来扩展，以满足客户 RPC 请求的要求。每一个额外的 RPC 节点，只需要跟踪 EVM 的状态，可以简单地从数量少得多的 Leap 节点中获得 EOS 区块，这些节点负责跟踪所有 EOS 状态。

此外，与替代节点实现相比，在 EOS EVM 中使用 Silkworm 的一个主要好处是，它可以在 EVM 合约和服务 RPC 请求的节点之间共享大量核心代码。这降低了两个环境之间不兼容的风险。由于 Silkworm 是用 C++ 实现的，因此编译成 WebAssembly 并在 EVM 合约中运行是很简单的。通过共享相同的代码来保持两个环境之间固有的兼容性，尤其是一个重要的优势，因为需要对 Silkworm 代码进行进一步的更改，以支持 EOS EVM 中的自定义功能，例如无无需信任的跨链桥。

考虑到以上所有原因，尽管它造成了发布延迟，但迁移到 Silkworm 已成为 EOS EVM 的一个重要选择。

加密原语

当前 Web3 领域中的一个重要议题是用户隐私问题。随着越来越多的企业应用程序进入该领域，实施隐私保护技术变得更加必要。这导致了直到最近才在 EOS 上执行的 zk-SNARKS 等工具的流行。

当 Leap 3.1 硬分叉发生时，Antelope 协议引入了 Crypto Primitives 功能，以启用可以支持此操作和其他复杂操作的新功能。该功能使所有 EOS 合约都可以使用新的主机功能，同时与以太坊密码学预编译进行 1 对 1 映射。

以太坊生态系统已经有了很多这样的功能，理论上可以执行。然而，昂贵的 Gas 费和缓慢的交易会导致技术和经济上的障碍。有了 EOS EVM，这些障碍就消失了，开发者能够试验在其他环境中难以执行的库。

除了将 zk-SNARKS 的功能引入 EOS EVM 之外，开发者现在还可以利用原生 EOS Layer 上的相同原语。这将再次在推动 EOS Native 和 EOS EVM 大规模采用方面发挥重要作用。

1 秒区块时间

如前所述，性能和兼容性是 EOS EVM 开发过程中的重要考虑因素。在决定 EVM 出块时间应该有多快时，这两个因素都会发挥作用。EOS 原生区块时间为半秒，而 EOS EVM 区块时间为 1 秒。这比以太坊大约 12 秒的出块时间快得多，并且它保持了兼容性，如果设计短于一秒则可能会丢失。

半秒出块时间在理论上比一秒快，但在实践中要复杂得多。首先，这里讨论的指标是延迟而不是吞吐量。 无论选择什么样的出块时间，EOS EVM 都能从 EOS 区块链的高吞吐量中获益。其次，在实践中，从发送交易到确认它被包含在一个区块中，观察到的实际延迟并不会简单地通过将区块时间从一秒减少到半秒而减半；延迟的减少没有那么显著。因此，将出块时间从 1 秒降到半秒，在性能上有小的提升，但在设计的兼容性方面却有潜在的重大损失。

关于出块时间间隔是多少，EVM 操作码返回当前区块时间戳只有秒的分辨率，这是由于以太坊规范。 这意味着为了实现一对一的区块映射，即每个 EOS 区块对应一个 EVM 区块，有必要截断时间戳，并在两个不同的连续区块上发送相同的时间戳。

虽然在不同的区块中重复时间戳可能不会造成太大的损害，但这将是一个设计风险，因为它打破了传统 Solidity 合约与 EVM 交互的方式。在开发 EOS EVM 时，重要的是要确保来自以太坊的开发者拥有与其原生链尽可能相似的体验。 因此，我们选择了对兼容性造成最小损害的出块时间。

此外，该设计还可以分离原生和 EVM 出块时间。这意味着将来，如果 EOS 网络决定更改出块频率，也不会影响 EVM 运行。 虽然没有计划在这方面进行任何升级，但开发者可以放心，基于 EOS EVM 构建的 dApp 将与 EOS 网络架构未来的任何变化相兼容。

获得资金，开始建设，为上线做好准备

EOS EVM 的定位是成为最广泛采用的 EVM 之一，并为 EOS 吸引新一波以太坊开发者。这主要归功于本文所解释的架构设计选择，包括：

• 支持 RPC 的 Silkworm 的 C++ 实现，允许节点扩展以满足客户的 RPC 需求。
• Leap 3.1 引入了 Crypto Primitives 架构，支持在 EOS EVM 和 EOS Native 上进行 zk-SNARKS 和其他复杂计算。
• 1 秒出块时间，这在实现出色性能的同时，仍保持了 EOS EVM 与传统以太坊 EVM 之间的最大兼容性。

本周，EOS EVM 代码完成，新测试网定于 3 月 27 日启动。随着主网将于 4 月 14 日上线，现在将是开始在 EOS 上建设的最佳时机。

尽管 EOS EVM 取得了巨大进步，但 EOS Native 的工作并没有放缓。事实上，由于目前 EVM 所需的资源较少，核心协议开发者可以将更多精力投入到 EOS Native 上。这将确保 EOS Native 继续作为 EOS 网络的旗舰产品，同时仍然允许 Solidity 项目利用 EOS 所提供的所有优势。

无论是基于 EOS EVM 还是 EOS Native 进行构建，都有大量的资源和资金可以帮助项目快速启动和运行。 点击此处详细了解 EOS 生态系统中的资助机会 。您也可以查看上一篇关于 EOS EVM 的文章，了解有关如何连接到当前测试网的详细信息。同时欢迎前往 EOS 文档和 EOS 学习门户网站，获取有关如何在 EOS 上构建和部署 DApp 的详细指导。