这个系列面向的是智能合约开发者，或者是在智能合约和自己定制区块链之间摇摆不定的从业者。希望读完这个系列之后，可以帮助大家更好地了解Substrate与智能合约的异同，面对不同的业务需求时，可以更加高效进行技术选型。同时，也希望可以给大家提供一些有趣的视角来看待Substrate，欢迎任何反馈。
简单来说，Substrate是一个构造区块链的“轮子”。在Substrate之前，如果大家想要快速构造一条链，选择是非常少，而且可定制化程度也很低。基本上公链会fork Bitcoin，联盟链会直接使用Hyperledger。Substrate是一个开箱即用的构造区块链的SDK，从简单的智能合约，到中层的链上逻辑，或者底层的p2p网络、数据库、共识，都可以自由定制。关于Substrate入门介绍文章已经很多了，这里就不赘述了。想入门的同学可以看看下面的资料：（注：由于微信订阅号无法跳转外部链接，下面几篇文章请移步 “阅读原文” 后点开）
Substrate初次亮相视频， 15分钟速成搭链， 什么是Substrate - from boka.network
, 什么是Substrate - from Ethfans
想要了解更多的童鞋也可以自行google。
智能合约是部署在区块链之上的一段代码，可以按照合约里预先设定的不可篡改的规则执行功能。因目前主流的智能合约指的都是以太坊上的智能合约，下文中的智能合约指的都是以太坊网络中的智能合约。
在这里，会从最宏观的角度去理解Substrate和智能合约的异同，不会涉及到具体的功能性demo和细节。更加详细的主题我们会在后续的文章中提及。
bool
integers
address (``accountId` in Subtrate)
array
map
enum
string：虽然存在string类型，但是没有完善的string处理方法
linked_map：可以遍历的map
per_things：可以认为定点数
double_map：双键map
enum：这里单独列出来，是因为solidity中的enum只是数字的枚举，而substrate中的enum包含类型信息
Substrate中没有string
Substrate中没有string类型，与string对应的，只有Vec。这就要涉及到Substrate或者是区块链的设计哲学。链上存储是很宝贵的，并且string和Vec是相互可转换的，因此Substrate决定不用string.
Substrate中的enum
Solidity和Substrate中都有enum，但是两者存在的意义对整个系统来说是完全不同的。
Solidity中的enum更像是一个数字的文字化表述，例如下面的定义：enum trafficLight { Red, Yellow, Green}
这里的Red, Yellow和Green 其实只是 0, 1, 2而已。
而Substrate中的enum（其实就是rust中的enum，继续学习请参考：Rust中的枚举）则可以携带类型信息，功能强大。
例如Substrate中的Error，
enum Error<AccountId> { WrongAddress(AccountId), WrongIndex(u32), // ...}Substrate中的linked_map与Solidity中的map
struct Student { string name, uint32 number, uint8 age, }mapping(uint8 => Student) students; uint[] class;并且对array进行元素删除并且是一件O(n)的操作，这意味着我们无法支付的起昂贵的gas费用，并且涉及到多个存储的更改，稍不留神可能就会出现逻辑错误。
Substrate中提供了多种map，包括map, linked_map, double_map。其中linked_map即是对map提供了iterate的功能。这使得存储和逻辑变得更加贴近真实。
想要深入学习Substrate中存储类型的童鞋，请移步Substratec存储类型概览
作为一个前智能合约er，深知dapp的痛：
gas费用太高，用户玩不起；
出块时间长，用户等不起；
一般dapp都会有自己的token，但是用户必须现有eth才可以玩，这对不习惯区块链的用户来说是一大门槛；
新用户经常弄丢私钥，资产都没了；
这当然不是智能合约的错。站在昨天，智能合约是划时代的产物；站在现在，智能合约的不足需要新的技术来弥补。
有些dapp开发者选择不在eth公链上部署dapp，而是自己使用eth开发私链来部署自己的dapp，确实可以解决上述的部分问题，但是类似私钥、多种token对用户门槛的提高，仍然是无法避免的。
而Substrate作为区块链开发的“轮子”，因为优秀的框架设计和抽象分层，给开发者提供了多阶定制选择：
Substrate分层
这里简单介绍一下Substrate的分层，想要深入了解的童鞋可以自己搜索一下，
Substrate Node: 节点层。在这一层基本上不做什么改动。就是编译一下就可以运行一个节点了。如果想要做一些改动，就重写一下创世配置文件就好了。重新定义链中的参数，但是无法修改链的运行逻辑。
Substrate FRAME: runtime层。基本上绝大部分的定制化都发生在这一层。在这一层大家可以做的事情很多，概括起来就是修改区块链的运行逻辑。比如转账、治理、链上升级逻辑、staking等都发生在这一层。是智能合约开发者最需要关注的一部分。
Substrate Core: 核心层。整个FRAME/runtime层在Core面前都可以被忽略。可以用任何语言从0开始搭建一个runtime，只要它最终可以被编译成WebAssembly. 这一层主要包括区块链的一些底层组件，包括共识、数据库、p2p网络等。
对于智能合约开发者而言，我们把大部分目光放在FRAME层就可以了。
在这一层中，大家可以实现任何可以用智能合约实现的功能，以及用智能合约办不到的事情。比如：
自定义token system，除了转账，还实现链逻辑层面上的锁仓、自定义释放规则等；
自定义区块间隔时间和手续费：这里，所有原先区块链的出快慢、手续费高的烦恼都可以丢掉，开发者可以自定义出块时长，以及操作手续费多少；
实现链逻辑的整体升级；
实现链的治理；
实现多种账户支持，例如在用户丢失私钥的情况下，如果保证用户的资产不受损失；
....
所有对区块链操作门槛、用户友好、响应速度的抱怨，都可以在runtime层通过巧妙地设计来化解。接下来会详细聊到其中的一些部分。
solidity智能合约开发者，还有一层痛苦就是，需要不停地ctrl+C和ctrl+V。因为solidity是独立于现有编程语言系统的，没有任何可以直接调用的依赖；solidity里自带的library，与其说是library，更像是一段“不配拥有地址的”代码引用。即使有import，前提也是依赖必须自己写。哪怕复制粘贴。
这使得大家在写solidity代码的时候，无法直接找到现有轮子，然后下载引入；而是复制粘贴+改写，某种程度上，分散了dapp开发者的注意力，进一步阻碍了dapp的生态进步。毕竟，除了注意复杂的业务逻辑和防不胜防的安全漏洞之外，还要自己写轮子。
对此dapp开发者有一段心酸地自嘲，“只要能用solidity写出log(n)就足以创建一个项目了”。
Substrate的FRAME，目前parity自己使用Rust语言进行开发，但任何可以编译成WebAssembly的语言都可以用来写FRAME。终于，开发区块链逻辑也可以像正常写程序一样正常进行了。（这里的痛可能只有dapp开发者能体会了）
这里举个例子，比如著名的BTC-Relay项目，实现了BTC -> ETH的跨链，方法是用solidity在智能合约中实现了一个BTC的SPV（Simplified Payment Verification），其中最关键的一步就是验证比特币网络中的交易的有效性。
验证交易有效性在solidity中的实现，也得益于solidity中提供的precompile的hash function和在BTC中使用的一样(SHA256)，否则可以想见，这样著名的项目，可能就不会出现。
所以，自由地使用各种现有的基础设施，不仅帮助开发者节省时间和精力，更是鼓励整个应用生态层层推进，向水更深、更未知的方向去探索。如果说之前dapp开发者是带着镣铐在跳舞，那现在substrate就是在帮助他们卸下枷锁，更自由地舞蹈。
ETH是没有延后执行或者自动执行功能的，所有的交易必须手动触发。有一些区块链平台已经实现了延后执行的功能，但是不能精准控制执行的时间和条件。
在Substrate中有一个很棒的自定义功能，on_initialize和on_finalize两个功能会在validator构造区块的开始和结束时自动执行，也就是如果有一些很重要的功能，需要根据是否达到时间点或者条件阈值而触发时，这是一个不错的选择。
不建议大规模使用，因为如果需要消耗太多算力的话，会影响到validator的打包出块5. Off-chain worker在写智能合约时，如果想要获取链下数据比如随机数，第一可以自己手动写进去，这样缺乏公信力；或者也可以去请求oracle服务，贵且数据源选择不多。
Substrate有一个功能叫做off-chain worker, 用来执行一些计算密集并且计算周期长的操作。例如在获取链下数据时，可以把http请求操作写在offchain worker中，可以在runtime中被触发执行，获取链下数据并在请求成功之后把结果返回给链上进行相关计算操作。
这不仅给了dapp开发者带来了很多便利，例如随机数请求；更给区块链开发者带来了全新的想象空间。比如在联盟链领域，之前通常的做法就是往左走区块链架构，往右走传统存储服务，因为区块链天然和链下世界隔离的特点，好像很难把两件事情融合在一起。
有了off-chain worker，是不是可以发现一些新的交叉地带？请大家此处放飞想象力。
说了这么多不同，个人感觉，在开发Substrate runtime时，和开发智能合约在思路上，还是很类似的。
无论写智能合约还是runtime，首先都会进行填空题操作：
以上部分在Solidity中直接按照写代码的方式声明变量和方法就可以了，在Susbtrate中则是在相应的宏内声明，详见上表。
所以对于智能合约开发者来说，所需要的只是学习Rust相关的语法，在逻辑构造环节，无缝迁移。
Substrate runtime相关资料，请参考：Substrate Runtime
当然Substrate也不是全都是好处，最大的缺点，就是上手开发确实比智能合约要难。这里的难不仅体现在Rust语法上，还体现在Substrate runtime中的方法不像智能合约一样可以原子调用。即在智能合约中，如果其中一个逻辑失败，那么整个交易执行失败，所有存储更改全部回滚（不会发生）。但是在Substrate中，即使一笔交易在某一处逻辑判断失败，但是在这之前的执行，还是会发生。所以强烈提醒Substrate runtime开发者在开发runtime时，一定要 Verify first, Write Last。
作为系列开篇，简单地总结一下Substrate和合约开发的异同。在接下来的系列文章中，会从具体的例子出发，希望可以帮助大家在实操层面，感受到Substrate开发的自由。
欢迎任何反馈和问题。
本文经作者王大锤授权，转载自「Substrate 区块链开发」知乎专栏，原文链接：https://zhuanlan.zhihu.com/p/108000025
欢迎学习 Substrate:
https://substrate.dev/
关注 Substrate 进展:
https://github.com/paritytech/substrate
关注 Polkadot 进展:
https://github.com/paritytech/polkadot
申请 Bootcamp:
https://bootcamp.web3.foundation/
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。