智能合约设计（单链 · 基于 lengzhao/vm）

日期：2026-07-19
类型：合约 / VM 适配设计
状态：已对齐（跨链 Call = 第一版不做；执行方案见 §0 选型结论）
关联：

• 2026-07-19-主分片共识-design.md
• 2026-07-19-账户类型-design.md
  上游参考：lengzhao/vm docs（以链接为准，本文只写本链差异与装配）

0. 主流合约方案对比与本链选型

0.1 主流方案一览

补充参考：VM 综论、EVM/WASM/SVM/CKB 对比。

0.2 各方案要点（架构视角）

EVM

• 优点：工具、审计、流动性、开发者最多；同步 CALL 可组合性成熟。
• 缺点：256-bit 栈机偏慢；全局账户存储天然串行；重入等历史包袱。
• 对本链：若强行 EVM，会放弃 Object 并行与 version 活键优势，等于另做一条「EVM 侧链心智」。

SVM

• 优点：显式账户列表 → 冲突可知 → 多核并行；吞吐导向。
• 缺点：Rust/Anchor 栈；硬件门槛；可组合模式与 EVM 不同。
• 对本链：并行调度可借鉴（你们已有 Read/WriteList）；不必整栈换 BPF。

MoveVM（尤其 Sui）

• 优点：对象/资源与资产安全同语言绑定；Owned/Shared 与并行路径清晰。
• 缺点：Move 生态与人才池小于 Solidity/Go；与 lengzhao/vm 重复建设。
• 对本链：账户文档已吸收「Owner + 对象版本」直觉，不必再上 Move 运行时。

WASM（CosmWasm 等）

• 优点：近原生性能、多语言、Cosmos 应用链常见。
• 缺点：计量与确定性要额外工程；默认不是 Object-UTXO。
• 对本链：可作为远期第二运行时，不是 v1 最优。

lengzhao/vm（Go 源码）

• 优点：与默认 Object / 用户 Object / 审查白名单 / Gas 注入已对齐；Go 团队上手快；库式嵌入节点。
• 缺点：生态与审计市场远小于 EVM；源码合约的确定性/供应链要靠沙箱与白名单扛住。
• 对本链：与已定账户、单链 Call、Coin Object 阻抗最低。

0.3 选型结论（合适方案）

flowchart TD
  R[目标: Object并行 + Go友好 + 快速落地] --> A{是否要最大DeFi生态?}
  A -->|是,可另议| EVM[EVM 兼容层/侧系统]
  A -->|否,本链主路径| B{状态是否已是Object?}
  B -->|是| G[lengzhao/vm 主路径]
  B -->|想要语言级资源| M[Move 重做成本高]
  G --> G1[借 SVM: 声明式读写集并行]
  G --> G2[借 Sui: Owner/version 语义]
  G --> G3[借 EVM: 仅同链同步Call可组合]

推荐方案（定稿）

1. 主执行引擎：继续 lengzhao/vm（Go 源码合约 + 沙箱 + Gas）。
2. 状态与并行：账户设计（Object / Owner / version / 续期 / Coin）+ 交易 Read/WriteList（借 SVM/Sui 调度思想）。
3. 可组合：v1 仅同链同步 Call（借 EVM 可组合，不做跨链 Call）。
4. 明确不选为 v1 主路径：纯 EVM、纯 MoveVM、纯 SVM/BPF；避免双栈。
5. 可选演进：生态需要时再评估 EVM 兼容预编译/桥 或 WASM 第二运行时，与主 Object 状态通过适配层互通——不阻塞第一版。

以下各节按该结论做本链装配说明。

1. 目标与范围

flowchart LR
  subgraph 本设计装配
    Tx[交易] --> Node[链节点调度]
    Node --> VM[lengzhao/vm Engine]
    VM --> Host[Host 适配层]
    Host --> Obj[本链 Object 存储]
    Host --> Coin[Coin / Gas / Renew]
  end

文档分工

2. 采用 vm 的哪些部分（原文链接）

