智能合约

1. 智能合约的历史

智能合约最初是由 Nick Szabo 在 20 世纪 90 年代后期的一篇名为 Formalizing and Securing Relationships on Public Networks(《公共网络上关系的格式化和安全保护》）的文章中提出的，但是 20 年之后，比特币的发明和区块链技术的发展才让人真正意识到智能合约的潜力和利益。Szabo 对智能合约的描述如下：

“智能合约是一种执行合约条款的电子交易协议，总的目的是满足共同的合约条件（例如支付条款、留置权、机密性，甚至是强制执行），最大限度地减少恶意和意外，并最小化相关的经济指标，包括降低欺诈损失、仲裁和执行成本以及其他交易成本。”

智能合约在 2009 年以有限的方式在比特币中得以实现。在比特币中，使用有限的脚本语言进行比特币交易，这使得即便在彼此无信任的点对点网络上，用户之间也可以转移价值，而无须可信任的中介。

2. 智能合约的定义

关于智能合约的标准定义目前尚无共识。智能合约的定义至关重要。

智能合约（Smart Contract) 是一种安全且不可中断的计算机程序，它代表可以自动执行和强制执行的协议。

如果对该定义进一步的分析，则可以看出，智能合约实际上是一种以计算机或目标机器可以理解的语言编写的计算机程序。此外，它还包含业务逻辑形式的各方之间的协议。当满足某些条件时，将自动执行智能合约，它们是可强制执行的。这意味着，即使存在对手，所有合约条款也会按照定义和预期执行。

强制执行（Enforcement) 是一个广义的术语，它涵盖了法律形式的传统强制执行，以及特定措施和控制措施的实现，这些措施无须任何调解即可执行合约条款。应当指出的是，真正的智能合约不应依赖传统的执行方法。相反，它们应该遵循 “代码即法律” 的原则。这意味着，不需要仲裁员或第三方来控制或影响智能合约的执行。

智能合约是自我执行的，而不是法律上可执行的。这个想法可能被认为是自由主义者的梦想，但它完全有可能实现并且符合智能合约的真正精神。

此外，智能合约是安全且不可中断的。这意味着，计算机程序的设计方式应使其具有容错性，并且可以在合理的时间内执行，即使外部因素不利，这些程序也应能够执行并保持健康的内部状态。

例如，一个典型的计算机程序以某种逻辑编码，并根据编码的指令执行操作。如果它所运行的环境或所依赖的外部因素偏离了正常或预期状态，则该程序可能会做出不确定性的反应，或仅仅是中止它。智能合约必须能够不受此类问题的影响。

安全性和不可中断的特性被认为是必要的或理想的特性。如果从一开始就将安全性和不可中断的特性包括在智能合约的定义中，那么长期来看它将提供更大的收益。这将使研究人员从一开始就专注于这些方面，并将有助于为进一步的研究奠定坚实的基础。

一些研究人员认为智能合约不必自动执行。相反，由于在某些情况下需要人工输入，因此只能称为“ 可自动化的” 。例如，合格的医疗专业人员可能需要对病历进行手动验证，在这种情况下，全自动方法可能效果不佳。

虽然在某些情况下确实需要人工输入和控制，但这并不是必需的。笔者认为，要使合约真正智能，就必须完全实现自动化。某些需要人工提供的输入可以而且应该通过 Oracle 将其自动化。

智能合约常通过使用状态机模型管理内部状态，这允许开发用于编写智能合给程序的有效框架。在该框架中，将根据某些预定义的标准和条件进一步完善智能合约的状态。

关于智能合约的代码是否可以作为法院接受的合约的问题，也正在进行辩论。智能合约的表达方式与传统的法律条文有所不同，尽管它们确实代表并强制执行了所有合约条款，但法院可能并不理解该代码。

这一难题引发了关于智能合约如何具有法律约束力的若干问题：

能否以法院容易接受和理解的方式发展智能合约？如何在代码中实现争议解决，有这种可能性吗？

此外，法规和合规性要求是一个要解决的问题。只有解决了这些问题，才能像使用传统法律文件一样有效地使用智能合约。

虽然智能合约被命名为 “智能”，但实际上它们并非真的智能，只能按编写好的代码执行。当然，这也没问题，因为这一特性可确保智能合给每次执行时都产生相同的输出。由于共识要求，在区块链平台中非常需要智能合约的这种确定性，即智能合约并不需要真正的智能，只要能够按其编程执行即可。

这自然也引发了一个问题，即如果现实世界和区块链世界之间出现了巨大差距，又该如何呢？在这种情况下，智能合约是无法理解自然语言的，而自然世界也无法理解代码。现在的问题是，如何在区块链上部署现实生活中的合约？如何建立现实世界与智能合约世界之间的桥梁。

