摘要： 智能合约是以数字形式定义的承诺，控制数字资产并涵盖合约参与者约定的权利和义务。它由计算机系统自动执行。在基于区块链的智能合约中，数据管理、事务验证和状态处理都是在区块链上完成的，区块链提供完备的状态机接受和处理各种智能合约程序。我们在此系统列举四十种支持或是用于开发智能合约的平台或项目，并介绍影响智能合约功能的主要因素。本文是该系列文章的第一篇，给出了其中 10 种支持平台，包括著名的 ETH、RSK 和 Zen 等。

正文

大家已经看到，区块链正在改变我们的世界。

区块链解决了人类一直面对的一个重大问题，信任问题。区块链可为任何需信任的事物创建一种不可更改的追溯印迹，由此解决信任的问题。

当然，该技术的强大还不止于此。

它在上述特性上继续扩展，用以创建一经制定就必须准守的规则，其中的每个行为都会产生相应的反应。其实，就是智能合约。

本文列出了四十种支持或是用于开发智能合约的平台或项目，它们均在不断的演进中。如果读者发现本文存在任何遗漏或错误，希望能在评论中提出。此外，随着本文作者对这些平台或项目的进一步研究，本文内容将会定期更新。

原文提供在Github上，读者可以拉取下来提出修改建议。

附： 本文对智能合约平台/项目的评估，主要考虑的是影响智能合约功能的一些因素，而不是整体功能评估。

这篇文章花费了原作者数天时间才完成。如果读者喜欢阅读此类内容，想表达感谢和支持，可在此处或下面的 ETH 地址请作者喝杯咖啡：

           a93e64a691d5aff8f78cd63130cf23b89182d235

下面详细列出四十种智能合约平台/项目。本文是该系列文章的第一篇，给出了其中 10 种支持平台，包括著名的 ETH、RSK 和 Zen 等。

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 智能合约的设计和实施还具有下述非功能性目标，按重要性顺序列出为：

1. 合约的执行应该是安全的。

2. 合约的执行应该是高效的、可扩展的。

3. 合约的执行应该是低代价的。

4. 具有从以太坊智能合约迁移的简单方式。

目标一：合约执行应该是安全的

安全合约指的是用户可以指定并自动地验证合约的属性。

为了实现安全合约，æ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博客。

6. Counterparty

优点：

• 基于比特币网络的以太坊智能合约（用于共识）。

不足：

• 和以太坊具有同样的不足之处。

智能合约语言： Solidity，Serpent。

现状： 活跃。

说明：

Counterpart 依靠比特币实现共识，但它也支持以太坊智能合约。下面给出其在更高层级上的工作机制：

• 用户使用 Solidity 或 Serpent 等语言编写智能合约代码，并编译为更紧凑的格式（字节码）。

• Counterparty 将创建并广播一个 publish 交易，将交易代码嵌入到比特币区块链中。这是以一种可花费的方式实现的，并不会“污染”整个区块链。

• 交易一旦发布，智能合约就“存活”于一个指定的地址上，看上去和正常的比特币地址毫无二至，只是地址以字母"C"开头。

• 用户进而可以使用 Counterparty 创建并广播 execute 交易，调用智能合约代码中指定的函数或方法。

• 一旦 execute 交易在广播后得到比特币挖矿者的确认，每个在运行的 Counterparty 节点将接收到该请求，并执行其中的方法。智能合约代码在执行中，会修改存储在Counterparty数据库中的合约状态。鉴于每个 Counterparty 节点具有相同的合约代码（由比特币机制确保）和相同的 EVM 代码，并且所有代码均为确定性的，因此每个节点将实现同样的状态更改。

• 其他用户也可以向智能合约发送 Counterparty 资产。这些资产将得到保存，并用于今后的 execute 调用。该机制对于融资等类型的合约非常有用。

• 从本质上看，我们所看到的智能合约发布，以及执行合同中特定功能或方法的命令，二者均为比特币区块链上的实际交易。因此，这两个操作会受到比特币约 10 分钟阻塞时间的限制。但是，执行智能合约代码一旦启动，通常会以节点处理速度运行。

比特币的 10 分钟区块生成时间限制对 EVM 的影响

一个合约在编写完成后，将会“发布”到区块链上，其数据将嵌入到区块链中，这确保了所有 Counterparty 节点执行同一合约代码。合约一旦发布，合约中的函数或方法将被执行。

合约的发布操作和执行操作均作为 Counterparty 交易发布（在比特币交易中），进而受限于区块生成时间。但是，合约一旦开始执行，就会按节点主机处理性能逐行尽快得到执行，合约中的每一个“执行步骤”并不受限于区块的生成时间，合约方法或调用方法将会立刻得到执行。

这样，区块的生成时间限制从整体上看对合约影响不大，只是会影响合约的最初发布，以及合约中方法的最初执行。

如果读者对 Counterparty 还有其它不解之处，推荐访问此处提供的扩展资源。

学习资源： CounterParty smart contract docs

7. Rootstock (RSK)

优点：

• 支持基于比特币实现图灵完备的智能合约。

智能合约语言： Solidity

现状： 活跃。

说明：

Rootstock（RSK）是一种在比特币上集成了图灵完备虚拟机（TCVM，Turing Complete Virtual Machine）的智能合约平台。它还提供了其它一些网络上的改进，例如更快的交易、更好的可扩展性等，以及一些支持新应用场景的特性。

RSK 是首个与比特币双向挂钩的开源智能合约平台。它也是通过合并挖矿而奖励比特币矿工，使矿工能够积极地参与到智能合约中。RSK 的目标是通过实现对智能合约的支持、近乎实时的支付以及更高的可扩展性，它增加了比特币生态系统的价值和功能。

