# Neon EVM：以太坊兼容性的限制 By [白开水](https://paragraph.com/@baikaishui) · 2022-05-04 --- ![](https://storage.googleapis.com/papyrus_images/94b45a785b0f75289ff6554bf90709ec958ca0828b785bd0b40888a8af3a2633.jpg) Neon EVM 是一个完整的以太坊仿真，旨在处理类似以太坊的交易并在 Solana 上执行它们。然而，某些交易目前无法通过 Neon EVM 处理，因此可能需要进行调整以允许它们被处理。这些限制是区块链缺乏标准化编程实践的结果——这反映了智能合约开发仍处于早期阶段的事实。此外，尽管以太坊是 dApps 最流行的第 1 层区块链，但它的设计目的是支持在单独的网络（例如 Solana）上执行，并且主要依靠自身来保证安全性 Neon EVM 与以太坊的兼容性 ----------------- Neon EVM 是在 Solana 上构建为智能合约的以太坊仿真。使用 Neon Proxy 的处理架构，Neon EVM 能够同时遵守以太坊和 Solana 规则——使其能够在 Solana 上迭代处理 EVM 字节码合约的并行执行。为此，使用 Vyper/Solidity 编译器构建的 EVM 合约被上传到各个 Solana 账户。然后根据以太坊的规则在 Solana 上检查签名。然而，仍有一些问题仍未解决——这些将在主网启动后得到解决。 与集成以太坊原生 dApp 并将它们连接到 Neon 相关的挑战是双重的，即：处理预编译的合约和复杂的迭代交易。本文将探讨Neon EVM MVP 版本当前**不**支持的很少使用的函数、预编译合约和 RPC 方法。 不支持的预编译合约 --------- 由于计算成本或其他原因，开发人员通常依赖预编译的合约来执行不适合用操作码编写的复杂操作。例如，_ECRecover_预编译是一种流行的验证消息签名的方法，并且与 Neon EVM 兼容。因为预编译的合约依赖于 Neon EVM 之外的东西，所以目前并不是所有的都支持。 在以太坊的八个主要预编译合约中，Neon EVM 目前不支持以下四个： * [bigModExp](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-198.md) — 用于 EVM 内的高效[RSA](https://doc.neonlabs.org/docs/glossary#rsa)验证和其他形式的基于数论的密码学。 * [bn256Add](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-196.md) — 对椭圆曲线操作执行加法。 * [bn256ScalarMult](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-196.md) — 对椭圆曲线运算执行标量乘法。 * [bn256Pairing](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-197.md) —在区块气体限制内执行[zkSNARKs](https://doc.neonlabs.org/docs/glossary#zk-snark)验证所需的椭圆曲线配对操作。 如果在 Solana 上使用任何这些预编译的合约，用 Solidity 编写的智能合约将无法在 Neon EVM 上运行。如果开发人员坚持使用它们，他们应该在 Solana 核心中进行系统调用——类似于_erc-recover_的实现。例如，请在[此处查看](https://github.com/neonlabsorg/solana/pull/43/files)bn256\* Solana Syscalls 的实现。[您还可以在此处查看](https://github.com/neonlabsorg/neon-evm/pull/468/files)Neon EVM 如何在后台使用以太坊预编译合约。 从广义上讲，开发人员可以采取以下步骤通过 Neon EVM 实现上述预编译合约： 1. 准备必要的更改以支持 Solana 核心中的预编译合约。 2. 为 Solana 核心创建拉取请求以进行这些改进。 3. 测试网中的更改。 4. 在 Devnet(开发者测试网) 中测试更改。 5. 测试主网的更改。 6. 更新 Neon EVM 以支持这些预编译合约。 不支持的 JSON-RPC 方法 ---------------- 对于与以太坊通信的软件，它必须能够连接到以太坊节点。此通信由 JSON-远程过程调用 ( [JSON-RPC](https://ethereum.org/en/developers/docs/apis/json-rpc/#:~:text=For%20this%20purpose%2C%20every%20Ethereum,the%20rules%20around%20their%20processing.) ) 处理。Neon EVM 与 JSON-RPC API 的交互方式与 Ethereum 相同，遵循[Ethereum JSON-RPC Specification](https://playground.open-rpc.org/?schemaUrl=https://raw.githubusercontent.com/ethereum/eth1.0-apis/assembled-spec/openrpc.json&uiSchema%5BappBar%5D%5Bui:splitView%5D=true&uiSchema%5BappBar%5D%5Bui:input%5D=false&uiSchema%5BappBar%5D%5Bui:examplesDropdown%5D=false)。 Neon EVM 已经支持一些最流行的 RPC 方法，可以在[此处](https://docs.neon-labs.org/docs/architecture/evm_compatibility/)查看。还有一些其他受支持的方法尚未添加到列表中。 不支持的令牌 ====== 在 Testnet 和 Devnet 中，Neon EVM 都支持使用符合[ERC-20](https://doc.neonlabs.org/docs/glossary#erc-20)标准的代币进行操作。Neon EVM 目前无法处理根据[ERC-721](https://doc.neonlabs.org/docs/glossary#erc-721)标准生成的不可替代令牌 (NFT) 。尽管它们可以在 EVM 中生成，但它们没有价值，并且将被锁定在生态系统中，因为它们在 Neon EVM 之外无法识别。 对迭代事务和当前解决方案的限制 =============== 在迭代交易中，不同的账户在一系列中执行不同的步骤。在使用 Neon EVM 的迭代模式时，尝试执行后可能会出现关于被阻止帐户的错误消息，这将导致交易暂停。由于 Neon EVM 处理迭代事务的方式，会出现此错误消息。 Neon EVM 以下列方式处理迭代事务： 1. Neon EVM 接收一个用于迭代执行的事务并阻止其中指定的帐户。 2. 当下一笔交易进入 Neon EVM 时，EVM 会查看其中指定并参与其执行的账户列表。如果此时任何列出的帐户由于参与另一个交易的迭代执行而被阻止，Neon EVM 将返回错误。 3. 第一笔交易必须首先完成，然后才能解锁被它阻止的帐户。 主网实现的目的是在交易执行期间为 Solana 账户提供一致的状态，直到交易完成。由于事务是以迭代方式执行的，因此每个步骤的执行之间存在时间间隔。因此，此解决方案可防止在这些时间间隔内更改位于系统状态中的 Solana 帐户数据的可能性。 在开始交易时发出有关被冻结帐户的错误是一种临时解决方法。此错误和变通解决方案将在主网上 MVP 发布后实施。 尽管有这些限制，Neon EVM 仍然是一个强大的仿真工具。在绝大多数情况下，它允许开发人员有效地将他们基于 Solidity 的智能合约移植到 Solana 区块链上。即使合约需要一些不受支持的功能，通常也有办法以另一种更兼容的方式实现它。随着时间的推移，Neon 期望在 EVM 中为这些当前不受支持的功能引入更多兼容性。 --- *Originally published on [白开水](https://paragraph.com/@baikaishui/neon-evm)*