智能合同
本章介绍了智能合约。这个概念并不新鲜，但是，随着区块链的出现，人们对这个概念的兴趣又恢复了，现在这是区块链空间中一个活跃的研究领域。由于智能合同可以通过降低交易成本和简化复杂的合同为金融服务行业带来成本节约的好处，各种商业和学术机构正在进行严格的研究，以尽快使智能合同的实施变得简单和实用。
历史
智能合约最初是由 Nick Szabo 在 20 世纪 90 年代末的一篇名为的文章中提出的，这篇文章描述了公共网络上的关系的形式化和安全性，但直到近 20 年后，随着比特币的发明和随后区块链技术的发展，智能合约的真正潜力和好处才被真正认识到。Szabo 对智能合约的描述如下:
“智能合同是一种执行合同条款的电子交易协议。总体目标是满足常见的合同条件(如支付条款、留置权、保密性，甚至强制执行)，最大限度地减少恶意和意外的例外，并最大限度地减少对可信中介的需求。相关的经济目标包括降低欺诈损失、仲裁和执行成本以及其他交易成本。”
Szabo 撰写的原文可在http://firstmonday.org/ojs/index.php/fm/article/view/548获得。
这种智能合约的想法在 2009 年以有限的方式在比特币中实现，使用有限脚本语言的比特币交易可用于在用户之间转移价值，通过点对点网络，用户不一定相互信任，也不需要可信的中介。
定义
对于智能合约的标准定义，目前还没有达成共识。有必要定义什么是智能合约，以下是我尝试提供的智能合约的通用定义:
智能合同是一种安全且不可阻挡的计算机程序，代表一种可自动执行和实施的协议。
剖析这个定义进一步揭示了智能合约实际上是一个用计算机或目标机器能够理解的语言编写的计算机程序。此外，它以业务逻辑的形式包含各方之间的协议。另一个基本思想是，当满足某些条件时，智能合约会自动执行。它们是可执行的，这意味着所有的合同条款都是按照定义和预期执行的，即使是在有对手的情况下。
强制执行是一个更广泛的术语，包括法律形式的传统强制执行，以及实施具体的措施和控制，使之有可能在不需要任何调解的情况下执行合同条款。应当指出，真正的智能合同不应依赖于传统的执行方法。相反，他们应该遵循代码即法律的原则，这意味着不需要仲裁人或第三方来控制或影响智能合同的执行。智能合同是自我执行的，而不是法律强制执行的。这个想法可能被视为自由主义者的梦想，但它是完全可能的，并且符合智能合同的真正精神。
此外，它们是安全的和不可阻挡的，这意味着这些计算机程序需要以这样一种方式设计，即它们是容错的并且在合理的时间内是可执行的。这些程序应该能够执行并保持健康的内部状态，即使外部因素不利。例如，想象一个典型的计算机程序，它用一些逻辑编码，并根据其中编码的指令执行。但是，如果它运行的环境或它所依赖的外部因素偏离了正常或预期的状态，程序可能会任意做出反应或干脆中止。智能合约必须避免这类问题。
安全和不可阻挡可能被认为是需求或期望的特性，但是从长远来看，如果安全和不可阻挡的属性从一开始就包含在智能契约定义中，它将提供更大的好处。这将使研究人员从一开始就专注于这些方面，并有助于建立坚实的基础，以便进一步研究。一些研究人员还提出，智能合约不需要自动执行；相反，它们可以是所谓的自动化，因为在某些情况下需要人工输入。例如，合格的医疗专业人员可能需要对医疗记录进行人工验证。在这种情况下，完全自动化的方法可能不是最好的。虽然在某些情况下人类的输入和控制确实是可取的，但这并不是必须的；而且，在作者看来，要想让合同真正智能，它必须完全自动化。一些需要由人提供的输入可以也应该通过使用 Oracles 来自动化。神谕将在本章后面更详细地讨论。
智能合约通常通过使用状态机模型管理其内部状态来运行。这允许为智能契约编程开发一个有效的框架，其中契约的状态基于一些预定义的标准和条件被进一步推进。
关于《守则》是否可以作为合同在法庭上被接受的问题，也正在进行辩论。智能合同在表述上不同于传统的法律散文，尽管它们确实代表并执行所有的合同条款，但法院并不理解该代码。这种困境提出了几个关于智能合同如何具有法律约束力的问题:它能否以一种在法庭上容易接受和理解的方式发展？如何在准则内实施争议解决，是否可能？此外，在智能合同可以像传统法律文档一样有效地使用之前，法规和合规性要求是另一个需要解决的问题。
尽管智能合约被命名为 smart，但它们实际上只做它们被编程要做的事情，这很好，因为智能合约的这一特性确保智能合约每次执行时都产生相同的输出。由于一致的共识要求，智能合约的确定性在区块链平台中非常受欢迎。这意味着智能合约并不是真正的智能，它们只是在做它们被编程要做的事情。
现在这就产生了一个问题，现实世界和区块链世界之间出现了巨大的差距。在这种情况下，自然语言无法被智能合约理解，同样，代码也无法被自然世界理解。因此，出现了一些问题，如何在区块链上部署现实生活中的合同？如何在现实世界和智能合约世界之间建立桥梁？
前面的问题提供了各种可能性，比如让智能合同代码不仅可以被机器读取，也可以被人读取。如果人类和机器都能理解智能合同中的代码，这在法律环境中可能更容易被接受，而不是只有程序员才理解的一段代码。这个理想的属性是一个成熟的研究领域，在这个领域已经花费了大量的研究工作来回答关于合同的语义、意义和解释的问题。
已经做了一些工作，通过将合同条款与机器可理解的元素链接起来，将智能合同代码和自然语言合同结合起来，来正式描述自然语言合同。这是使用标记语言实现的。这种标记语言的一个例子叫做法律知识交换格式 ( LKIF )，这是一种用于表示理论和证据的 XML 模式。它是 2008 年在 ESTRELLA 项目下开发的。
更多信息可以在 https://doi.org/10.1007/978-3-642-15402-7_30 的一篇研究论文中找到。
智能合同本质上要求具有确定性。该属性将允许网络上的任何节点运行智能合约，并获得相同的结果。如果节点之间的结果稍有不同，那么就无法达成共识，在区块链问题上的分布式共识的整个范例都会失败。此外，还希望契约语言本身是确定性的，从而确保智能契约的完整性和稳定性。确定性是指语言中没有使用非确定性函数，这种函数会在不同的节点上产生不同的结果。
我们举个例子，各种编程语言的各种函数计算的各种浮点运算，在不同的运行时环境下可以产生不同的结果。另一个例子是 JavaScript 中的一些数学函数，它们可以在不同的浏览器上对相同的输入产生不同的结果，从而导致各种错误。这在智能契约中是非常不可取的，因为如果节点之间的结果不一致，那么将永远无法达成共识。
确定性功能确保智能合约总是为特定输入生成相同的输出。换句话说，程序在执行时会产生一个可靠而准确的业务逻辑，它完全符合高级代码中编程的要求。
总之，智能合约具有以下四个属性:
- 可自动执行
- 可实施的
- 语义合理
- 安全且不可阻挡
前两个属性是最低要求，而后两个在某些场景中可能是不需要的或不可实现的，可以放宽。例如，金融衍生品合约也许不需要在语义上是合理的和不可阻止的，但至少应该在基本层面上是可自动执行和可强制执行的。另一方面，地契需要在语义上是合理和完整的，因此，为了将其实现为智能契约，该语言必须能被计算机和人理解。伊恩·格里格用他发明的李嘉图契约解决了这个解释问题，我们将在下一节更详细地讨论这个问题。
李嘉图契约
李嘉图契约最初是由伊恩·格里格在论文七层中提出的。这些合同最初用于一个名为李嘉图的债券交易和支付系统。基本思想是写一份法庭和计算机软件都能理解和接受的文件。李嘉图合约解决了通过互联网发行价值的挑战。它识别发行者并在文档中捕获合同的所有条款，使其成为具有法律约束力的合同。
李嘉图合约是一种具有以下几个特性的文件:
- 发行人向持有人提供的合同
- 由持有者持有并由发行者管理的有价值的权利
- 人们容易阅读(就像纸上的合同)
- 程序可读(可解析，像数据库一样)
- 数字签名
- 携带密钥和服务器信息
- 与唯一且安全的标识符相关联
上述信息基于伊恩·格里格在http://iang.org/papers/ricardian_contract.html的原始定义。
实际上，合同是通过生成一个文档来实现的，该文档以法律散文的形式包含合同条款和所需的机器可读标签。该文档由发行者使用他们的私钥进行数字签名。然后，使用消息摘要函数对该文档进行哈希处理，以产生能够识别该文档的哈希。然后，在履行合同期间，各方进一步使用和签署该散列来链接每一笔交易，从而将标识符散列用作意图的证据。下图对此进行了描述，通常称为蝴蝶结模型。
该图显示了一些元素:
- 文件来源左侧的法律世界。这份文件是一份用法律语言写成的书面合同，带有一些机器可读的标签。
- 然后对该文档进行哈希处理。
- 由此产生的消息摘要被用作整个会计世界的标识符，如图右侧所示。
会计世界元素代表任何会计、交易和信息系统，这些系统在业务中用于执行各种业务操作。这个流程背后的想法是，通过散列文档生成的消息摘要首先用于所谓的起源事务或第一个事务，然后在合同的整个操作执行过程中用作每个事务的标识符。
通过这种方式，在原始书面合同和会计领域的每一笔交易之间建立了安全的联系:
李嘉图合同，领结图
李嘉图合同不同于智能合同，因为智能合同不包括任何合同文件，仅关注合同的执行。另一方面，李嘉图契约更关心包含契约法律散文的文档的语义丰富性和生产。契约的语义可以分为两种类型:操作语义和指称语义。
第一种类型定义了契约的实际执行、正确性和安全性，而后者关注的是完整契约的真实含义。一些研究人员区分了智能合同代码和智能法律合同，智能合同只涉及合同的执行。第二种类型包括法律协议的指称语义和操作语义。根据语义之间的差异对智能合约进行分类可能是有意义的，但最好将智能合约视为一个独立的实体，能够在其中编码法律散文和代码(业务逻辑)。
在比特币中，可以观察到基本智能合约(条件逻辑)的直接实现，它完全面向合约的执行和履行，而李嘉图合约更适合于生成人类可以理解的文档，其中一些部分是计算机程序可以理解的。这可以看作是法律语义与操作性能(语义与性能)的对比，如下图所示。该图显示李嘉图契约在语义上更丰富，而智能契约在性能上更丰富。这个概念最初是由 Ian Grigg 在他的论文中提出的，关于李嘉图和智能合约的交集。
解释性能与语义的图表是正交的问题，如 Ian Grigg 所述；略有修改，以显示两轴上的 different 合同类型示例
智能合约将这两个元素(性能和语义)嵌入在一起，从而完成了智能合约的理想模型。
一个李嘉图契约可以表示为三个对象的元组，即散文、参数、和代码。散文用自然语言表现法律契约；代码代表程序，它是法律条文的计算机可理解的表示；和参数将合法契约的适当部分连接到等价代码。
李嘉图契约已经在许多系统中实现，如 CommonAccord、OpenBazaar、OpenAssets 和 Askemos。
智能合同模板
智能合约可以在任何需要的行业中实现，但当前大多数用例都与金融行业相关。这是因为区块链首先在金融行业发现了许多用例，并在其他行业之前很久就在金融行业引发了巨大的研究兴趣。专门针对金融行业的智能合同领域的最新工作提出了智能合同模板的概念。这个想法是建立标准模板，提供一个框架来支持金融工具的法律协议。
这个想法是由 Clack 等人在他们 2016 年发表的论文中提出的，名为智能合同模板:基础、设计景观和研究方向。该论文还提出，应该构建特定于领域的语言来支持智能合同模板的设计和实现。已经提出了一种称为 CLACK 的语言，一种用于扩充合同知识的通用语言，并且已经开始研究开发这种语言。这种语言旨在非常丰富，并提供各种各样的功能，从支持法律散文到能够在多种平台上执行和加密功能。
Clack 等人最近致力于开发支持可依法执行的智能合同的智能合同模板。该提案已在他们的研究论文智能合同模板:基本要求和设计选项中进行了讨论。本文的主要目的是研究如何使用标记语言将法律散文与代码链接起来。它还介绍了如何创建、格式化、执行和序列化智能法律协议，以便进行存储和传输。这是一项正在进行的工作，也是一个有待进一步研究和开发的开放领域。
金融行业中的契约并不是一个新概念，各种特定于领域的语言 DSL 已经在金融行业中使用，以提供特定领域的特定语言。例如，有一些 DSL 可用于支持保险产品的开发，代表能源衍生品，或者用于构建交易策略。
在http://www.dslfin.org/resources.html可以找到金融领域特定语言的完整列表。
理解特定领域语言的概念也很重要，因为可以开发这种类型的语言来编写智能合约。这些语言是为特定的应用程序或感兴趣的领域开发的，表达能力有限。领域专用语言(DSL)不同于通用编程语言 ( GPLs )。DSL 有一小部分功能，这些功能对于它们要使用的领域来说是足够的和优化的，并且与 GPL 不同，通常不用于构建通用的大型应用程序。
基于 DSL 的设计理念，可以设想这种语言将被专门开发来编写智能合同。有人已经做了一些工作，Solidity 就是这样一种语言，它被以太坊区块链公司引入来编写智能合同。Vyper 是最近为以太坊智能联系人开发引入的另一种语言。
这种用于智能合同编程的领域特定语言的思想可以进一步扩展到图形领域特定语言，这是一种智能合同建模平台，领域专家(不是程序员，例如前台经销商)可以使用图形用户界面和画布来定义和绘制金融合同的语义和性能。一旦绘制并完成了流程，就可以首先对其进行模拟测试，然后将其从同一系统部署到目标平台，该平台可以是区块链。这也不是一个新概念，Tibco StreamBase 产品中使用了类似的方法，这是一个基于 Java 的系统，用于构建事件驱动的高频交易系统。
建议还应在开发高级 DSL 的领域进行研究，这些 DSL 可用于在用户友好的图形用户界面中对智能合同进行编程，从而允许非程序员领域专家(例如，律师)设计智能合同。
神谕
甲骨文是智能合约生态系统的重要组成部分。智能契约的局限性在于它们不能访问外部数据，而控制业务逻辑的执行可能需要外部数据；例如，合同要求支付股息的证券产品的股价。Oracles 可用于向智能合约提供外部数据。Oracle 是从外部来源向智能合同提供数据的接口。
根据行业和需求的不同，Oracles 可以交付不同类型的数据，从天气预报、真实世界的新闻和企业行动到来自物联网 ( 物联网)设备的数据。Oracles 是使用安全通道将数据传输到智能合约的可信实体。
Oracles 还能够对数据进行数字签名，证明数据的来源是可信的。然后，智能合约可以订阅 Oracle，智能合约可以拉取数据，或者 Oracle 可以将数据推送到智能合约。同样必要的是，神谕不应该能够操纵它们提供的数据，而必须能够提供可信的数据。尽管 Oracles 是可信的，但在某些情况下，由于操纵，数据仍然可能是不正确的。因此，Oracles 无法更改数据是必要的。这种验证可以通过使用各种公证方案来提供，这将在本章后面讨论。
在这种方法中，已经可以看出一个问题，在某些情况下这可能是不可取的，这就是信任问题。您如何信任第三方提供的数据的质量和真实性？在金融界尤其如此，市场数据必须准确可靠。对于一个聪明的合同设计者来说，接受由一个大型的、有信誉的、可信任的第三方提供的 Oracle 数据可能是可以接受的，但是集中化的问题仍然存在。这些类型的神谕可以被称为标准或简单神谕。例如，数据的来源可以是声誉良好的天气预报机构或转播航班延误的机场信息系统。
另一个可以用来确保第三方来源为 Oracles 提供的数据的可信度的概念是，数据来源于多个来源；甚至可以访问和了解某些数据的用户或公众成员也可以提供所需的数据。然后可以汇总这些数据，如果从多个来源获得大量相同的信息，那么这些数据很有可能是正确的和可信的。
另一种类型的 Oracle 本质上是由于去中心化的需求而出现的，称为去中心化Oracle。这些类型的预言可以基于某种分布式机制来构建。还可以设想，先知可以从另一个区块链找到自己的源数据，这是由分布式共识驱动的，从而确保数据的真实性。例如，一个运行其私有区块链的机构可以通过 Oracle 发布其数据馈送，然后其他区块链可以使用该数据馈送。
当需要来自物理设备的真实世界数据时，研究人员还引入了硬件预言的另一个概念。例如，这可以用于遥测和物联网。然而，这种方法需要一种机制，其中硬件设备是防篡改的。这可以通过在物联网设备上提供物联网设备数据的加密证据(不可否认性和完整性)和反篡改机制来实现，这使得设备在篡改尝试的情况下变得无用。
下图显示了 Oracle 和智能合同生态系统的一般模型:
Oracle 和智能合同生态系统的通用模型
现在有一些平台可以支持智能合约使用 Oracle 获取外部数据。Oracle 使用不同的方法将数据写入区块链，具体取决于使用的区块链类型。例如，在比特币区块链中，甲骨文可以向特定交易写入数据，智能合约可以在区块链中监控该交易并读取数据。
各种在线服务，如 http://www.oraclize.it/的和 https://www.realitykeys.com/的都可以提供甲骨文服务。https://smartcontract.com/的另一项服务也可用，它提供外部数据和使用智能合同进行支付的能力。
所有这些服务都旨在使智能合约能够获得执行和决策所需的数据。为了证明 Oracle 从外部源检索到的数据的真实性，可以使用 TLSnotary 之类的机制来证明数据源和 Oracle 之间的通信。这确保了从源检索反馈到智能合约的数据。
更多关于 TLSnotary 的细节可以在这里找到:https://tlsnotary.org/。
智能甲骨文
Ripple labs (codius) 也提出了智能甲骨文的想法。其原始白皮书可在https://github . com/codius/codius/wiki/Smart-Oracles:——一个简单、强大的智能合同方法获得。智能 Oracle 是与 Oracle 一样的实体，但是增加了契约代码执行的能力。Codius 提出的智能 Oracles 使用 Google Native Client 运行，这是一个运行不可信 x86 本机代码的沙箱环境。
在区块链上部署智能合约
智能合同可能部署在区块链上，也可能不部署在其上，但是由于区块链提供的分布式和分散的共识机制，在区块链上部署智能合同是有意义的。以太坊是区块链平台的一个例子，它本身支持智能合约的开发和部署。以太坊区块链上的智能合约通常是更广泛应用的一部分，如去中心化自治组织 ( DAOs )。
作为比较，在比特币区块链中，比特币交易中的nLocktime字段和 CHECKLOCKTIMEVERIFY (CLTV)、CHECKSEQUENCEVERIFY 脚本操作符等交易时间锁可以被视为智能合约简单版本的使能器。这些时间锁使事务能够被锁定到指定的时间或一定数量的块，从而强制执行一个基本契约，即只有在满足某些条件(经过的时间或块的数量)的情况下，某个事务才能被解锁。比如可以实现“3 个月后支付 X 方，N 笔比特币”等条件。然而，这是非常有限的，并且应该仅被视为基本智能合约的示例。除了上面提到的例子，比特币脚本语言虽然有限，但可以用来构造基本的智能合约。一个基本智能合约的例子是，为一个比特币地址提供资金，任何证明“哈希碰撞攻击”的人都可以使用这个地址。这是一场在 Bitcointalk 论坛上宣布的比赛，比特币被设置为对任何设法找到哈希冲突的人的奖励(我们在第六章、公钥加密中讨论了这个概念)。这种只有在证明攻击成功的情况下才有条件解锁比特币的做法，是智能合约的一种基本类型。
这个想法是在 Bitcointalk 论坛上提出的，更多信息可以在https://bitcointalk.org/index.php?topic=293382.0找到。这也可以被认为是智能合约的一种基本形式。
各种其他区块链平台支持智能合约，如 Monax、Lisk、Counterparty、Stellar、Hyperledger fabric、corda 和 Axoni core。智能合约可以用多种语言开发。然而，关键的要求是确定性，这非常重要，因为无论智能合约代码在哪里执行，它都会随时随地产生相同的结果。智能合约的确定性的这一要求也意味着智能合约代码绝对没有错误。智能合同的确认和验证是一个活跃的研究领域，该主题的详细讨论将在第 16 章、可扩展性和其他挑战中介绍。人们开发了各种语言来构建智能合约，如 Solidity，它运行在以太坊虚拟机 ( EVM )上。值得注意的是，有些平台已经支持智能合约开发的主流语言，比如支持 JavaScript 的 Lisk。然而，另一个突出的例子是 Hyperledger fabric，它支持 Golang、Java 和 JavaScript 进行智能合同开发。
刀
DAO 是众筹金额最高的项目之一，它始于 2016 年 4 月。这是一套智能合约，旨在提供一个投资平台。由于代码中的一个错误，这在 2016 年 6 月被黑客攻击，相当于 5000 万美元的资金被从 DAO 转移到另一个账户。
尽管上面使用了“黑客”一词，但这并不是真正的黑客，智能合约只是做了要求它做的事情。这只是 DAO 的程序员没有预见到的一个无意的行为。这一事件导致以太坊上的硬分叉从攻击中恢复。应该注意的是，代码就是法律或不可阻挡的智能合约的概念应该以某种怀疑的态度来看待，因为这些概念的实现还不够成熟，不足以值得完全和不容置疑的信任。这从最近的事件中显而易见，以太坊基金会通过引入一个硬叉子能够停止并改变道的执行。尽管引入这种硬分叉是出于真正的原因，但它违背了真正的分权精神，而且代码就是法律的概念。另一方面，对这种硬叉的反抗和一些决定继续在原链上采矿的矿工，导致了以太坊经典的产生。这条链子是原始的非分叉以太坊区块链，其中代码仍然是法律。
这一攻击凸显了不正式和彻底测试智能合约的危险。它还强调了为智能合同的开发和验证开发一种正式语言的绝对必要性。这次攻击也凸显了彻底测试以避免 DAO 所经历的问题的重要性。围绕智能合约开发语言，最近在以太坊发现了各种漏洞。因此，最重要的是开发一个标准框架来解决所有这些问题。一些工作已经开始，例如，在 https://securify.ch 的一项在线服务，它提供了正式验证智能合同的工具。然而，这个领域已经成熟，可以进行更多的研究来解决智能合约语言的局限性。
摘要
本章首先介绍了智能合同的历史，然后详细讨论了智能合同的定义。由于在智能合同的标准定义上没有一致意见，我们试图引入一个包含智能合同关键内容的定义。
还介绍了李嘉图合同，并解释了李嘉图合同和智能合同之间的区别，强调李嘉图合同涉及合同的定义，而智能合同面向合同的实际执行。
讨论了智能合同模板的概念，学术界和工业界目前正在就这一主题进行高质量的积极研究。还讨论了关于创建高级特定领域语言的可能性的一些想法，以创建智能合同或智能合同模板。在本章的后面几节中，介绍了 Oracles 的概念，然后简要讨论了 DAO，以及 DAO 和智能契约中的安全问题。
关于智能合约的形式验证和安全性的讨论将在本书后面的第 16 章、可伸缩性和其他挑战中介绍。
在下一章，你将会了解到对称加密的概念、理论和实践方面
