blockchain - 我应该什么时候构建 Substrate 运行时模块而不是 Substrate 智能合约？

Question

开发 Substrate Runtime Module 和 Substrate Smart Contract(例如使用 ink! 语言)之间有什么区别？

哪些应用程序最好以一种或另一种形式编写？

Answer 1

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

智能合约

传统的智能合约平台允许用户在一些核心区块链逻辑之上发布额外的逻辑。由于智能合约逻辑可以由任何人发布，包括恶意行为者和缺乏经验的开发人员，因此围绕智能合约平台构建了许多有意的保护措施。一些例子是:

费用:确保合约开发者为他们在运行合约的计算机上强制执行的计算和存储付费，并且不允许滥用区块创建者。

沙盒:合约不能直接修改核心区块链存储或其他合约的存储。它的功能仅限于修改自己的状态，以及对其他合约或运行时函数进行外部调用的能力。

状态租金:合约占用区块链上的空间，因此应为简单存在而收费。这可确保人们不会利用“免费、无限的存储空间”。

Revert:合约容易出现导致逻辑错误的情况。合约开发人员的期望很低，因此增加了额外的开销来支持在交易失败时恢复交易，因此在出现问题时不会更新状态。

这些不同的开销使运行合约变得更慢且成本更高，但同样，合约开发的“目标受众”与运行时开发人员不同。

合约可以让你的社区在你的运行时逻辑之上扩展和开发，而无需经历所有疯狂的提案、运行时升级等......它甚至可以用作 future 运行时更改的测试基础，但在一种将您的网络与任何可能发生的成长烦恼或错误隔离开来的方法。

总结 , 基板智能合约:

本质上对网络更安全。

建立了防止滥用的经济激励措施。

有计算开销来支持逻辑中的优雅故障。

进入开发阈值较低。

通过游乐场实现快节奏的社区互动以编写新逻辑。

运行时模块

另一方面，运行时模块无法提供智能合约为您提供的这些保护或安全防护。作为运行时开发人员，您生成的代码的进入阈值越来越高。

您可以完全控制网络上每个节点将运行的底层逻辑。您可以完全访问所有模块中的每个存储项目，您可以对其进行修改和控制。你甚至可以用不正确的逻辑或糟糕的错误处理来破坏你的链。

Substrate Runtime Module 开发的目的是生产精益、高性能和快速的节点。它不提供交易恢复的任何保护或开销，并且不会隐式地向链上节点运行的计算引入任何费用系统。这意味着在您开发运行时函数时，您需要正确评估运行时逻辑的不同部分并将其收取费用，以免被不良行为者滥用并损害您的网络。

总结 , 基板运行时模块:

提供对整个区块链的低级别访问。

消除了内置安全性能的开销。

为开发人员设置高阈值。

不一定要编写工作代码，但要避免编写损坏的代码。

没有内在的经济动机来排斥不良行为者。

适合您的工具

Substrate Runtime Modules 和 Substrate Smart Contracts 是您可以用来解决问题的工具。

每个人可以解决的问题种类可能有一定程度的重叠，但也有一组明确的问题只适合两者中的一个。两个在每个类别中只举一个例子:

运行时模块:在区块链交易之上构建隐私层。

共享:构建像 Cryptokitties 这样的 DApp，它可能需要建立一个用户社区(倾向于智能合约)，或者可能需要扩展到每天数百万笔交易(倾向于运行时模块)。

智能合约:将第二层代币和自定义 Assets 引入您的网络。

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

另一方面，建立你自己的区块链需要建立一个社区，在你的服务中找到值(value)，或者建立一个具有云计算系统和一般网络维护开销的私有(private)网络。

我认为现在真的是第一次构建运行时逻辑变得如此简单和平易近人。过去，每个人都使用他们可用的工具智能合约来构建他们的“去中心化应用程序想法”，即使这不是最适合工作的工具。

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

相反，作为一个社区，我们第一次拥有两个工具，我们需要共同找出最适合每个场景的工具。我不认为今天所有的答案都存在，但我们可以在此过程中学习并做出一些有根据的猜测。