如何进阶理解智能合约

2015年7月30日，以太坊第一个区块被挖出，以太坊正式登上历史舞台。随之而来，还成就了智能合约的大热门。我们可以从谷歌趋势可看到，智能合约和以太坊的相关性。

智能合约这个概念是1995年由尼克·萨博提出来的。那时候还没有比特币，没有区块链，更没有以太坊。

现在主流的认知都把智能合约和以太坊（或类以太坊项目）绑定在一起。以太坊是一个智能合约平台，任何人都可以在以太坊上发布定义了某些合同属性的代码，并委托给以太坊网络运行。

就像马云开发了淘宝平台，人们可以在淘宝上开网店一样。经营网店并不需要店家自己部署服务器，网店的后台完全是运行在淘宝上的。

目前影响力较大的智能合约实例基本上都是运行在以太坊上，最广泛的几个是发代币、DeFi、去中心化的Du 博。

对于智能合约的应用方向，现在主流的信息对智能合约更多的共识是将传统的合同进行智能合约化改造。传统的合同是通过社会习俗和法律来定义参与方的权利和义务，习俗和法律是合同背后的约束力来源。智能合约化改造是期望于代码来承担约束力来源。

这也是为什么智能合约会被以太坊，以及类以太坊项目绑定在一起的原因。因为以太坊提供了有约束能力的代码运行平台。以太坊被设计成了一个世界计算机，可以让程序的运行不依赖于特定的中心化服务器。

比特币的爱好者对以太坊在智能合约上大放光彩非常不服，也想了大量的办法让比特币网络承接智能合约生意。

比特币系统内置了脚本引擎来完成账本的可编程性，以太坊使用的是虚拟机。后者是图灵完备的，可以用来运行非常复杂的程序。加上比特币的UTXO设计，以太坊是账户设计。前者只能设计无状态的合约。这代表着，比特币上的合约代码是不能利用自己生成的中间状态。比特币的脚本程序都是一次性的，只对这个交易有效，不能被其他交易引用。比特币的脚本代码也不能去读取数据，你无法编写一个程序命令比特币的某笔交易获取特定的参数。只有极少数例外，比如区块CSV指令，允许比特币脚本依赖区块高度来做出反应。对应的，以太坊的虚拟机，都没有这些阻碍。

但比特币网络依然可以承接特定的智能合约。P2SH交易格式允许在脚本里嵌入代码，就可以用来实现特定的应用场景。Core开发者在搞默克尔化抽象语法树（MAST）就有望将比特币脚本构建更复杂的代码。

BCH已经实现了OP_CHECKSIGVERIFY这样的操作码，脚本可以验证外部数据（Oracle），可以用来构建去中心化仲裁的资产交易。如Bitcoin.com发布的local.bitcoin.com就是一个去中心化的资产交易平台。这个操作码还可以用来构建去中心化的菠菜。

但无论是使用以太坊的智能合约平台，还是使用比特币脚本引擎来实现智能合约，都是将传统的合同智能合约化改造的思路。这种思路显然是手里有一把锤子，看什么都是钉子。现在有了智能合约平台，就像是有一把锤子，要把传统的合同全拿这把锤子锤一下。可事实上，传统的合同，在绝大多数情况下，是不需要被改造的。

这种思路是对智能合约的一种矮化。

就如上一篇文章《初步清晰理解智能合约》所描述的比特币挖矿，就是一个非常完美的智能合约。挖矿是全新地创造了一个商业范式，一个智能化的商业范式。

这是智能合约发展的一个思路，创造全新的商业范式。

任何一条链，无论是PoW，还是PoS，其实都是一个类似的商业范式的案例。PoW链里，矿工交付工作量证明，帮用户打包交易，系统发放Coinbase奖励。PoS链里，节点交付币龄证明，帮用户验证交易，系统发放铸币奖励。

去中心化的交易所，参与买卖的交易双方是点对点的，双方在成交之前都是自己控制自己的资产。交易时，不存在第三方介入。去中心化的交易所也是一个无须授权，自运行，公开透明的智能合约。

类似的Openbazaar，是一个去中心化的淘宝，参与者也是不需要注册，系统自运行的商业平台。需要注意的是，Openbazaar并不会记录所有的商业交易。

或许，设计一个区块链项目，首先想明白如何设计出一个商业逻辑自洽的智能合约。

尼克·萨博在提出智能合约这个概念时，还没有诞生比特币，更没有以太坊。把智能合约限制在某个智能合约平台上的自动化运行的程序，是对智能合约这个概念的矮化。回归智能合约的初心，降低商业成本，降低违约风险，扩展商业范围。