虚拟机
FRAME 提供了两个智能合约虚拟机，可以添加到 Substrate runtime。
合约模块
FRAME 合约模块（SEAL）为 runtime 提供部署和执行 WebAssembly 智能合约的功能。它旨在迭代现代智能合约平台的设计。
EVM 模块
FRAME EVM 模块[1]提供了 EVM 执行环境，允许未修改的 EVM 代码在基于 Substrate 的区块链中执行。它的设计目的是在 Substrate runtime 上最接近的模拟在以太坊主网上执行合约的功能。
自定义
Substrate 不是一个仅限制于自带模块的平台。
我们鼓励在 Substrate runtime 的基础上进一步开发更多选择的智能合约平台。你可以使用这些预先构建的模块在现有的系统上设计自己的系统或端口，然后去运行了一个基于 Substrate 的链。
智能合约语言
ink!
ink![2] 是一个基于 Rust 的 eDSL，专门用于为合约模块[3]编写 Wasm 智能合约。它设计的目的是为了正确、简洁和高效。
智能合约 vs Runtime 模块
Substrate runtime 模块和 Substrate 智能合约是使用 Substrate 框架构建“去中心化应用程序”的两种不同方法。
智能合约
传统的智能合约平台允许用户在一些核心区块链逻辑的基础上增加额外的逻辑。由于任何人都可以发布智能合约逻辑，包括恶意行为人和缺乏经验的开发人员，因此在这些公共智能合约平台都建立了许多安全卫士。
一些例子：
- 费用：确保合约开发人员在执行合约的计算机上强制进行计算和存储，并且不允许滥用区块创建者。
- 沙盒：合约不能直接修改核心区块链存储或其他合约的存储。它的能力仅限于修改自己的状态，以及对其他合约或 runtime 函数进行外部调用的能力。
- 状态租赁：合约占用区块链上的空间，因此应该收取存在的费用。这确保人们不会利用“免费、无限存储”。
- 还原：合约很容易出现导致逻辑错误的情况。合约开发人员的期望值很低，因此会增加额外的开销支持在交易失败时还原交易，所以在出现错误时不会更新状态。
这些不同的管理开销使得运行合约变得更慢、成本更高，但是，合约开发的“目标受众”与 runtime 开发人员不同。
合约可以让你的社区在 runtime 逻辑的基础上进行扩展和开发，而无需经历所有疯狂的提议、runtime 升级等等... 它甚至可以用作将来 runtime 更改的测试基础，这种方式可以将你的网络与 “成长带来的痛苦” 或可能发生的错误隔离开来。
总结一下，Substrate 智能合约：
- 对网络来说本质上更安全。
- 建立了防止滥用的经济激励机制。
- 具有计算开销可以去支持逻辑中的正常故障。
- 开发门槛较低。
- 通过 playground 实现快速社区互动，以编写新逻辑。
Runtime 模块
Runtime 模块不提供智能合约提供的这些安全保护。所以作为一个 runtime 开发人员，你的开发成本会比较高。
你可以完全控制网络上每个节点运行的底层逻辑。你可以完全访问所有模块中的每个存储项，也可以对其进行修改和控制。你甚至可以用不正确的逻辑或糟糕的错误处理来构建你的链。
Substrate runtime 模块开发的目的是产生精益的、高效的和快速的节点。它不提供交易还原的任何保护或开销，也不会向链上节点运行的计算引入任何收费系统。这意味着，在开发 runtime 函数时，你需要正确评估 runtime 逻辑的不同部分并对其计算费用，这样就不会被坏的参与者滥用，也不会损害你的网络。
总结一下，Substrate Runtime 模块：
- 提供了对整条区块链的底层访问接口。
- 移除了内置的安全性开销系统，从而提高了性能。
- 对开发人员有很高的门槛。
- 不一定要写工作代码，但要避免写坏代码。
- 没有内在的经济激励来击退坏的参与者。
适合你的工具
Substrate runtime 模块和 Substrate 智能合约是可以用于解决问题的工具。
这两个方法能解决的问题可能有一定程度的重叠，但也有一些明确的问题只适合其中一个。关于这个，在这里给出一些举例：
- Runtime Module：在区块链中的交易之上构建隐私层。
- 共享：构建一个游戏 dApp，它可能需要构建一个用户社区（倾向于使用智能合约），或者可能需要扩展到每天数百万个交易（倾向于使用 runtime 模块）。
- 智能合约：在你的区块链代币上引入多签名钱包。