按 00_directory_structure 阅读顺序，本链整包采用以下能力：

详细设计目录 detailed_design/ 作为实现蓝本，本文不重复展开。

3. 合约生命周期（本链装配）

对齐 contract_processing_flow，部署交易在当前链上执行：

flowchart TD
  A[部署交易: Go 源码 + 部署费/Gas Coin] --> B[安全审查]
  B --> C[编译 + Gas 注入 + TinyGo]
  C --> D[生成 ABI / 可执行文件]
  D --> E[分配合约 Address]
  E --> F[创建默认 Object<br/>Owner=合约 version=1 expire_at]
  F --> G[代码与元数据上链/存节点<br/>状态根可锚定]
  G --> H[可被 Call / 用户交易调用]

4. 默认库：本链语义适配

接口形状保持 default_library.md；Host 实现须遵守账户设计。

4.1 保留并直通

• BlockHeight / BlockTime / ContractAddress / Sender / User
• Log / Assert / GetHash
• CreateObject / GetObject / GetObjectWithOwner / DeleteObject
• Object.ID/Owner/Contract/Get/Set/SetOwner

4.2 必须适配的行为

4.3 本链增补 API（建议）

在默认库同包或 host 扩展中增加（名称可调）：

Renew(objectID, extendBy)     // 任何人可调；只延 expire_at；version 不变
SplitCoin / MergeCoin         // 显式 Coin 操作（Transfer 底层用）

Gas：执行消耗按 gas_metering.md；扣费从交易声明的原生 Coin Object 扣除（账户文档 §3.2）。

4.4 与 Owner 规则一致

5. 安全模型（采用 vm + 本链加强）

完整规范见 security_review.md。本链强调：

1. 禁止全局变量 → 状态只进 Object
2. import / 关键字白名单 → 无 unsafe/系统调用等
3. 沙箱执行 → 无宿主机文件/网络
4. Gas 上限 → 超限回滚（状态先缓存再提交，见 gas 文档）
5. 声明式并行 → 交易必须带 Read/WriteList；节点判冲突（账户文档 §4）
6. 单链 Call 边界 → Host 层强制 callee.chain_id == current

6. 执行与并行（节点侧）

对齐 execution_environment §6 与账户文档：

flowchart TD
  T[区块内交易集] --> C[按 Read/WriteList 建冲突图]
  C --> P[无冲突子集并行调 vm.Engine]
  C --> S[争用默认 Object 等串行]
  P --> V[校验 id@version 活集 + 未过期]
  S --> V
  V --> E[执行 / Gas / 提交或回滚]

• 写冲突键：(object_id, version)（账户文档已定）
• 续期交易：目标 Object 可不进 write_list（version 不变）；付费 Coin 进 write_list

7. 与共识 / 分片的边界

合约地址与 ObjectID 建议带隐式 chain_id 命名空间，避免多链 ID 碰撞。

8. 交易类型（合约相关，示意）

参数编码：与 vm 一致，调用数据可用 JSON（function + args）。

9. 决策记录

10. 待标定 / 实现清单

• Host 适配层：Object 存储、签名集、version 校验、单链 Call 守卫
• 默认库包路径：沿用 github.com/lengzhao/vm 或 fork 改模块路径
• 部署费是否与 Gas 分离
• 合约代码上链 vs 仅存内容哈希 + 节点存储（GOVM/多链下存储策略）
• Gas 表是否按账户模型微调（CreateObject/Renew 单价）
• 白名单是否允许合约 import 同链已部署合约源码模块（vm 流程已支持「可 import 模块」）

11. 阅读指引

1. 本文 §1–§4（装配与差异）
2. architecture.md
3. default_library.md + security_review.md
4. gas_metering.md + contract_processing_flow.md
5. 账户类型-design.md（状态真相）
6. 实现时再下钻 detailed_design/

本设计 = lengzhao/vm 合约栈 + 本链账户/共识约束；不复制 vm 全文，避免双源漂移。

• Previous
  主分片共识 Design
• Next
  账户类型 Design