什么是区块链中的“智能合约”？

提到区块链，就必然离不开“智能合约”二字。 我们在本系列的第一篇文章中提到，“智能合约”（smart contract）是由多产的跨学科法律学者Nick Szabo于1995年提出的，他将其定义为：“智能合约是一组以数字形式定义的Commitments，包括合同方可以执行这些承诺的协议。” 那么，我们应该如何理解这段话呢？

查看比特币区块链系统中的转账：

Alice 转给 Bob 100 个比特币，在比特币区块链系统中记录如下：

本质上，这是一份合同。 这份合约规定，Alice 将 100 个比特币转给 Bob，合约立即生效。 注意里面有个“解锁信息”。 这条“解锁信息”本质上是爱丽丝在证明自己是爱丽丝的地址持有者时需要提交的一条信息。

显然，在比特币区块链系统中，这种纯 UTXO 模式下的合约的用处是非常有限的。 首先，比特币是一个独立运行的封闭系统，其传输脚本不提供与外界交互的接口。 所有的信息（这里主要是解锁信息）只能在脚本提交到区块链之前固定下来，然后才能固定的运行。 这对于“合同”来说是不切实际的。

在我们的实际生活中，一个完整的合同制定-执行过程是随着时间的推移而进行的：

其中，条件的达成通常是外部输入事件，也就是说我们现实生活中的合约通常是“事件驱动”类型的。 这个“事件”是否发生，通常不是通过区块链上的数据来判断，而是依靠事件发生的时间，通过链外输入数据来判断。

以电子商务为例，爱丽丝在某宝从商家那里购买了一台笔记本电脑。 当 Alice 下单成功后，本质上就是生成了一个合约。 这个合约包括爱丽丝需要支付多长时间给第三方平台（事件1）。 然后卖家看到Alice付款后需要发货，Alice收到货后需要点击确认收货（事件2）来完成整个合约（不考虑售后）。

在本合约执行过程中，由于事件1是纯金融活动，已经高度虚拟化，可以实现自动发现事件的自动触发。 事件2是发生在现实世界中的事件，我们需要通过“点击确认接收”将此事件的发生同步到虚拟世界中。 这个“点击确认收货”是虚拟世界中的事件2。 因此，对于某宝的购物合约，事件1本质上是Alice是否向平台转账，事件2是Alice是否点击确认收货。 因此，在本合约中，预留了一个与外界交互的接口——确认收货。

除了能够与外界交互之外，比特币转账合约（脚本）的另一个重要缺陷是它不是图灵完备的。 这句话对于非计算机专业人士来说可能不太容易理解。 我们可以简单理解为它没有循环能力和复杂条件控制能力。

回收合同的能力在我们的现实世界中非常普遍。 例如，我们与电信运营商签订的手机服务合同通常是循环合同。 这种合约以自然月为单位，每月自动执行。 企业之间也有类似的长期采购合同，是一种连续的循环合同。 合约规定的事件（或时间点）全部实现后，会自动循环回到第一步，重新执行。

而复杂的条件控制能力更为常见——合同中默认的条款就是条件控制能力。 事件如何达成，未达成违约条款如何执行等，这些都需要合约具备复杂的条件控制能力。

比特币中的交易是使用一组由比特币区块链底层平台定义的脚本语言编写的。 由于最初的比特币区块链系统是按照数字货币模型设计的，不需要这些复杂的能力。 但是如果我们需要将区块链技术应用到其他业务场景中怎么做比特币合约，往往需要这些能力。 比如我们使用以太坊平台来实现某项业务，整个流程是这样的：

目前，关于智能合约的争议还很多。 主要包括两个方面：

1 合同本身是否是双方真实意思的表达

a) 在现实世界中，我们编写的合同除了合同的细节外，还受外部法律和行业惯例的约束。 在智能合约中，如果合约不能严格反映外部法律和行业惯例，那么合约就不是双方真实意思的表达。

b) 在现实世界中，我们写的合同通常是由律师或法律专家为我们完成的。 不同级别的法律专家在完成合同时的严谨程度不同。 同样在智能合约中，我们编写的合约是由程序员为我们完成的，程序员的水平决定了合约的严谨性。 另一点是程序通常有错误。 在漏洞被发现之前，这些漏洞是否会造成严重损失是未知数。

2 谁是合同的仲裁机构？

a) 在现实世界中，我们通常会在合同中约定发生争议时将邀请哪个仲裁机构对合同进行仲裁。 在区块链中，尤其是公链平台上的智能合约，一旦我们认为合约没有表达双方的真实意思，就找不到仲裁机构对合约进行仲裁。

b) 在联盟链中，由于各方的每个节点的身份都是已知的，现实世界中的司法机关可以介入智能合约纠纷。 但是怎么做比特币合约，这种干预有时可能会影响整个联盟链系统的稳定性。 在这种情况下，如何介入是一个技术问题，这个技术问题可能会带来新的bug。

关于作者