上述问题实际上打开了各种可能性，例如使智能合约代码不仅可以被机器读取，也可以被人类阅读和理解。如果人和机器都能理解智能合约中编写的代码，那么在法律意义上可能更容易被接受，而不仅仅是除程序员以外的其他人都无法理解的一段代码。这已经成为智能合约一个比较热门的研究领域，并且在该领域已经进行了大量的研究工作，以回答有关语义、含义和智能合约解释的问题。

通过将智能合约代码和自然语言合同进行组合（将合同条款与机器可理解的元素链接在一起），目前已经完成了一些正式描述自然语言合同的工作，这是使用标记语言实现的。这种标记语言的一个示例称为法律知识交换格式（Legal Knowledge Interchange Format,LKIF),它是用于表示理论和证明的XML模式，该格式是在 2008 年的 ESTRELLA 项目中开发的。

在本质上，智能合约必须具有确定性，此属性将使智能合约可以由网络上的任意节点运行并获得相同的结果。智能合约在节点之间的输出即便略有不同，也将无法达成共识，并且关于整个区块链的分布式共识范式可能会失败。

此外，智能合约语言本身也应该是确定性的，只有这样才能确保智能合约的完整性和稳定性。从某种意义而言，确定性是指该语言中没有使用不确定性函数（不确定性函数会在各个节点上产生不同的结果）。

例如，以不同编程语言中的不同函数计算出的各种浮点运算可以在不同的运行环境中产生不同的结果，从而导致各种错误。这些情况在智能合约中都是非常不希望看到的，如果节点之间的结果不一致，那么将永远无法达成共识。

确定性函数可确保智能合约始终为特定输入产生相同的输出。换句话说，程序在执行时会产生可靠且准确的业务逻辑，这完全符合高级代码中编程的要求。

智能合约应具有以下4个属性：

可自动执行
强制执行
在语义上是完整的
安全且不可中止

在上述 4 个属性中，前两个是最低需求。在某些情况下，后两个属性可能不是必需的或是不可实现的，所以可以放宽要求。例如，金融衍生品合约也许不需要在语义上是完整的和不可中止的，但至少应该是可以自动执行和强制执行的。

另外，房产地契必须在语义上是完整的，要使其作为智能合约，其语言必须被计算机和人类都能理解。Ian Grigg 发明了李嘉图合约，从而解决了有关解释的问题。

3. 李嘉图合约

李嘉图合约（Ricardian Contract) 这一术语最初出现在 Ian Grigg 于 20 世纪 90 年代末提出的 7 层金融密码学（Financial Cryptography in 7 Layers) 中。这些合约最初用于名为 Ricardo 的债券交易和支付系统，其基本思想是编写一份法院和计算机软件都可以理解和接受的文档。李嘉图合约解决了通过互联网发行价值的挑战，它可以识别发行人（Issuer)，并在文件中记录合约的所有条款，以使其具有法律约束力。

李嘉图合约是具有以下若干属性的文件：

发行人提供给持有人（Holder) 的合约。发行人是卖方，持有人是买方。
由持有人所拥有的，由发行人管理的有价值的权利。
可由人类轻松阅读（和纸质合约一样）。
可由计算机程序读取（可解析，和数据库一样）
采用数字形式签名
包含密钥和服务器信息
与唯一的和安全的标识符相关联

注意：

以上信息基于 Ian Grigg 的原始定义，其网址如下：

http://iang.org/papers/ricardian_contract.html

实际上，李嘉图合约是通过产生一个文档来实现的，该文档包含法律文书形式的合约条款和一些必要的机器可读标签。首先，该文档由发行人使用私钥进行数字签名；其次，使用消息摘要函数（Message Digest Function,MDF) 对该文档进行哈希处理，以生成可以识别该文档的哈希；最后，该哈希在合约执行期间由各方进一步使用并签名以链接每个交易，因此标识符哈希可作为意图的证明。下图描述了李嘉图合约的过程，它通常被称为领结模型（Bowite Model)。

上图显示了以下要素：

文档左侧是法律领域，这是文档的来源。本文档包含法律文书形式的合约条款和一些必要的机器可读标签
在加密学领域，对文档进行哈希处理
获得的消息摘要被用作右侧会计领域的标识符

会计领域的要素代表业务中用于执行各种业务操作的任何会计、交易和信息系统。该流程的核心思想是，通过对文档进行哈希处理而生成的消息摘要首先用于创世交易（第一笔交易），然后在整个交易的合约执行过程中，在每笔交易中用作标识符。

通过这种方式，即可在原始书面合约和会计领域中的每笔交易之间创建一个安全链接。

