如需了解更多差异与相似之处,请参阅 Aptos Learn
| 功能 | Ethereum | Aptos |
|---|
| 智能合约 | Solidity, EVM | Move, MoveVM |
| 优势 | 成熟,广泛采用 | 可扩展性,高吞吐量,低延迟,可预测费用 |
| 交易手续费 | 变化大,可能很高 | 更低且更可预测 |
| 账户地址 | 160 位 | 256 位 |
| 账户结构 | 余额存储于单一字段,使用 nonce | 模块与资源,使用序列号 |
| 数据存储 | Patricia Merkle 树 | 通过资源和模块实现的全局存储 |
| 存储思路 | 基于合约的存储 | 以账户为中心的代码与数据管理 |
| 示例代码 | ERC-20 | Fungible Asset |
| 调用者 ID | msg.sender | &signer reference |
| 可升级性 | 代理模式 | 直接模块升级 |
| 安全性 | 易受重入等攻击 | 缓解常见漏洞 |
| 调度类型 | 动态调度 | 静态调度 |
| FT 标准 | ERC-20 | Coin(传统)与 Fungible Asset |
| NFT 标准 | ERC-721, ERC-1155 | Digital Asset |
| 区块链交互 | Ethers.js library | Aptos Typescript SDK |
| Solidity | Move (Aptos) |
|---|
| 代币结构 | 每个代币是独立的合约. | 每个代币是单一,可复用合约下的类型化 Coin 或 FungibleAsset. |
| 代币标准 | 必须符合如 ERC20 等标准,具体实现可变. | 所有代币采用统一接口和实现. |
| 余额存储 | 余额通过合约内的 mapping 结构存储. | 资源导向余额:余额作为资源存储在用户账户中.资源不可随意创建,确保代币价值的完整性. |
| 转账机制 | 可在未获接收方明确授权的情况下转账. | 除特定情况(如 AptosCoin)外,代币通常需要接收方 signer 权限进行转账. |
- EVM:以灵活性和动态调度著称,支持多样化的智能合约行为.但这种灵活性会导致并行执行和网络操作的复杂性提升.
- Move VM:注重安全与高效,虚拟机与编程语言深度集成.其数据存储模型有助于更好地并行化,静态调度提升了安全性和可预测性.
| EVM (Ethereum Virtual Machine) | Move VM (Move Virtual Machine) |
|---|
| 数据存储 | 数据存储于智能合约的存储空间. | 数据分布于智能合约,用户账户和对象. |
| 并行化 | 由于存储空间共享,并行执行受限. | 灵活的分离式存储设计带来更强的并行执行能力. |
| 虚拟机与语言集成 | EVM 与智能合约语言(如 Solidity)为分层结构. | 虚拟机层与 Move 语言无缝集成,原生函数以 Rust 可执行文件形式在 Move 中实现. |
| 关键网络操作 | 网络操作实现复杂且不够直接. | 关键操作如验证者集管理在 Move 中原生实现,可直接执行. |
| 函数调用 | 动态调度支持任意智能合约调用. | 静态调度更注重安全性和可预测性. |
| 类型安全 | 合约类型提供一定的类型安全. | Move 的模块结构体与泛型提供更强的类型安全. |
| 交易安全 | 通过 nonce 实现交易排序与安全. | 通过序列号实现交易排序与安全. |
| 认证存储 | 支持,基于智能合约存储. | 支持,基于 Move 的资源模型. |
| 对象可访问性 | 对象不具备全局可访问性,仅限于智能合约作用域. | 对象保证全局可访问性. |
