关注 Polkadot 生态的社区今天应该都收到一条消息：Gavin 正式公布了有关 Kusama 拍卖的时间安排，Kusama 网络目前已经开启众贷活动。波卡生态上的项目们早已摩拳擦掌，将早早准备好的平行链竞拍计划公之于众，吸引更多的社区成员参与其中。

在波卡上，开发者可以基于 Substate 框架构建出自己希望的区块链，达到链级别创新。然而写一条链的开发难度和拍槽成本过高，需要质押几百万的 DOT/KSM ，如果项目方拍下了平行链插槽，还需要等到插槽租赁期过后才能解锁，而且平行链插槽租期至少半年轮换一次。

而用智能合约的方式，能够把一条平行链的资源按照 Gas 价格，以每个块的粒度实时拍卖出去。部署难度和运行成本都很低，还可以获得不同业务场景的可组合性。在 Gavin Wood 设计的波卡平台上，可容纳多种智能合约技术，形成最丰富的技术多样性，达到异构多链的状态。不仅可以吸收已有的生态，同时低成本开展新的创新。

波卡的 Pallet-Contracts 是最原生的 Wasm 合约，能够发挥虚拟机最直接的效能。目前，波卡原生 Wasm 合约模型以及基于 Rust 的这个 ink! 语言框架，但不是很成熟。

作为波卡生态上的 Wasm 合约技术提供方，为了提供一个最基本的节点环境，Patract 启动了一条测试链 Jupiter，开发完成了基于 JavaScript 的自动化测试环境 Redspot 开发脚手架；以及可通过 AssemblyScript 编写 ERC20、ERC721 这类复杂合约的 Ask! 合约框架等等，满足开发者利用 Substate 构建出自己希望的区块链，达到链级别创新。

那应该什么时候构建 Substrate Runtime Modules 而不是 Substrate 智能合约呢？在 stackoverflow.com 看到一位开发者是这样回答的（原文见文末）：

Substrate 智能合约

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

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

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

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

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

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

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

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

总之，Substrate 智能合约：

本质上对网络更安全；
建立了防止滥用的经济激励措施；
有计算开销来支持逻辑中的优雅故障；
进入开发门槛较低；
通过 playground 实现快节奏的社区互动以编写新逻辑。

Runtime Modules

另一方面，Runtime modules 无法提供智能合约为你提供的这些保护或安全防护。作为运行时开发人员，你生成代码的进入门槛就越来越高。

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

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

总之，Substrate Runtime Module ：

提供对整个区块链的低级别访问；
消除了内置安全性的开销以提高性能；
为开发人员设置高门槛；
不一定要编写工作代码，但要避免编写损坏的代码；
没有内在的经济动机来排斥不良行为者。

选择适合你的工具

Substrate Runtime Modules 和 Substrate 智能合约是你可以用来解决问题的工具。

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

Runtime Modules：在区块链交易之上构建隐私层。

共享：构建像 Cryptokitties 这样的 DApp，它可能需要建立一个用户社区（倾向于智能合约），或者可能需要扩展到每天数百万笔交易（倾向于 Runtime Module）

智能合约：将第二层代币和自定义资产引入你的网络。

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

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

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

随着 Substrate 的引入，有一个新工具可用于构建你的去中心化应用；但同样，有着“你的所有主意都应该是一个 Substrate Runtime Module ”这种想法是错误的。

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

原文链接：

https://stackoverflow.com/questions/56040779/when-should-i-build-a-substrate-runtime-module-versus-a-substrate-smart-contract/56041305#56041305

预告：

本周 PolkaWorld 直播将邀请 Bifrost 和 Acala 团队，与社区分享平行链插槽拍卖和奖励发放等信息，点击下方按钮立即预约⬇️

欢迎学习 Substrate:
https://substrate.dev/
关注 Substrate 进展:
https://github.com/paritytech/substrate
关注 Polkadot 进展:
https://github.com/paritytech/polkadot

什么时候该构建 Substrate 智能合约而不是 Substrate Runtime Module？

Substrate Runtime Modules 和 Substrate 智能合约是你可以用来解决问题的工具。