本体技术视点|一文读懂Substrate的合约机制（一）

本期我们分享来自本体技术团队的一篇文章的第一部分，关于 Substrate 的合约机制分析。

01

概要

Substrate 把整个程序逻辑分为 Host 和 Runtime 部分，Host 功能是固定的，偏向于底层，是采用原生执行的方式，而 Runtime 部分是动态的，偏上层业务，编译成 Wasm 字节码，这样可以随时升级，其执行在 Wasm 虚拟机中。合约功能作为上层业务，放置在 runtime 中，由 contract pallet 模块负责。通过分析本文主要要搞清楚两个问题：

1. 合约设计的经济模型：交易执行收费和存储租金机制；

2. 合约的执行机制：本身跑在 Wasm 虚拟机里的 runtime 里是怎么跑用户 Wasm 合约的。

Runtime 的 contract pallet 扩展了 Currency trait 的账户系统，因此可以和其他基于 Currency 实现账户系统的模块一起使用。扩展的合约账户具有实例化合约和调用其他合约和非合约账户的功能。

为了合约代码的复用，将合约代码的上传部署和合约账户的实例化分成两部分，多个合约账户可以从同一份上传的 code 进行实例化。

02

合约的经济模型

为了避免垃圾交易和恶意合约占用计算和存储资源，合约的设计考虑了交易执行收费和合约存储收费逻辑。当合约账户的余额不够支付存储租金时，合约的存储会被清理并进入 tombstone 状态。

合约的生命周期

alive 状态的合约信息

当合约处于正常工作状态，其主要有以下信息：

tombstone 状态的合约信息

当合约进入 tombstone 状态后，合约的所有存储都会被清理，合约信息里只有一个对 storage_root+code_hash 进行 hash 的值。

合约的复活

合约进入 tombstone 状态后，技术上是可以进行恢复的。首先需要准备一本新临时合约T，往 T 合约的存储中插入原合约中的 key-value 对，使 storage root 和原合约完全一致，然后调用 restore_to 合约接口，这个接口会检查当前合约的 storage root 是否和要恢复的 tombstone 一致，如果满足要求那么就使原合约复活，并且将当前的临时合约的资产转移到复活合约，并销毁当前临时合约。

执行合约的 Gas 收费

交易的 sender 必须在每个 call 中指定 gas limit，未使用完的 gas 会在调用结束后返还。当到达了指定的 gas limit 后，那么所有的 call 和相关的状态变更（包含转账）只会在当前调用的合约层进行回滚，比如，合约 A 调用 B，并且 B 执行时 gas 不够，那么所有 B 的调用将被回滚。如果 A 能对错误进行正确处理，那么 A 的其他调用和状态变更依然可以进行持久存储。初看起来这样做是一个极大的限制，但其实是底层增加了灵活性，因为并不是所有的调用都是灾难性的，因此给了调用方可以进行合理的判断和处理的机会；如果想要其他链那种出错就完全回滚的方式，那么可以在调用 B 出错后 A 也直接报错回滚 A 的变更。

对于 Wasm 的每一个指令和 host 函数都设置了对应的 Instruction Weight。

runtime 会准备一个 gas(amount:u32)的计费函数，在 Wasm 合约上传后，立刻会对 Wasm 中的每一个函数进行计费函数的插入生成新的 code。后续合约的执行都以新的 code 为准。

下一期我们将继续围绕 Substrate 的合约存储的收租机制、Wasm 合约限制、合约对外部交易的接口等方面展开。

如有任何疑问，可通过 [email protected] 联络我们。

—-

编译者/作者：本体Ontology

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。