谈到区块链，必然离不开“智能合约”这个词。我们在本系列的第一篇文章中提到“智能合约”（smart contract）是由多产的跨领域法律学者 Nick Szabo 在1995年提出来的，他的定义为：“一个智能合约是一套以数字形式定义的承诺，包括合约参与方可以在上面执行这些承诺的协议。”那么，我们该如何理解这段话呢？
回顾一下比特币区块链系统中的转账：
Alice 转账给 Bob 100比特币，在比特币区块链系统中是这样记录的：
本质上，这就是一个合同。这个合同里面规定了 Alice 要转给 Bob 100比特币，该合同立即生效。注意，里面有一个“解锁信息”，这个“解锁信息”本质上就是 Alice 证明自己是 Alice 的地址持有者时需要提交的一个信息。
显然，像比特币区块链系统里面，纯UTXO模式的这种合同用处是很有限的。首先，比特币是一个独立运行的封闭系统，它的转账脚本没有提供和外界进行交互的接口。所有信息（这里主要是解锁信息）只能在脚本提交到区块链之前定死，之后就只能按照固定方式运行。这对于“合同”来说是不符合实际应用的。
在我们实际生活中，一个完整的合同制定——执行流程是按照如下方式随着时间流逝而进行的：
其中，条件的达成通常是一个外部输入的事件，这意味着，我们实际生活中的合同通常是“事件驱动”型的。这个“事件”是否发生通常不是区块链上的数据能够判断出来的，而是依靠事件发生的时间点，通过链外输入数据的方式实现。
以电子商务为例，Alice 在某宝的某个商家购买了一台笔记本电脑，当 Alice下单成功的那一刻，实质上就生成了一个合同。这个合同包含了 Alice 需要在多长时间内付款到第三方平台（事件1）。然后卖家看到 Alice 付款后需要发货，当 Alice 收到货以后需要点击确认收货（事件2），完成整个合同（在不考虑售后的情况下）。
在这个合同的执行过程中，事件1由于是一个纯粹的金融活动，已经高度的虚拟化，能够实现自动发现事件自动触发。而事件2则是一个在现实世界中发生的活动，需要我们“点击确认收货”来把这个事件的发生同步到虚拟世界中，这个“点击确认收货”就是虚拟世界中的事件2。所以，对于某宝的购物合同而言，事件1实质上是 Alice 是否转账到平台，事件2是 Alice 是否点击确认收货。因此，在这个合同中，预留了一个和外部交互的接口——确认收货。
除了和外部的交互能力外，比特币转账合同（脚本）的另一个重要缺陷是它不是图灵完备的。这句话对于非计算机专业的人来说可能不太好理解，我们可以简单的理解为它没有循环能力和复杂的条件控制能力。
合同的循环能力在我们现实世界中是很常见的，例如我们和电信运营商签署的移动电话服务合同，通常就是一个循环合同。这种合同以自然月为单位，每个月自动循环执行。还有类似的企业间签订的长期采购合同，都是一种不断循环的合同。合同中规定的事件（或时间点）全部达成以后，自动循环回第一步，重新执行。
而复杂的条件控制能力就更常见了——合同中的违约条款就是条件控制能力。事件达成怎样，没有达成如何执行违约条款等，这些都需要合同拥有复杂的条件控制能力。
比特币中的交易是使用比特币区块链底层平台定义的一套脚本语言来写的，由于当初比特币区块链系统是按照一个数字货币的模型进行设计的，因此它并不需要这些复杂的能力。但是如果我们需要区块链技术在其他商业场合进行应用，很多时候就需要这些能力。比如我们利用以太坊平台来实现某个业务，那么整个流程是这样子的：
目前，关于智能合约的争议仍然是很多的。主要包含两方面：
1、合同本身是否是双方真实意思的表达
a）在现实世界中，我们撰写的合同除了受合同细节的约束外，还受到了外部法律和行业惯例的约束。而在智能合约中，外部法律和行业惯例如果不能严格的体现在合同中，那么合同就不是双方真实意思的表达了。
b）在现实世界中，我们撰写的合同通常是由律师或者法律专家来帮我们完成的。不同水平的法律专家，其完成的合同严谨程度是不一样的。同样在智能合约中，我们撰写的合同是由程序员帮我们完成的，程序员的水平决定了合同的严谨性。还有一点，程序通常都会有bug，这些bug是否会导致严重的损失，然而在bug没有被发现之前，都不得而知。
2、合同的仲裁机构是谁
a）在现实世界中，我们通常都会在合同中约定一旦发生纠纷，请哪个仲裁机构对合同进行仲裁。而在区块链中，尤其是公有链平台上的智能合约，一旦我们认为合同没有表达双方真实的意思，我们无法找到一个仲裁机构对合同进行仲裁。
b） 在联盟链中，由于各方各个节点的身份都是已知的，现实世界中的司法机构是可以介入智能合约纠纷的。但是这种介入有时候可能会影响整个联盟链系统的稳定性，这种情况下，怎样介入是一个技术问题，而这个技术问题又可能会带来新的bug。