李嘉图合约与智能合约的不同之处在于智能合约不包括任何合约文件，并且仅专注于合约的执行；而李嘉图合约则更关注包含产生合约法律文书的文档的语义丰富性。合约的语义可以分为两种：操作语义和指标语义。操作语义（Operational Semantics)类型定义合约的实际执行，正确性和安全性，它涉及完整合约的真实含义。一些研究人员区分了智能合约代码和智能法律合约，其中智能合约只与合约的执行有关。指称语义（Denotational Semantics) 类型则同时包含法律协议的指称语义和操作语义。

根据语义之间的差异对智能合约进行分类也是有意义的，但最好还是将智能合约视为能够在其中编写法律文书和代码（业务逻辑）的独立实体。

在比特币网络中，可以观察到基本智能合约（条件逻辑）的直接实现，它完全面向合约的执行和性能，而李嘉图合约则更适于生成人类可以理解的文档，其中一些部分是计算机程序也可以理解的。

如下图所示，可以将智能合约与李嘉图合约之间的关系视为法律语义与操作性能的对比。简而言之，就是以语义对比性能。

上图显示，李嘉图合约在语义上更加丰富，而智能合约则在性能上更加丰富。李嘉图合约的概念最初是由 Ian Grigg 在论文 On the intersection of Ricardian and smart contracts (《李嘉图和智能合约的交集》) 中提出的。

智能合约就是通过将两个元素（性能和语义）嵌入在一起而组成的，它完善了智能合约的理想模型。

李嘉图合约可以表示为包含 3 个对象的元组，即 Prose（文书）、Parameters (参数）和 Code (代码）。文书代表自然语言中的法律合约；代码代表程序，是计算机可理解的法律文书的表示形式；参数则将法律合约的相应部分加入等效代码中。

李嘉图合约已在许多系统中实现，如 CommonAccord、OpenBazaar、OpenAssets 和 Askemos 等。

4. 智能合约模板

智能合约可以在需要它的任何行业中实现，但是目前其大多数用例都与金融行业有关。这主要是由于区块链首先在金融业中发现了许多用例，并引起了人们对智能合约在金融业应用的极大研究兴趣，其研究远早于其他行业。

5. Oralce

请注意，这里的 Oracle 不是数据库系统，也不是开发该数据库系统的甲骨文公司。 Oracle 的本义是 “神谕或传达神谕的牧师”，所以它还引申出一个譬喻义 "能够提供有价值的信息的人"。智能合约生态系统中的 Oracle 就引用了这个譬喻义：Oracle 是一个接口，它可以提供有价值的信息，即可以将数据从外部源传递到智能合约。有些文档将 Oracle 翻译为 “预言机”。

Oracle 是智能合约生态系统中的重要组成部分。智能合约的局限性在于它们无法访问外部数据，而这可能是控制业务逻辑执行所必需的，例如，合约发放股息所需要的证券产品的股票价格。 Oracle 即可用于向智能合约提供外部数据。

对于智能合约来说，Oracle 就是每个智能合约的输入参数。所有智能合约都绕不开 Oracle 的输入数据，输入数据决定了智能合约的运行结果。通过向区块链中添加包含所需信息的交易，智能合约可以运行并始终获取相同的结果。

根据行业和需求，Oracle 可以提供不同类型的数据，从天气预报、真实新闻、公司行动到物联网（Internet of Things,IoT)设备的数据。 Oracle 是使用安全通道将数据传输到智能合约的受信任实体。

Oracle 能够对数据进行数字签名，以证明数据源是真实的。智能合约可以订阅 Oracle ,并且智能合约可以提取数据，或者 Oracle 可以将数据推送到智能合约。

Oracle 不能操纵由其提供的数据，而必须能够提供可靠的数据。即使 Oralce 是受信任的，在某些情况下由于操作仍可能导致数据不正确。因此，Oracle 必须无法更改数据，可以使用各种公证方案来提供此验证。

在该方法中，人们发现了一个可能在某些情况下并不理想的问题，那就是信任问题。如何信任第三方提供的数据的质量和真实性，这在金融领域中至关重要，因为在金融领域中，市场数据必须准确可靠。智能合约的设计者可以接受由信誉良好的大型第三方提供的 Oracle 数据，但是集中化的问题仍然是存在的。

这些信誉良好的大型第三方提供的 Oralce 数据可以称为标准 Oracle 或简单 Oracle。例如，气象数据的 Oracle 源可以是信誉卓著的天气报告机构，航班延误数据的 Oracle 源可以是机场信息系统，等等。

可以用来确保由第三方来源为 Oracle 提供的数据的可信度的另一个概念是：数据来自多个来源，甚至具有某些数据知识的用户或公众也可以提供所需的数据，然后可以汇总此数据。如果从多个来源获得大量相同的信息，则该数据很可能是正确的并且可以被信任。

由于去中心化要求而出现了另一种 Oracle,称为去中心化 Oracle (Decentralized Oracle)。可以基于某种分布式机制构建这些类型的 Oralce。还可以设想，Oracle 可以从另一个由分布式共识驱动的区块链中找到自己的源数据，从而确保数据的真实性。例如，一个运行某私有区块链的机构可以通过 Oracle 发布其数据，然后供其他区块链使用。

研究人员还引入了另一种硬件 Oracle 概念，即需要来自物理设备的真实数据。例如，它可以用于遥测和物联网，但是此方法需要硬件设备防篡改的机制。这可以通过提供物联网设备数据的加密证据（不可否认性和完整性）以及物联网设备上的防篡改机制来实现。在进行篡改尝试时，设备将无法使用。

下图显示了 Oracle 和智能合约生态系统的通用模型。

现在已经有可用的平台，使智能合约能够使用 Oracle 获取外部数据。Oracle 使用不同的方法将数据写入区块链，具体取决于所使用的区块链的类型。例如，在比特币区块链中，Oracle 可以将数据写入特定交易，而智能合约则可以在区块链中监控该交易并读取数据。

以下在线服务都可以提供 Oracle 服务：

https://www.oraclize.it/

https://www.realitykeys.com/

以下服务可以提供外部数据并可以使用智能合约进行支付：

https://smartcontract.com

所有这些服务旨在使智能合约能够获取执行和决策所需的数据。为了证明 Oracle 从外部源检索到的数据的真实性，可以使用 TLSnotary 之类的机制来产生数据源与 Oracle 之间的通信证明，这样可以确保从源中检索馈送到智能合约的数据。

6. 智能 Oracle

Ripple Labs (Codius) 还提出了智能 Oracle (Smart Oracle) 的想法，其原始白皮书的网址如下：

https://github.com/codius/codius-wiki/wiki/White-Paper

智能 Oracle 是与 Oralce 一样的实体，但是具有合约代码执行的附加功能。Codius 提出的 Smart Oracles 可使用 Google Native Client 运行，这是一个沙箱环境，用于运行不受信任的 x86 本机代码。

7. 在区块链上部署智能合约

智能合约可能会部署在区块链上，也可能不会部署在区块链上，但由于区块链提供的分布式和去中心化共识机制，将智能合约部署在区块链上是有意义的。

以太坊就是一个区块链平台示例，该平台原生支持智能合约的开发和部署。以太坊区块链上的智能合约通常是诸如去中心化自治组织（Decentralized Autonomous Organization,DAO) 之类更广泛应用的一部分。

