区块链技术精华：五种智能合约支持平台
点击上方
“Unitimes” 可以订阅哦！
unitimes.io
全球视角，独到见解
大家已经看到，区块链正在改变我们的世界。
区块链解决了人类一直面对的一个重大问题，信任问题。区块链可为任何需信任的事物创建一种不可更改的追溯印迹，由此解决信任的问题。
当然，该技术的强大还不止于此。
它在上述特性上继续扩展，用以创建一经制定就必须准守的规则，其中的每个行为都会产生相应的反应。其实，就是智能合约。
本文列出了五种支持或是用于开发智能合约的平台或项目，它们均在不断的演进中。如果读者发现本文存在任何遗漏或错误，希望能在评论中提出。
附： 本文对智能合约平台 / 项目的评估，主要考虑的是影响智能合约功能的一些因素，而不是整体功能评估。
1. 以太坊（Ethereum）
优点：
图灵完备。
拥有可能是规模最大的开发人员社区。
最支持智能合约的平台。
不足：
它使用 Solidity 语言。与 C++、C#、Python 等现代开发语言相比，Solidity 并不具有优势。
如果智能合约编写的效率不高，那么实现代价巨大。
智能合约语言：Solidity
现状： 活跃。
说明：
以太坊是首批在区块链中引入智能合约概念的平台之一，并得到了开发者社区的最大支持。它宣称实现了图灵完备的智能合约平台。合同代码由每位以太坊网络中的矿工在 EVM（以太坊虚拟机）上执行。它是最广为使用的区块链项目平台。
尽管以太坊平台可安全使用，但是其因用户实现代价问题而备受批评。此外，以太坊平台缺乏可扩展性，会导致交易速度不高，不适合当前的现实世界应用。
平台使用Solidity语言。Solodity 可以很好地实现图灵完备，但是缺乏现代语言的灵活性，存在的问题包括：
输入和返回参数不支持多维数组（例如，字符串数组）。对此问题存在替代解决方案。
智能合约函数支持的参数数量有限（不能多于十六个）。否则会给出“stack too deep”错误。
上述问题表明，为适应现代语言的灵活性，该智能合约语言依然需要进一步发展。
有资料列出了Solidity 存在的 62 个问题。
学习资源： CryptoZombies 主页，Solidity 官方文档，OpenZeppelin，以太坊的 Medium 博客。
2. Quorum
优点：
图灵完备。
通过使用constellation，添加了支持网络中两个以上参与者间发送私有交易的特性，因此更适用于企业用户。
将瓦斯（GAS）价格降至零，但依然保持瓦斯限制。这样 Quorum 在利用瓦斯限制所提供的安全特性的同时，将交易代价（即瓦斯价格 * 瓦斯限制）降至零。
不足：
开发人员社区相对不大。
因为也使用 Solidity 作为合约语言，因此具有和以太坊同样的不足之处。
智能合约语言： Solidity
现状： 活跃
说明：
简而言之，Quorum 是以太坊智能合约平台的一种版本，它提供免费的交易，并且还能够使用constellation完成各参与方间的私有交易。
Quorum 维护了两个账本，即公开的和私有的。公开账本被公开交易修改，私有账本只针对私有交易所涉及的各方，被私有交易修改。
Quorum 与以太坊联系密切，它们使用同一核心平台和语言。因此 Quorum 也同样继承了以太坊智能平台的优缺点。
学习资源： Quorum 文档，CryptoZombies，Solidity 文档，OpenZeppelin。
3. Wanchain
优点：
在正常以太坊智能合约平台特性之外，添加了用户隐私特性。
适用于跨链交易。
不足：和以太坊一样。
智能合约语言： Solidity
现状： 活跃
说明：
Wanchain 是以太坊的一个分支，因此它继承了以太坊的许多属性。此外，它还提供了用户隐私特性。Wanchain 侧重于通过区块链实现当前金融模型的数字化。
Wanchain 的隐私特性是通过使用环签名（ring signature）实现的，环签名可实现交易签名者完全匿名，并为接收者提供了验证发件者签名的能力。此外，Wanchain 还提供一次性地址（OTA，One Time Addresses）选项，实现了进一步的匿名功能。
Wanchain 的分布式账本建立在以太坊的功能之上，因此任何以太坊 DApp 都可以在 Wanchain 上运行，而无需更改任何代码。为了增强这些应用程序，Wanchain 提供了许多拥有扩展跨链功能和改善隐私保护的 API，扩展了 DApp 的功能。
学习资源： Wanchain 上实现智能合约的文档，Wanchain 代币，CryptoZombies、Solidity 文档，OpenZeppelin，Oliver Birch 的 Medium 博客。
4. æternity
优点：
引入了新的智能合约语言和 VM，实现代码的快速安全执行。
使用状态通道和高效的方式执行合约，维持低代价交易。
通过提供一种版本的 EVM，简化了将 EVM 合约迁移到æternity。
智能合约语言： Sophia，Solidity，Varna
现状： 活跃
说明：
æternity 智能合约的既定功能目标是支持在链上执行代码。也就是说，代码执行由矿工验证，并且可以改变链状态。
æternity 智能合约的设计和实施还具有下述非功能性目标，按重要性顺序列出为：
合约的执行应该是安全的。
合约的执行应该是高效的、可扩展的。
合约的执行应该是低代价的。
具有从以太坊智能合约迁移的简单方式。
目标一：合约执行应该是安全的
安全合约指的是用户可以指定并自动地验证合约的属性。
为了实现安全合约，æternity 设计了一种新的功能语言 Sophia，以及一种新的安全虚拟机 FTWVM。
目标二：合约执行应该是高效和可扩展的
为实现可扩展的解决方案，æternity 提供了状态通道（State Channel）和一种新的共识算法。
为实现高效的合约执行，æternity 提供了一种非常高层的语言，支持快速、直接地执行简单的合约。对于更高级的合约，可使用 Sophia 语言。Sophia 将会编译为一个专用于执行 Sophia 合约的虚拟机。该虚拟机也是一种高层虚拟机，其中具有操作区块链和 Sophia 数据结构的指令，无需显式管理堆栈和内存。
æternity 也使用一种称为“Varna”的高层智能合约语言。该语言类似于比特币的脚本语言，但是不提供循环和固定的瓦斯价格。Varna 使用自身的虚拟机 HLM（High Level Machine），代码直接被节点软件执行。Varna 设计实现高速的日常合约。
目标三：合约执行应该低代价
合约执行的代价最终取决于矿工和用户，但是通过提供状态通道，实现了一种高效的合约执行方式，由此维持了简单高层合约语言的低执行代价。
目标四：具有迁移以太坊智能合约的简单方式
æternity 通过提供一个版本的 EVM，简化了从 EVM 合约迁移到æternity。
学习资源： 智能合约文档，Sophia 文档，Sophia 简介，æternity 的 Medium 博客
5. Zen
优点：
完备性（参见下面给出详细解释）。
鉴于智能合约语言是“独立设计”的，因此更难以出错，并且语言的表达力完全可以用于“形式化验证”（参见下面给出的详细解释）。
智能合约语言： F*
现状： 活跃
说明：
与其它智能合约项目相比，Zen 协议提供了一种完全不同的智能合约实现方式。
下面从智能合约的定义开始解释。从最抽象的意义上看，智能合约是一种设计运行于去中心化环境中的计算机程序。也就是说，智能合约的运行是用于确认区块链的共识。在比特币中，智能合约实现为Bitcoin Scripts形式，用于验证交易正确与否。在以太坊中，智能合约实现为 EVM 字节码形式，用于更改 EVM 的状态。
Bitcoin Script 的局限性在于它并非“图灵完备”的，也就是说，它不能表达所有计算机程序。如果我们想要在智能合约中表达任意逻辑，那么合约语言必须可执行任意逻辑，这样才能确认共识。图灵完备语言具备表达任何“不停止”程序的能力，即永远不会停止执行的程序。通常，我们并不知道一个程序是否会完成并终止，或是程序需要多长时间才会终止，执行程序需要多少计算资源。正是因为我们不知道执行程序所需的资源，因此不能使用非图灵完备语言确定共识。一个程序可能不会停止，这意味着也无法确定共识。
以太坊的 EVM 相比 Bitcoin Script 更具表达力。EVM 为每个 EVM 字节码指令关联了一个“瓦斯价格”（GAS Cost）。用户支付一定量的“瓦斯”，EVM 就开始执行智能合约指令。EVM 首先计算一条指令的瓦斯价格，如果瓦斯量足够继续执行，那么 EVM 将从用户支付的瓦斯量中扣除所需瓦斯价格，执行指令并继续。如果在指令执行完成前瓦斯量用尽，那么执行指令将会失败。使用这种方式，EVM 可以表达几乎所有的计算。以太坊智能合约的唯一局限性在于合约必须最终终止，因为用户不会为无限循环计算的执行而无限量地支付瓦斯。在实际运行中，我们很少关注那些不会终止的程序，因此这一局限性制基本不构成问题。
EVM 解释字节码指令和追踪瓦斯消耗的过程是非常低效的。对于每条指令，EVM 必须查看该指令的瓦斯价格，检查剩余瓦斯量是否充足，并从剩余瓦斯量中扣除所需瓦斯价格。使用这种执行模型，很难以优化改进运行时间。
以太坊中所有智能合约必须终止的限制是有意义的。实现所有程序必须终止的语言，事实上并非图灵完备的，只是“完备”而已。Zen 在表达智能合约中使用了一种完备的语言，而不是依赖于某种通过追踪瓦斯价格确保完备性的执行模型。完备语言并非绝对适用于表达包括循环和递归在内的所有逻辑，Zen 协议的问题也正在于此。
Zen 的智能合约语言是一种“依赖类型的语言”（Dependently Typed）。也就是说，每个表达式必须具有一个类型，并且类型依赖于表达式和类型。依赖性类型系统的表达力足以用于实现“形式化验证”。这些类型可表达一个表达式中的任意属性。例如，尽管在一些基本类型语言中，我们可以定义数字 3 的类型为“Integer”。但是在一些独立类型语言中，数字 3 也可以定义为“Prime Integer”类型，或是定义为“小于 10 的整数”类型。
如果类型不正确，那么类型化语言会在编译时报错。而非类型化语言则不会这样。如果程序表达了错误的资源消耗或是错误的断言，那么编译将会失败。
Zen 协议的智能合约方式使用了这一方式。它用独立类型化源代码表达资源的消耗情况。如果代码编译通过，那么它确保了资源消耗是正确的。鉴于我们使用了完备语言，因此我们知道程序终将结束。而我们从代码本身可了解资源的消耗情况，因此我们就预先知道了代价，进而无需在运行代码前解释字节码指令并计算瓦斯消耗量。这体现了编译代码相对与解释代码的高效性。Zen 当前使用了 F# 语言，并将 F# 编译为 CLI 字节码，然后执行。Zen 协议也可以使用其他实现方式，例如使用 OCaml 和 C 等。
编译过程只需做一次。代码一旦通过编译，就可以多次执行，这极大地提高了效率。
下面进一步详细阐述整个过程。在交易中，用户提交自己的智能合约源代码，节点将编译代码，从中提取程序及表达程序资源消耗的表达式。之后节点执行合约，这要比执行解释型代码更加高效。代码本身就是合约的组成部分，而编译后的二进制代码则不属于合约，并且只存在于节点的本地。在合约提交到“激活”之间存在延迟，使得节点可以在接收到合约后开展并行的合约编译，进而使得合约在数个区块后得以使用。合约的编译并不影响交易通量。
Zen 智能合约不仅运行速度快，而且在大部分时间中也可以并行执行。
Zen 协议在运行智能合约所需的时间上具有较少的局限性，可以更快地处理包含智能合约的交易。Zen 智能合约不仅运行速度快，而且在大部分时间中也可以并行执行。
不同于 EVM，Zen 协议不将完整的虚拟机作为共识的一部分进行维护。不同于 EVM 的单线程执行方式，Zen 合约之间是相互独立的，因此支持并行执行合约。这极大地提高了执行效率，因为现代硬件适合于高度并发。鉴于 Zen 合约是无状态的，只实现功能，因此合约中不存在竞争条件，或存在其它妨碍并发执行的问题。包含同一智能合约的多个交易可能并不易于并行执行，必须要串行执行。但是，这种方式运行的是高效、编译后的代码，因此性能相比起在 EVM 上执行同等计算还是要快一些。
学习资源： Zen Medium 技术博客，Zen 官方文档，Asher Manning 的 Medium 博客。
智能合约是以数字形式定义的承诺，控制数字资产并涵盖合约参与者约定的权利和义务。它由计算机系统自动执行。在基于区块链的智能合约中，数据管理、事务验证和状态处理都是在区块链上完成的，区块链提供完备的状态机接受和处理各种智能合约程序。
作者：Vaibhav Saini
翻译：盖磊
来源：infoQ
【文章版权归原作者所有，其内容与观点不代表Unitimes立 场。转载文章仅为传播更有价值的信息，合作或授权联系请发邮件至 [email protected]或添加微信unitimes2017】
