选择基于rust的以太坊虚拟机，还是基于RISC-V的虚拟机？一文了解他们的部署差异和部署机制

原文作者：PaperMoon团队

引言

Polkadot 的智能合约平台支持两种不同的虚拟机执行后端：
    •    Rust Ethereum Virtual Machine（REVM）
    •    基于 RISC-V 架构的 PVM

这两种后端在合约部署方式与优化策略上存在明显差异。

REVM 提供了与以太坊高度兼容的单步部署体验，几乎无需修改即可迁移现有合约；而基于 RISC-V 架构设计的 PVM，则采用了更加结构化的两阶段部署模型，以适配其底层执行架构。

理解这两种后端在部署机制上的差异，有助于开发者在不同执行环境中顺利部署和运行智能合约。

REVM 部署机制

REVM 后端支持无需修改即可部署以太坊合约，实现真正意义上的无缝迁移。

在 REVM 环境下，合约的部署流程与以太坊保持完全一致，包括：
    •    合约字节码在单笔交易中打包并部署
    •    工厂合约可在运行时动态创建新合约
    •    支持运行时代码生成，包括内联汇编（inline assembly）
    •    Hardhat、Foundry、Remix 等主流工具可直接使用，无需适配

因此，对于以太坊开发者而言，在 REVM 上部署合约几乎没有额外学习成本。

PVM 部署机制

PVM 采用了与 EVM 完全不同的部署模型，其设计针对 RISC-V 架构进行了深度优化。

对于简单合约部署场景，PVM 的使用体验同样顺畅；但在涉及工厂模式等高级部署结构时，则需要理解其两阶段部署流程。

标准合约部署

对于大多数常见使用场景，例如：
    •    ERC-20 代币
    •    NFT 合集
    •    独立业务合约

PVM 的部署过程对开发者是透明的，不需要额外操作。

在使用标准 Solidity 编程模式时，Revive 编译器会自动处理底层部署流程，开发者无需关心内部细节。

两阶段部署模型

PVM 将合约部署拆分为两个相互独立的阶段：

1. 代码上传（Code Upload）

合约字节码必须首先上传至链上，并进行存储。

该阶段只负责保存代码，不会创建具体合约实例。

2. 合约实例化（Contract Instantiation）

随后，通过引用已上传代码的哈希值，在链上创建具体合约实例。

每个实例都基于同一份已存储代码生成。

架构差异说明

这种模式与 EVM 将代码与实例打包在同一笔交易中的方式明显不同，并对部分部署模式产生重要影响。

工厂模式的适配要求

在 EVM 中，常见的工厂模式允许合约在运行时动态创建其他合约。例如：

EVM 工厂示例：

// 在 REVM 上可直接运行，在 PVM 上需调整
contract Factory {
    function createToken() public returns (address) {
        // EVM 中可直接内嵌字节码
        return address(new Token());
    }
}

该模式在 REVM 中可以直接使用，但在 PVM 中需要进行适配。

PVM 的部署要求

在 PVM 环境下，工厂合约需要满足以下条件：

1. 预先上传依赖合约
所有可能在运行时被实例化的合约，必须提前上传到链上。

2. 使用代码哈希引用
工厂合约通过已上传代码的哈希值进行实例化，而不是直接嵌入字节码。

3. 禁止运行时代码生成
由于 PVM 采用 RISC-V 格式，不支持动态生成字节码。

工厂合约迁移策略

当从以太坊迁移工厂合约到 PVM 时，建议按照以下流程进行调整：

1. 识别所有依赖合约

明确哪些合约会在运行时被动态创建。

2. 优先部署依赖项

在部署工厂合约前，先将所有依赖合约上传到链上。

3. 使用链上构造函数

充分利用 PVM 提供的链上构造函数功能，实现灵活初始化逻辑。

4. 避免使用汇编创建合约

不要在汇编代码中使用 create 或 create2 操作码进行手动部署。

架构层面的限制

由于 PVM 的部署模型设计，其在部分低层级模式上存在明确限制：

1. EXTCODECOPY 限制

使用 EXTCODECOPY 在运行时读取或操作代码的合约可能出现兼容问题。

2. 运行时代码修改受限

动态构造、修改合约字节码的模式不被支持。

3. 汇编工厂模式限制

使用 YUL 汇编动态生成代码的工厂合约，可能会触发 CodeNotFound 错误。

实际影响说明

上述模式通常需要深入使用汇编才能实现，在标准 Solidity 开发中较为少见，因此对大多数开发者影响较小。

链上构造函数（On-Chain Constructors）

PVM 提供了链上构造函数机制，作为运行时代码生成的替代方案，其优势包括：
    •    支持在不生成新字节码的前提下创建实例
    •    提供灵活的初始化能力
    •    保持代码上传与实例创建的分离
    •    提供更可预测的部署成本

该机制在保证安全性的同时，提高了部署模型的可维护性。

Gas 预估与实际消耗差异

无论是 REVM 还是 PVM，在部署合约时，都可能出现 Gas 预估值与实际消耗存在较大差异的情况。

常见表现为：
    •    预估值明显高于真实消耗
    •    实际消耗通常仅为预估值的约 30%

产生原因

该现象属于正常行为，主要原因在于：
    •    预执行阶段无法精确区分计算权重与存储押金
    •    系统采用保守估算策略避免失败
    •    合约部署涉及大量代码存储押金

因此，系统往往会显著高估成本。

部署模式对比

总结

REVM 与 PVM 均可高效支持智能合约部署，但侧重点不同：
    •    REVM 提供即插即用式的以太坊兼容体验
    •    PVM 提供结构化、可预测的两阶段部署体系

对于大多数场景（如代币合约、应用合约部署），两种后端都可无缝使用。

对于涉及工厂模式等高级架构的项目，在 PVM 上可能需要进行一定适配，但只要提前规划部署流程，迁移成本通常较低。

整体而言，该双后端设计使 Polkadot 能够同时满足：
    •    以太坊生态迁移需求
    •    高性能架构长期演进需求

为开发者提供了兼顾兼容性与可扩展性的部署基础。

原文链接：https://docs.polkadot.com/smart-contracts/for-eth-devs/contract-deployment/