相比之下，在比特比区块链中，比特币交易中的交易时间锁--例如 nLocktime 字段和 CHECKLOCKTIMEVERIFY（CLTV）、CHECKSEQUENCEVERIFY 脚本操作符--可以被视为智能合约简单版本的启动器。这些时间锁定使交易可以被锁定到指定时间或直到满足一定数量的区块，从而强制执行基本合约，即只有在满足某些条件（流逝的时间或达到的区块数）的情况下才能解锁特定交易。例如，可以实现 “3 个月后支付给 X 方 N 个比特币” 的条件。当然，这样的操作是非常有限的，所以应仅将其视为基本智能合约的示例。

除上述示例外，比特币脚本语言虽然受到限制，但仍可以用于构建基本的智能合约，一个基本的智能合约示例是给一个比特币地址提供赞助，任何演示了 “哈希碰撞攻击”的人都可以花费该地址的比特币。

这是在 Bitcointalk 论坛上宣布的一项竞赛，其中设置了比特币，以奖励设法为哈希函数找到哈希碰撞的人。仅在演示成功攻击后才能有条件地解锁该地址的比特币，该项赛事中的有条件解锁其实就是智能合约的基本类型。

还有很多区块链平台也都支持智能合约，如 Monax、Lisk、Counterparty、Stellar、Hyperledger fabric、corda 和 Axoni core。

可以用多种语言开发智能合约，但是关键的需求是确定性，这非常重要，因为无论智能合约代码在何处执行，它必须每次都能在任何地方产生相同的结果。另外，智能合约的确定性要求也意味着智能合约代码绝对没有错误。

目前已经开发了多种语言来构建智能合约，例如在以太坊虚拟机（Ethereum Virtual Machine,EVM) 上运行的 Solidity. 值得注意的是，已经有一些平台支持使用主流的语言进行智能合约的开发，例如 Lisk 支持使用 JavaScript 。还有一个示例是 Hyperledger fabric,该架构支持使用 Golang、Java 和 JavaScript 进行智能合约开发。