我应何时构建基板运行时模块和基板智能合约？

Question

开发基板运行时模块和基板智能合约（例如使用ink！语言）有什么区别？

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

Answer 1

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

智能合约

传统的智能合约平台允许用户在一些核心区块链逻辑之上发布其他逻辑。由于智能合约逻辑可以被任何人（包括恶意行为者和经验不足的开发人员）发布，因此围绕智能合约平台构建了许多故意的安全防护措施。一些例子是：

• 费用：确保对合同开发者收取强制执行其合同的计算机上的计算和存储费用，并且不允许滥用块创建者。
• 沙箱：合约无法直接修改核心区块链存储或其他合约的存储。它的功能仅限于修改其自身的状态以及对其他协定或运行时函数进行外部调用的能力。
• 州租：合同占用了区块链上的空间，因此应就简单存在的情况收取费用。这样可以确保人们不会利用“免费，无限存储”的优势。
• 恢复：合同容易出现导致逻辑错误的情况。合同开发人员的期望很低，因此添加了额外的开销来支持交易失败时的还原交易，因此当出现问题时不会更新任何状态。

这些不同的开销使运行合同的速度变慢且成本更高，但是合同开发的“目标受众”又不同于运行时开发人员。

合同可以使您的社区在您的运行时逻辑之上进行扩展和开发，而无需经历提案，运行时升级等的所有疯狂工作。它甚至可以用作将来运行时更改的测试依据，但是一种将您的网络与可能出现的任何不断增长的麻烦或错误隔离开来的方法。

总之，底物智能合约：

• 本质上对网络更安全。
• 建立了防止滥用的经济激励措施。
• 有计算开销来支持逻辑上的正常故障。
• 降低进入开发的门槛。
• 通过操场实现社区快速互动，以编写新的逻辑。

运行时模块

另一方面，运行时模块无法提供智能合约为您提供的这些保护或安全防护。作为运行时开发人员，您生成的代码上的输入栏会迅速增加。

您完全控制网络上每个节点将运行的基本逻辑。您具有对所有模块中每个存储项目的完全访问权限，可以对其进行修改和控制。您甚至可以用不正确的逻辑或不良的错误处理来构建链。

基板运行时模块开发旨在产生精益，高性能和快速的节点。它不提供事务恢复的任何保护或开销，也不会在链上运行哪些节点的计算中隐式引入任何费用系统。这意味着在开发运行时功能时，要由您自己正确评估并向运行时逻辑的不同部分收取费用，以使它不会被不良行为者滥用并损害您的网络。

总之，底物运行时模块：

• 提供对整个区块链的低级访问。
• 消除了内置安全性带来的性能开销。
• 对开发人员有很高的准入门槛。
  • 不一定要编写工作代码，而是要避免编写损坏的代码。
• 没有内在的经济诱因来击退不良行为者。

适合您的工具

底物运行时模块和底物智能合约是为您提供的解决问题的工具。

每个人可以解决的问题可能存在很多重叠，但也存在一组仅适用于这两个问题的明确问题。在每个类别中，两个仅给出一个示例：

• 运行时模块：在区块链中的交易之上构建隐私层。
• 共享：构建像Cryptokitties这样的DApp，可能需要建立用户社区（倾向于Smart Contract），或者可能需要扩展到每天数百万笔交易（倾向于Runtime Module）。
• 智能合约：将第二层令牌和自定义资产引入您的网络。

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

另一方面，建立您自己的区块链会产生建立社区的成本，这些社区可以在您的服务中找到价值，或者建立私有网络，而这需要云计算系统和一般网络维护的开销。

我认为，现在确实是第一次构建运行时逻辑如此容易且容易上手。过去，即使不是最佳工具，每个人都使用可用的工具“智能合约”建立自己的“去中心化应用程序构想”。

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

相反，作为社区的第一次，我们有两个工具，我们需要一起找出哪种方案最适合每种情况。我认为目前尚无所有答案，但是我们可以在此过程中学习并做出一些有根据的猜测。