学习资源： Rootstock

8. RChain

优点：

• 图灵完备。

• 智能合约可使用多种行业领先的功能，例如：元编程、响应式数据流、模式匹配等。因此，RChain 智能合约具有更好的可编程性。

智能合约语言： RHOLang

说明：

RChain 项目侧重于可扩展性。它使用了多线程区块链，并具有自身的智能合约语言，目前能与以太坊等顶级区块链项目一争高下。RChain 的构建遵循如下最小需求：

• 动态智能合约功能，支持更多的用例实现。

• 并发执行，支持多个独立的智能合约可以紧邻着执行。

• 使用 Casper 智能合约协议，计算强度低，不会浪费资源。

Rho 虚拟机（RVM）是一种基于 JVM 的虚拟机。RVM 的执行环境支持操作多个运行智能合约的 RVM 以多线程方式并发运行。这种并发结构支持将多个独立进程组合为一个不会产生资源竞争的复杂进程。因此，这种架构也支持多链（即每个节点存在多个区块链），并且每个交易由独立执行的 VM 实例处理。

Rholang 合约

RChain 节点可使用 Rholang 合约。Rholang 是一种“面向进程”的合约，所有计算通过消息传递方式完成。消息通过一种非常类似于消息队列的“通道”传递。注意在本文中，“命名”（name）和“通道”（channel）是同义词，这是因为 Rholang 所基于的 rho 代数中使用了“命名”一词。用户可以在“命名”上发送和接受信息，因此从语义上看，“命名”和“通道”是等价的。用户可以通过此处Web界面试用部分 Rholang 代码。

RChain 为 Rholang 重建了 ERC20 功能，支持用户自建代币智能合约并在 RChain 上部署。在RChain的Github代码库中提供了一些例子。

学习资源： RCHain开发者网站，RHOLang教程，RChain的Medium博客。

9. Qtum

优点：

• 可以看成是对以太坊智能合约平台的一种改进。它解决了可扩展性、形式化验证工具缺失、使用 SPV（简单支付验证，simple payment verification）时最小移动解决方案缺失等问题。

不足：

• 由于完全兼容 EVM 并支持 Solidity 合约，Qtum 继承了以太坊智能合约在安全上的缺陷。

智能合约语言： Solidity

现状： 活跃。

说明：

Qtum 是一种在设计上兼容以太坊的智能合约平台，它改进了以太坊一些明显的缺陷，例如可扩展性、缺少形式化验证工具，使用 SPV 时缺少最小移动解决方案等。Qtum 使用一种新的底层区块链和共识算法解决了上述问题。在 Qtum 看来，这些改进使得平台可为轻量级移动和IoT应用提供更好的支持。Qtum 项目意在成为一种“企业通用区块链”，有望在未来将其技术应用于金融服务、供应链管理、社会媒体、游戏等行业。

Qtum 本质上是一种基于以太坊的智能合约系统，共识使用的是一种改进版本的 Blackcoin 的 PoS，运行在基于比特币的区块链上。Qtum 添加了一个自定义的采纳层，将以太坊账户的金额映射到一组比特币 UTXO 上。

由于 Qtum 是完全兼容 EVM 的，并支持 Solidity 合约语言，因此 Qtum 也继承了以太坊智能合约在安全上的所有不足之处。

Qtum 计划通过添加一种x86虚拟机实现智能合约的扩展，支持使用 C++、Java 和 Haskell 等语言开发智能合约。尽管这一改进将使得 Qtum 项目适用于更多的开发人员，并可使用现有的工具，但是 Qtum 并未针对继承自 Solidity 设计中的安全问题做出改进。

在Qtum白皮书中指出，Qtum 的目标是开发一种称为 QSCL（Qtum Smart-Contract Language）的智能合约语言。据白皮书阐述，QSCL 是一种“专门用于实现形式化验证”的语言。但是除了一篇由白皮书作者之一发表的学术论文之外，QSCL 尚未提供更多可参考细节。在该论文中，论文作者提出了自己开发的一种“跨组织协作本体”语言，但是在论文中并未采用 QSCL 命名。鉴于 QSCL 资料的匮乏，看上去 Qtum 现在应该未再推进该创意的实现。

学习资源： 智能合约开发人员指南，Qtum。

10. Ark

智能合约语言： 待定。

现状： 不活跃

说明：

Ark 意在创建一种类似于以太坊的智能合约平台。ARK 提供集成的虚拟机，支持用户发布 ARK 智能合约。Ark 与以太坊的唯一差别在于，Ark 使用 dPoS 作为共识机制，加快了交易速度。

学习资源： ACES Ark转以太坊智能合约服务，BoldNinja的Medium博客。

本篇小结

智能合约是以数字形式定义的承诺，控制数字资产并涵盖合约参与者约定的权利和义务。它由计算机系统自动执行。在基于区块链的智能合约中，数据管理、事务验证和状态处理都是在区块链上完成的，区块链提供完备的状态机接受和处理各种智能合约程序。该系列文章将列举四十种支持或是用于开发智能合约的平台或项目，并介绍影响智能合约功能的主要因素。在下一篇中，我们将继续给出 10 种支持平台，其中包括著名的 EOS、HyperLedger Fabric、Corda 等。

作者简介：Vaibhav Saini是一家由 MIT Cambridge 创新中心孵化的初创企业TowardsBlockchain的联合创始人。Saini 也是一名高级区块链开发人员，具有 Ethereum、Quorum、EOS、Nano、Hashgraph、IOTA 等多种区块链平台的开发经验。他目前是德里印度理工学院（IIT Delhi）的一名大二学生。

查看英文原文： ContractPedia: An Encyclopedia of 40 Smart Contract Platforms A Complete List of all Smart Contract supportive Platforms