什么情况下应该创建 Substrate 运行时模块而不是 Substrate 智能合约？

Question

开发Substrate运行时模块和Substrate智能合约（例如使用ink!语言）之间有什么区别？

哪些应用程序最适合以其中一种形式编写？

- mountbranch

Answer 1

Substrate Runtime模块和Substrate智能合约是使用Substrate框架构建“去中心化应用程序”的两种不同方法。

---

智能合约

传统的智能合约平台允许用户在一些核心区块链逻辑之上发布附加逻辑。由于智能合约逻辑可以由任何人发布，包括恶意行为者和经验不足的开发人员，在智能合约平台周围构建了许多有意的安全保障。以下是一些例子:

• 费用: 确保合约开发人员对他们的合同强制执行的计算和存储进行收费，并且不允许滥用区块创建者。
• 沙盒: 合约不能直接修改核心区块链存储或其他合约的存储。它的能力仅限于修改自己的状态，并具有调用其他合约或运行时功能的外部调用能力。
• 状态租金: 合约占据了区块链上的空间，因此应该为其简单存在而收费。这确保了人们不会利用“免费、无限制的存储”。
• 还原: 合约可能容易出现逻辑错误的情况。合约开发人员的期望很低，因此添加了额外的开销来支持在事务失败时撤消交易，以便在出现问题时不会更新状态。

这些不同的开销使得运行合约变得更加缓慢和昂贵，但是需要指出的是，合约开发的“目标受众群体”与运行时开发人员是不同的。

合约可以让社区在无需经历提案、运行时升级等繁琐流程的情况下扩展和开发您的运行逻辑。它甚至可以作为未来运行时更改的测试场所，但以一种方式进行，该方式将您的网络与任何可能发生的增长痛苦或错误隔离开来。

总之，Substrate智能合约:

• 对网络本身具有固有的安全性。
• 具有内置的防止滥用的经济激励措施。
• 在支持优雅的逻辑故障时具有计算开销。
• 对开发入门门槛较低。
• 通过编写新逻辑的游乐场实现快速社区交互。

---

运行时模块

另一方面，运行时模块并没有像智能合约那样为您提供这些保护或安全措施。作为运行时开发人员，您所编写代码的入门门槛会大大提高。

您完全掌控网络上每个节点将运行的基础逻辑。您可以访问所有模块中的每个存储项，您可以修改和控制这些存储项。您甚至可以使用不正确的逻辑或糟糕的错误处理使您的链变得无法使用。

Substrate运行时模块的开发意图是产生精简、高性能和快速的节点，没有交易回滚的保护或额外的开销，并且不会隐式地向计算引入任何费用系统。这意味着在开发运行时函数时，由您正确评估和应用运行时逻辑的不同部分的费用，以使其不被恶意用户滥用并损害您的网络。

总之，Substrate Runtime Modules：

• 提供对整个区块链的低级访问权限。
• 为了性能，去除了内置安全保护的开销。
• 对开发人员有很高的门槛。
  • 不一定要编写工作代码，但要避免编写错误的代码。
• 没有内在的经济激励来驱逐恶意用户。

---

适合你的正确工具

Substrate Runtime Modules和Substrate智能合约是为解决问题而提供给您的工具。

两者可能在解决问题的种类上有一定的重叠，但也存在一组明确适合只使用其中一个的问题。比如：

• 运行时模块：在您的区块链交易中构建一个隐私层。
• 共享 (Shared)：构建像Cryptokitties这样的DApp，可能需要建立一个用户社区（偏向智能合约），也可能需要实现每天数百万交易的扩展性（偏向运行时模块）。
• 智能合约 (Smart Contract)：为您的网络引入第二层代币和自定义资产。

除了上面提到的所有内容，您还需要考虑使用某种工具来设置DApp的成本。部署合约是一个相对简单和容易的过程，因为您可以利用现有的网络。您需要支付的唯一费用是部署和维护合约时支付的费用。

另一方面，建立自己的区块链需要建立一个发现您服务价值的社区或建立一个具有云计算系统和一般网络维护开销的私有网络。

我认为现在真正容易且可操作的是构建运行时逻辑。过去，每个人都使用他们可以使用的工具——智能合约来构建他们的“去中心化应用想法”，即使那不是最好的工具。

随着Substrate的推出，有了一个新的工具可以用于构建您的去中心化应用程序；但同样，认为所有的想法都应该是Substrate运行时模块是错误的。

首次作为一个社区，我们拥有两个工具，需要一起确定在每种情况下哪一个工具最好使用。我认为今天并没有所有的答案，但我们可以在探索过程中学习和做出一些合理的猜测。

- Shawn Tabrizi