谈到区块链，必然离不开“智能合约”这个词区块链合约。我们在本系列的第一篇文章中就提到“智能合约”（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是否点击确认收货。因此，在这个合同中，预留了一个和外部交互的接口——确认收货。
除了和外部的交互能力外，比特币转账合同（脚本）的另一个重要缺陷是它不是图灵完备的区块链合约。这句话对于非计算机专业的人来说可能不太好理解，我们可以简单的理解为它没有循环能力和复杂的条件控制能力。
合同的循环能力在我们现实世界中是很常见的，例如我们和电信运营商签署的移动电话服务合同，通常就是一个循环合同区块链合约。这种合同以自然月为单位，每个月自动循环执行。还有类似的企业间签订的长期采购合同，都是一种不断循环的合同。合同中的规定的事件（或时间点）全部达成以后，自动循环回第一步，重新执行。
而复杂的条件控制能力就更常见了——合同中的违约条款就是条件控制能力区块链合约。事件达成怎样，没有达成如何执行违约条款等，这些都需要合同拥有复杂的条件控制能力。
比特币中的交易是使用比特币区块链底层平台定义的一套脚本语言来写的，由于当初比特币区块链系统是按照一个数字货币的模型进行设计的，因此它并不需要这些复杂的能力区块链合约。但是如果我们需要区块链技术在其他商业场合进行应用，很多时候就需要这些能力了。比如我们利用以太坊平台来实现某个业务，那么整个流程是这样子的：
目前，关于智能合约的争议仍然是很多的区块链合约。主要包含两方面：
一、合同本身是否是双方真实意思的表达区块链合约。
a) 业惯例的约束区块链合约。而在智能合约中，外部法律和行业惯例如果不能严格的体现在合同本身中，那么合同就不是双方真实意思的表达了。
b) 在现实世界中，我们撰写的合同通常是由律师或者法律专家来帮我们完成的区块链合约。不同水平的法律专家，其完成的合同严谨程度是不一样的。同样在智能合约中，我们撰写的合同是由程序员帮我们完成的，程序员的水平决定了合同的严谨性。还有一点，程序通常都会有bug，这些bug是否会导致严重的损失，在bug没有被发现之前，都不得而知。
二、合同的仲裁机构是谁
a) 在现实世界中，我们通常都会在合同中约定一旦发生纠纷，请哪个仲裁机构对合同进行仲裁区块链合约。而在区块链中，尤其是公有链的平台上的智能合约，一旦我们认为合同没有表达双方真实的意思，我们无法找到一个仲裁机构对合同进行仲裁。
b) 在联盟链中，由于各方各个节点的身份都是已知的，现实世界中的司法机构是可以介入智能合约纠纷的区块链合约。但是这种介入有时候可能会影响整个联盟链系统的稳定性，这种情况下，怎样介入是一个技术问题，而这个技术问题又可能会带来新的bug。
