[关闭]
@Rays 2018-10-28T12:32:09.000000Z 字数 30105 阅读 2956

四十种智能合约支持平台列表

区块链

摘要： 本文列出了四十种支持或是用于开发智能合约的平台或项目，主要介绍了影响智能合约功能的一些因素。

作者： Vaibhav Saini

正文：

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

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

当然，该技术还具有其它强大之处。

区块链还具有扩展上述特性的能力。区块链可用于创建一旦制定就必须准守的规则，其中每条规则会引发特定的操作行为。换句话说，就是实现智能合约。

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

原文提供在Github上，读者可以自行获取，并加以修改。

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

此类文章通常需要数天时间才能完成。如果读者喜欢阅读此类内容并继续关注，为表达感谢和支持，可在此处或下面的ETH地址捐赠茶水钱：

           a93e64a691d5aff8f78cd63130cf23b89182d235

下面详细列出四十种智能合约平台/项目。

1. 以太坊（Ethereum）

优点：

不足：

智能合约语言：Solidity

现状： 活跃

说明： 以太坊是首批在区块链中引入智能合约概念的平台之一，并得到了开发者社区的最大支持。它宣称实现了图灵完备的智能合约平台。合同代码由每位以太坊网络中的矿工在EVM（以太坊虚拟机）上执行。它是最广为使用的区块链项目平台。

尽管以太坊平台可安全使用，但是其因用户实现代价问题而备受批评。此外，以太坊平台缺乏可扩展性，会导致交易速度不高，不适合当前的现实世界应用。

平台使用Solidity语言。Solodity可以很好地实现图灵完备，但是缺乏现代语言的灵活性，存在的问题包括：

上述问题表明，为适应现代语言的灵活性，该智能合约语言依然需要进一步发展。

有资料列出了Solidity存在的62个问题。

学习资源： CryptoZombies主页，Solidity官方文档，OpenZeppelin，以太坊的Medium博客。

2. Quorum

优点：

不足：

智能合约语言： Solidity

现状： 活跃

说明：

简而言之：

Quorum是以太坊智能合约平台的一种版本，它提供免费的交易，并且还能够使用constellation完成各参与方间的私有交易。

Quorum维护了两个账本，即公开的的私有的。公开账本被公开交易修改，私有账本只针对私有交易所涉及的各方，被私有交易修改。

Quorum与以太坊联系密切，它们使用同一核心平台和语言。因此Quorum也同样继承了以太坊智能平台的优缺点。

学习资源： Quorum文档，CryptoZombies，Solidity文档，OpenZeppelin。

3. Wanchain

优点：

不足：

智能合约语言： Solidity

现状： 活跃

说明：

Wanchain是以太坊的一个分支，因此它继承了以太坊的许多属性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（即æ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依靠比特币实现共识，但它也支持以太坊智能合约。下面给出其在更高层级上的工作机制：

比特币的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

优点：

智能合约语言： RHOLang

说明：

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

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

优点：

不足：

智能合约语言： 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博客。

11. EOS

优点：

不足：

智能合约语言： C++，C

现状： 活跃。

说明：

EOS.IO合约（也称为“应用”）是作为预编译的WebAssembly应用（即WASM）部署到区块链上的。WASM是使用LLVM和Clang从C/C++程序编译得到的，这意味着用户在部署区块链应用中需要C/C++开发技能。尽管EOS.IO可以使用C开发，但是推荐使用EOS.IO C++ API。这些API提供了更强的类型安全，也更易于阅读。

应用结构

EOS.IO应用对用户动作的响应，是围绕事件/动作处理器设计的。例如，如果用户需要将代币转账给另一个用户，那么该事件可能会被发送者、接收者或者应用本身处理或是拒绝。作为应用开发人员，需要决定用户应采取的行动，以及对于各种行动应调用哪些处理器。

为了提高交易的速度，EOS做了一系列的优化，其中包括采用dPoS作为共识机制、并行执行、阶段性执行等。由于EOS具有高可扩展性、无交易费用、使用C++作为智能合约语言等特性，因此它被认为是以太坊的一种很好的替代平台。但是EOS仍然没有得到广泛使用，其作为智能合约平台的许多优缺点尚待实践检验。

学习资源： EOS开发人员文档，eosio的Medium博客。

12. Neo

优点：

不足：

智能合约语言： C#，VB.Net，F#，Java，Kotlin，Python，并计划支持C、C++、Golang和JavaScript。

现状： 活跃。

说明：

NEO智能合约2.0版具有确定性、高性能和扩展能力等特性，它支持验证合约、功能合约和应用合约等类型的合约。

从性能上看，NEO使用轻量级的NeoVM虚拟机作为智能合约执行环境。NeoVM启动非常快速，占用资源很少，适用于小型过程等一些小规模的合约。NeoVM还使用了JIT技术，显著地提高了热点合约的静态编译和缓存。NeoVM的设置中考虑了一系列的加密指令，优化了智能合约中加密算法的执行效率。此外，数据操作指令为直接操作数组和复杂数据结构提供了支持。所有上述考虑提高了NEO智能合约2.0版的性能。

NEO智能合约2.0版通过组合高并发、动态分区和低耦合设计实现了可扩展性。低耦合合约过程在NeoVM中执行，并通过交互服务层与外界交流。这样，大量对智能合约功能的升级可以通过交互服务层的API实现。

从语言方面看，NEO智能合约2.0版与以太坊的区别更加直观。不同于以太坊使用的Solidity语言，NEO智能合约可以直接使用几乎所有高层编程语言。先期支持的语言包括了C#、VB.NET、F#、Java和Kotlin等。NEO为这些语言提供了编译器和插件，用于将高层语言编译为NeoVM支持的指令集。首个实现的编译器使用了MSIL（Microsoft Intermediate Language），因此理论上讲，任何可转译为MSIL的.NET言语以及其它一些语言，都可被NEO支持。

尽管如此，NEO并未得到广泛采用。

学习资源： Neo智能合约官方文档，NEO的Medium博客。

13. NXT

现状： 活跃

说明：

NXT智能合约并非图灵完备的，但是它在创建模板智能合约中设置了一个图灵完备的脚本层。用户可以选择最适用的模板，并通过调整参数创建自身的智能合约。在NXT看来，从这些模板中创建的智能合约可以覆盖绝大多数的业务应用。NXT智能合约易于编码实现，并可确保系统的安全性。

学习资源： NXT智能合约官方网站。

14. Nem

优点：

不足：

智能合约语言： 无特定语言。

现状： 活跃

说明：

可扩展性是NEM去中心化应用的关键。尽管以太坊可以实现最大每秒十五次交易，但据报道NEM可达到每秒数百次交易。安全性和可用性问题是NEM基金会优先考虑的事项。

NEM区块链通过强大的API提供功能。这些API可被所有编程语言调用，而非局限于特定的“智能合约”语言。NEM提出了“链下协议”这一概念，用于表示使用了NEM API的代码。运行代码的用户无需与区块链做任何交互，只要用户愿意，就可以在任一时刻更新。因此，现有的“智能合约”可以修改。代码根据功能上的不同，可能在或多或少的程度上是无缝的。注意，开发人员不能更改代码在链上已完成的事情，例如，反向交易等。但是开发人员可以在不与区块链交互的情况 下修改这段代码，并使合约自此以后按新修改的功能运行。因此从某种意义上说，NEM正在实现的特性在很大程度上不能称之为去中心化的和透明的，只是具有更好的可扩展性（至少目前为止如此），更易于完成任务。

学习资源： Nem智能合约，NEM官方Medium博客。

15. Waves

智能合约语言： RIDEON

现状： 活跃。

说明：

Waves在智能合约的实现上是做了一些认真考虑的。备受期待的Waves智能合约，其推出过程可划分为两个阶段。第一阶段已经完成，就是4月28日在测试网络中推出了非图灵完备的智能合约。该初始版本使得社区可以先行测试具有账户控制支持等多种特性的非图灵完备合约。只有在这些特性经过完全测试，并正确地在主网应用后，Waves才会继续推出图灵完备的合约。

非图灵完备智能合约考虑到了大部分通用用例。它是一种实现用户潜在需求业务功能的通用且易用的工具，涉及了从不同区块链上的代币交易，到为用户项目或企业控制共享预算以建立精准机制和术语。此外，非图灵完备的智能合约是完全安全的，它确保了用户不会犯错误，因此合约绝不会出错。

多重签名（MultiSig）帐户是Waves智能合约的首个也是最受欢迎的用例之一。另一个有用的应用是代币冻结，即向用户发送一定数量的代币，但确保它在一段时间内是不可转让的且不可使用的。一个显著的用例是用做投资机制，或是在ICO后的团队/合约方付款。

余额管理是帐户控制的进一步应用。用户可能希望每月定期支付，但要确保其帐户余额不低于特定的余额。或者用户可能希望在一个账户中保留固定数量的资金，并将超出固定数额的资金移到另一个独立帐户中。

学习资源： Waves智能合约官方文档，智能合约IDE、Waves平台。

16. Stratis

优点：

智能合约语言： C#

现状： 活跃

说明：

Stratis智能合约实现的最重要特性，是使用了“真正的”.NET。也就是说，Stratis智能合约使用.NET Core执行。Stratis的完全节点（Full Node）也是用C#编写的，并使用了与Stratis智能合约相同的执行路线。Stratis智能合约不仅使用了C#语法，而是使用了微软提供的经过全面测试和测试的C＃包。

由于智能合约的执行必须是确定性的，因此在编写智能合约时无法使用C#语言和.NET Core软件库的全部功能。Stratis智能合约提供了验证工具，用于检查用户编写的智能合约中是否存在非确定性元素。

Stratis中还引入了与以太坊中一样的“瓦斯”概念。

学习资源： Stratis智能合约官方文档，Stratisplatform的Medium博客。

17. Stellar

优点：

智能合约语言： 无特定的语言。

现状： 活跃。

说明：

SSC（Stellar智能合约）与以太坊智能合约存在很大的差异。SSC并非图灵完备的，它实现为一种多方协定，并由交易强制执行。下表列出了Stellar和以太坊的对比情况。注意，两者间的最大不同在于代价和确认时间。Stellar网络上单个交易的代价可低至约0.0000002美元！

表：以太坊与Stellar智能合约对比。表中内容来源：https://www.stellar.org/blog/using-stellar-for-ico/。

对比项 Stellar 以太坊
交易确认的时间（中位数） 5秒 3.5分钟
交易费用 交易费用可忽略不计（低至0.00001 XLM，约合0.0000002美元）。计算无需瓦斯费用 交易费用依赖于计算的复杂度、交易速度、以太的法币价值等。一次转账费用的中位数约0.094美元 。
特性 提供基础抽象的软件库，可用于生成复杂行为。参见“Stellar开发人员文档”。 任何所考虑到的特性，但也有不少特性并未虑及。
安全 去中心化网络。任何人可以运行Strellar核心节点，并验证交易。也可以指定验证者以增强安全性。原子交易由以下基本的、描述性操作组成，形成更可追踪的代码，代码缺陷也少。 去中心化网络。任何人可以运行节点并验证交易。没有用于推选验证者的。提供图灵完备的编程能力，生成的代码可追踪性略低，具有很大风险暴露漏洞。

SSC可使用任何已由Stellar社区提供API的语言编写，包括JavaScript、Python、Golang、PHP等。读者可在Github代码库中找到智能合约的PHP例子代码。

SSC表示了使用各种限制连接在一起并执行的交易组合。下面列出了在创建SSC中需要考虑实现的一些限制：

学习资源： Stellar智能合约官方文档, Stellar

18. HyperLedger Fabric

优点：

不足：

智能合约语言： GoLang，Node.js

现状： 活跃。

说明：

HyperLedger Fabric是HyperLedger家族中的多个项目之一。

Hyperledger Fabric（HLF）将自己的智能合约称为“链码”（ChainCode）。HLF是一种企业联盟链，具有很好的灵活性，非常适用于业务，因为HLF的业务规则经历了近七年的发展。其它大多数区块链在构建时都没有考虑灵活性。

图 HyperLeger Fabric链码的结构流图。

Hyperledger Fabric本身是使用Go语言编写实现的，因此其智能合约同样也支持Go语言。这有什么优点？Golang是一种非常高效的编程语言，编译快速。

HLF的合约结构非常简单，其中四个最重要的函数是：

特别解释一下DelState函数。HLF使用一种状态数据库存储键及对应的值。这不同于组成区块链的区块序列方式。可使用DelState函数从状态数据库中删除一个键及其关联的值。但是，该函数并没有更改区块链中的区块。

和修改键和值的操作将作为交易记录在区块链上一样，键和值的删除同样会作为交易存储在区块链中。

一个键在被删除后，键的操作历史是可以检索的。HLF提供了GetHistoryForKey()函数检索历史，函数返回值中包括IsDeleted标识，标记一个键值是否已经被删除。一个键可以多次创建、删除然后再创建。所有操作历史都可使用GetHistoryForKey()检索。

学习资源： HLF链码官方文档。

19. Corda

优点：

不足：

智能合约语言： Java, Kotlin

现状： 活跃。

说明：

CorDapp简介

CorDapp（即Corda去中心化应用）是运行在Corda平台上的去中心化应用。CorDapp的目标是允许所有节点对更新账本达成共识。为实现这一目标，CorDapp定义了工作流。Corda节点的所有者可以通过RPC调用执行工作流。注意：每个CorDapp是安装在独立节点层面的，而非网络层面。

图 CorDapp的架构。

从结构上看，CorDapps包括下列主要组件：

1. 状态（State），定义了达成共识的事实。

每个节点都具有一个保险存储，用于存储节点本身的所有相关状态。

2. 合约（Contract），定义了组成有效账本更改的情况。

3. 服务（Service），提供节点中长存的功能。

Corda架构中的核心元素包括：

5. 序列化白名单（Serialisation whitelistes）

用于限制节点可从链上接收的类型。

编写CorDapp

可使用Java或Kotlin编写CorDapps，也可以混用两种语言编写。每个CorDapp组件均作为Corda软件库的子类或接口，实现为JVM类。Corda软件库的类型包括：

学习资源： Corda智能合约官方文档，Corda团队的Medium博客。

20. Neblio

智能合约语言： C++，Python，Go，JS，Ruby，.NET，Java，Node.js。

现状： 不活跃。

说明：

NTP1（即Neblio代币协议第一版，Neblio Token Protocol-1）支持根据指导或限制代币交易协议中使用的一组规则而创建的智能合约。例如，代币发行方可以为代币交易设置交易费用结构，并将交易费用置入指定的账户中。代币的锁定和到期规则可用于将代币移动到指定账户，或是用于在一定的时间或特定日期后使代币完全失效。规则还可用于生成限制代币可转移到账户的合同，或是限制允许生成新代币的账户（如果存在的话）。NTP1支持多种智能合约编写语言，原因在于其每个节点内置了RESTful API服务器，用于处理所有的API调用和响应，实现与Neblio网络和区块链的交互。

学习资源： Nebilo官方文档。

21. Viacoin

智能合约语言： Java

现状： 活跃。

说明：

Viacoin使用RSK（Rootstock）支持其智能合约功能，并与以太坊兼容。

Rootstock是一种双向锚定（Two-way Peg）的智能合约平台。Rootstock运行一种称为“Rootstock虚拟机”的图灵完备虚拟机，该虚拟机也是与EVM兼容的，并支持运行Solidity编译的智能合约。

Viacoin即将发布0.15.0核心版，其中将实现默克尔抽象语法树（MAST，Merkelized Abstract Syntax Trees）。MAST结构非常简单，支持更小规模的交易，因此更便于智能合约的执行。0.15.0版对实现RSK智能合约非常关键，将为Viacoin提供类似于以太坊的智能合约。RSK近期发布了比特币智能合约平台的首个Beta版。

学习资源： Viacoin的Github代码库。

Viacoin Github | Viacoin Reddit | Viacoin Telegram

22. Cardano

优点：

智能合约语言： Solidity，Plutus。

现状： 活跃

说明：

Cardano的智能合约平台称为CCL（即Cardano计算层，Cardano Computation Layer）。CCL尤其注重以最简单的方式确保智能合约在行为设计上不存在潜在的漏洞。CCL包括两个层面，一个层面是形式化指定的虚拟机和语言框架，另一个层面是形式化指定的语言，便于自动验证人类可读的智能合约代码。

图 Cardano智能合约和虚拟机

CCL的底层称为IELE。IELE提供了虚拟机和通用语言框架实现，其中虚拟机是设计用于简化形式化验证工具的构建，语言框架则用于将智能合约从高层语言转译为可执行指令。IELE的研发是由运行时验证（Runtime Verification）的提出者、UIUC教授Grigore Rosu领导的，并受到IOHK的资助。为构建更安全和高效的虚拟机，Rosu教授的团队正在将他们对KEVM和KLLVM的最新研究成果应用于其中。其中，KEVM是EVM使用的一种K框架形式化语义，KLLVM是LLVM中使用的一种K框架形式化语义。

不同于EVM这样基于堆栈的虚拟机，IELE将实现为LLVM这样基于注册器（register-based）的虚拟机。IELE将支持无限数量的注册器，并支持无界整数。IELE避免了使用无界堆栈，因此也无需担心堆栈或算术溢出，这显著地简化了智能合约的定义和验证。和以太坊类似，IELE也使用瓦斯表示资源使用，并防止出现DoS工具。这避免了在形式化验证中出现一些被研究团队认为是“棘手但可控”的挑战性问题。IELE使用K框架简化了验证智能合约匹配规范的自动化工具的开发，这使得IELE支持使用任何在K框架中具有形式化语义的编程语言编写智能合约。

Simon就是其中的一种编程语言。Simon是在Cardano的愿景论文提出的一种高度约束、特定于领域的交易语言，它给出了一组准确定义的基本金融交易原语。这些原语可组合创建更复杂并可验证的合约。关于Simon的介绍性内容不多，但是据称Simon是受到Simon Peyton Jones及其研究同事撰写的“Composing contracts: an adventure in financial engineering”一文的启发。

Simon Peyton Jones是Haskell的主要设计者之一。Haskell是一种静态类型的完全函数化语言，通常用于实现一些存在运行时软件缺陷代价很高问题的应用，并已用于实现Ouroboros。Haskell的设计天然适用于实现可在软件开发过程的早期发现并消除软件缺陷的自动验证工具。ACM Fellow及Haskell的另一位设计者Phil Wadler也出任了IOHK的编程语言的指导专家。因此很自然，Cardano的主要高层通用智能合约语言Plutus中集成了Haskell的大量底层机制。

Plutus是以一种静态类型的函数式编程语言，它具有类似于Haskell的人类可读语法。和Haskell一样，Plutus也将转译为一种更简单的语言Plutus Core，简化了形式化验证。形式化验证工具有助于开发人员推理合约，并验证智能合约行为的特定属性。这些验证工作是一些强大的工具，可用于标出并消除一些存在于合约中漏洞，其中包括非法输入处理、类型不匹配、不明显的非预期代码路径、对作用范围的模糊认识、输入错误、溢出等。例如，通过对某个属性的验证，表明不存在可以更改合同所有者的代码路径，这将防止了出现导致对Parity多签名（Multisig）钱包发出两次攻击的漏洞。现在回头看来，显然该特定属性是有必要的。因此，一些重要的属性完全有可能并未包括在正式规范之中，只有在被一些漏洞利用后才发现其重要性。由此，虽然形式化验证是一种非常强大的工具，但它只能在创建规范时起作用，体现人们当时的全盘考虑情况。

Cardano有计划支持包括Solidity在内的更多高层语言。但是，它只支持“将Solidity用于低保证性的应用，而将Plutus用于需要形式化验证的高保证性应用”。虽然很难想象会有智能合约编写者考虑使用低保证性应用，但是Cardano提供对Solhere的支持，这使得以太坊开发人员和一些已有的合约更易于迁移到Cardano。然而，促使开发人员和合约迁移到Cardano的主要原因并非在于其对Solidity的支持，而是在于Cardano减少了将资金置于于风险中的漏洞。如果经实践验证，IELE、Plutus及其支持验证工具开发的智能合约可避免出现那些困扰Solidity代码的漏洞类型，那么对于那些需要使用智能合约对所控资金获取更好安全性的情况（应该说所有的智能合约均是如此），Cardano无疑是首选平台。

学习资源： Cardano官方文档

23. Tezos

优点：

智能合约语言： Michelson

现状： 活跃

说明：

Tezos计划通过一种称为“Michelson”的新智能合约语言实现极大地提升安全性。Michelson在设计上聚焦于简化对链代码的形式验证。不同于Solidity，Michelson不编译生成任何输出。它是一种底层的、基于堆栈的、图灵完备的编程语言，由Tezos虚拟机直接解释执行。因此从技术上看，Michelson比Solidity更适合于EVM字节码。Michelson中还包括了一些高级结构，例如Map、集合、Lambdas表达式、加密原语，以及一些专用于合约的操作，这使得开发人员更易于阅读和编写。Michelson是一种纯函数式、强类型和静态类型检查的语言，它简化了构造正确性证明，并消除了多种会破坏Solidity合约的漏洞。

正确性证明并不能给出不会发生任何不良事件的通用证明，而是可以证明程序可满足特定规范中所列举的所有断言。因此，如果由开发人员创建的规范中所包含的断言指定了仅有授权用户才可以更改合约所有者，那么验证者将在Parity多签名钱包部署之前捕获其中的漏洞。但是出于效率上的考虑，开发人员需要考虑断言（回顾前文，这是十分明显的），并在部署代码遭受攻击之前将断言加入到规范中。

虽然人工分析和推理在预防漏洞上的作用是不可替代的，但形式验证也可以作为一种强大的补充工具。形式验证适用于那些漏洞可能会带来灾难性后果的情况，例如，控制大量资产的飞机软件和智能合约。以太坊社区也认识到了这一点，并且开展了多个项目去研究智能合约的形式验证和以太坊虚拟机本身。以太坊社区也正在研究Bamboo和Viper等新的编程语言，这些语言更适合于形式验证，而且更受限制，可使编译器而不是黑客发现许多漏洞。由于这些语言也将编译为EVM代码，因此有必要对高层代码以及其所生成的EVM字节码（和/或生成字节码的编译器）做形式验证。与以太坊不同，Michelson 直接由Tezos虚拟机解释，因此只需要对合约代码做正确性证明。

Tezos区块链启动后，Michelson将会提供一个编程环境。其中开发人员无需具备专家级能力，就可以开发比Solidity更安全的智能合约。目前，只有少数精通Michelson的编程人员。此外，Michelson作为一种基于堆栈的新语言，其中还存在一些编程人员并不习惯的功能。因此，Michelson的学习曲线可能会成为阻碍其被开发人员采纳的一个障碍。尽管如此，Michelson为开发更高层级的、对开发人员更友好的函数式语言提供了基础，促进了“全栈式”形式验证的实现。目前，还有一种称为“Liquidity”的编程语言正在积极的研发中。该语言提供类似OCaml的语法，并可与Michelson相互转码（transpile）。

在以太坊中，正在研究一些补充性的可扩展技术，例如分片、支付通道、侧链和链下计算等。虽然Tezos认识到微支付需要支付渠道等链下机制，但在他们看来，要实现大规模链上可扩展性的提升，其最佳途径并非分片等技术，而是在于递归SNARK技术。SNARK可为任意复杂度的交易提供加密证明，并递归地为交易证明块提供单一的证据，从而使大量交易能够在廉价硬件上得到快速验证。据Breitman介绍，这项技术可以完全消除对瓦斯限制的需求，并允许用户在不到一秒的时间内完成整个区块链的同步，从而无需考虑中心化和吞吐量间的权衡。采纳SNARK的两个主要障碍是产生递归证明的计算成本和对可信设置的要求。但是最新的进展表明，这种大规模扩展的方法可能很快就会投入实用。

学习资源： Tezos Michelson的文档，Tezos的Medium博客。

24. DFINITY

智能合约语言： Solidity

现状： 不活跃

说明：

DFINITY标榜自己是以太坊的“疯狂姐妹”，以比喻二者在基因上的相近性。但是DFINITY更专注于性能，并使用了基于神经元运作的治理模式。

DFINITY的理念认为，一些合约和去中心化应用可能更适合于采用由算法治理的平台，而非以太坊这样的“代码就是法律”类型的平台。DFINITY项目当前处于原型系统与可用于生产环境这两者之间的状态。在编写DFINITY项目时，尚不存在支持部署智能合约的公有链。

区块链神经系统（BNS，Blockchain Nervous System）和高性能与可扩展性是DFINITY的两大卖点。但是用户要理解DFINITY智能合约，必须首先理解“链上治理”（on-chain governance）机制。

使用DFINITY的链上治理机制，无需对网络做硬分叉（Hard Fork），即可实现升级协议等功能。这在某种程度上类似于Tezos的理念，但是DFINITY使用的是EVM和Solidity。因此，任何可在以太坊上部署的协议，也可部署在DFINITY上。

那些在“神经元”上“下注”自己代币的用户，将会根据投票的份额获得到相应的投票能力。BNS表示了网络中的所有神经元。任何人可以向网络提交提案（Proposal），而投注了代币的用户可以对提案进行投票。提案可以是：

学习资源： DFINITY官方文档，Dominic Williams的Medium博客。

25. BOSCoin

智能合约语言： Web本体语言

现状： 不活跃

说明：

不同于前文提及的大多数智能合约，BOSCoin的受信合约为实现可判断特性，在设计上使用了Web本体语言（OWL，Ontology Web Language），并采用了自动机理论。下面详细介绍其中的各个组件，以及组件间的相互作用机制。

OWL

OWL即Web本体语言，它是基于W3C（万维网联盟，World Wide Web Consortium）的语义Web语言提出的。OWL组件在BOS平台受信合约中用于解释智能合约中的语言结构，包括编码和句子字符串等。

W3C是一个为支持万维网长期发展而提出Web数据开放标准的国际组织。OWL的职责之一就是创建了用于表示事物及事物间丰富而复杂关系的OWL语言。

OWL具有五个主要组件：

BOS平台将通过W3C的语义Web使用OWL。本体是形式化的术语词汇表，它定义了描述自身与本体中其它术语之间的关系。OWL是应用用于处理信息的工具（相比起人工处理），支持系统解释词汇表的含义。其中，信息可以是标准的文本句子或代码。使用OWL的优点在于可以从OWL存储库所包含的众多本体中提供信息。

时间自动机语言（TAL，Timed Automata Language）

BOS平台受信合约上的智能合约需要验证，这是由TAL担当BOS平台的验证代理实现的。TAL源自于有限状态自动机理论，并在功能中添加了时间上的考虑。因此，我们最好首先了解自动机理论。幸运的是，对此有多种出版物。其中，斯坦福大学给出了如下的很好描述：

“（自动机）是一种执行特定处理的自动化过程……自动机理论针对被称为“自动机”的单机中的计算逻辑。计算机科学家通过自动机理论理解机器的计算功能，并解决问题。更重要的是，自动机理论提出了哪些功能可定义为可计算的，哪些问题可定义为可判定的。”——斯坦福大学教程

如上所述，有限状态自动机是自动机理论的扩展。有限状态自动机是一种建模有限数据逻辑的工具，用于理解自动机最终的生成状态。下面给出一个实际例子。该例子建模了一个自动推拉门，其中左图表示了门，右图表示了状态。

图 滑动门示意图。来自于Miachael Sipser所著的《计算理论导引（2006年版）》（“Introduction to Computer Theory”）一书。

图 滑动门的状态图。来自于Miachael Sipser所著的《计算理论导引（2006年版）》（“Introduction to Computer Theory”）一书。

在上例模型中，圆圈表示状态，箭头表示状态转移。图中最左边的箭头表示开始状态。系统（即本例中的滑动门）的状态有两种，开门（OPEN）和关门（CLOSED）。对于本例而言，输出情况如下表所列：

图 滑动门状态表

如果系统经历了如下事件序列：“FRONT，REAR，NEITHER，FRONT，BOTH，NEITHER，REAR，NEITHER”，那么状态转移如下图所示：

图 滑动门的状态转移

时间自动机（TA，Timed Automata）将时间引入了自动机的输入。台灯的状态就是一个使用系统时钟的很好示例。如果在一定时间内按下开关，台灯将会变暗，而不是仅打开或关闭。台灯的状态图如下所示：

图 调节台灯状态图。例子来自于澳大利亚新南威尔士大学Ansgar Fehnker的COMP4151课程第11a讲“算法验证”。

上面给出的调节台灯状态图中，存在三种状态，即Off、Dimmed和Bright。状态转换是由按钮开关启动的。如果处于“Off”状态，那么再次按下开关，台灯状态更改为“Dimmed”。如果在系统内部时钟的一个时间度量间隔（例如，一秒）内按下开关，台灯状态变为“Bright”。如果台灯处于“Bright”状态，或是在上次按下开关后一个时间度量间隔内再次按下开关，那么台灯状态将变为“Off”。

将区块链、OWL和TAL组合在一起

OWL、TAL组合构成了受信合约的基础。当前智能合约是编码实现的，OWL组件将解释代码字符串的结构，而TAL将建模并确认智能合约的整体逻辑。进而，区块链存储了OWL和TAL的来源。

由此，我们可以在受信合约验证和执行之前，确保合约是可判断的，进而确保了系统的整体性。

学习资源： BOScoin

26. Agoras Tauchain

现状： 不活跃。

说明：

要了解Agoras，首先需要介绍Tau链的原理。Tau链生态系统概括了很多中心化和去中心化对等网络，其中包括一些区块链企业。Tau链具有多种不同的用例，从软件开发到游戏，乃至去中心化存储。Agoras是一种运行在Tau链上的应用，它提供一种聚焦于点对点合约的智能货币。

Agoras聚焦于点对点智能合约，是一种值得企业考虑的解决方案。企业通常希望能保持私密性，考虑包括私密性交易的智能合约足以实现这一目标。Agoras希望首要关注的是有意义的智能合约，这些协议将始终遵循设定的设置和要求，对任何一方都不存在任何意外。

学习资源： Agoras blog

27. Burst

优点：

不足：

智能合约实现： Automated Technologies (C/C++)

现状： 活跃。

说明：

Burst是首个在现实环境中以自动化交易（AT，Automated Transaction）形式实现工作机制、图灵完备智能合约的加密货币。下图给出了从创建合约到最终状态更改的流程。

图 Burst智能合约的生命周期

由于一些问题的存在。Burst不能跟上其它平台的发展。在2018年4月4日的一次访谈中指出：

使用Burst AT的主要问题在于，矿工运行每个操作代码（即一行代码）都需要一个爆裂币（BRUST）。这使得即便运行从智能合约本身返回一个BRUST这样非常简单的合约，也需要花费大约二十个BRUST。如果合约的运行成本能降低到每个操作码需0.001个BRUST，那么在引入编译器等技术后，该平台才可以与以太坊等其它平台一争高下。

学习资源： BurstAT的wiki页面，Burstcoin_dev的Medium博客。

28. iOlite

优点：

现状： 活跃。

说明：

iOlite是一种聚焦于让智能合约技术为更广泛大众采纳的产品，它提供了一种可实现理解自然语言并将其编译为智能合约代码的引擎。对于那些不希望花费时间去学习而希望能快速启动智能合约应用的用户而言，iOlite是一种理想的解决方案。

图 iOlite的用例

iOlite是基于斯坦福大学的一项研究发展而来。这项研究提出的FAE技术适用于将自然语言及其它一些所需编程语言转译为智能合约代码。FAE并非直接将输入语言转译为代码，而是取决于贡献者（即一些智能合约的专家）是否定义了一些包含语言表达式的结构。进一步，这些结构将用于所编写的智能合约代码中。这使得引擎可以浏览这些结构，找出可编译为所需智能合约的正确表达式。一旦某个结构得以使用，贡献者将得到相应的iOlite代币作为奖励。

可以看到，iOlite FAE的成功依赖于社区的贡献。FAE通过使用机器学习技术帮助简化新结构的学习和采纳。

iOlite实验室当前正聚焦于最为广泛使用的Solidity以太坊智能合约。

iOlite团队的Travis Byrne介绍了哪些语言可用于创建智能合约。“这不仅意味着Python、C、JavaScript等正则语言的编程人员可立即使用自身现有的技能编写智能合约，而且意味着即便是没有编程技能的普通人，也可以使用英语等自然语言上手开发智能合约。iOlite正在拓展创建智能合约的技术学习疆界”

学习资源： iOlite官方指南，iOlite的Medium博客。

iOlite Reddit | iOlite Github | iOlite Telegram

29. ByteBall

智能合约语言： 声明式语言。

现状： 活跃

说明：

一般来说，DAG具有更高的通量，更好的可扩展性，但是实现此需要付出一些代价。由于链的类树形结构，Byteball等DAG平台不能像以太坊那样很好地支持智能合约。

图 图片来自于DAG区块链白皮书。

Byteball的DAG结构

对于以太坊等区块链，链的结构是线性的,开发人员可以定义交易的顺序。但是DAG并未过多考虑顺序问题，只是关注交易是否有效，是否会产生冲突。因此，DAG适用于哪些并不涉及交易顺序问题的交易。

Byteball与其它DAG的不同之处在于，它实现了Oracle去解决交易顺序问题。Oracle的作用是追踪所有交易的执行，维护网络中所有交易的全局顺序。这样通过使用Oracle，可以实现需要准确交易执行顺序的智能合约。

此外，用户无需具备开发人员技能才能理解或编写合约，也无需唯开发人员马首是瞻。每个用户都可以理解合约的意思，正如正式法律合约一样。

下图显示了Byteball中智能合约的形式：

图 构建一个Byteball智能合约

这使得Byteball智能合约潜在具有更广泛的前景，可跨越开发人员社区，让更广泛的大众使用。

学习资源： Byteball白皮书，Byteball的Medium博客。

Byteball Reddit | Byteball Github | Byteball Telegram

30. XTRABYTES

智能合约语言： 无特定语言。

现状： 不活跃。

说明：

DApp开发人员可以通过XTRABYTES的分布式命令消息API（DICOM API，Distributed Command Message API）访问其核心功能和数据。DICOM API使得开发人员可使用多种编程语言实现DApp代码。我们称此为“代码可感知”。开发人员只需在代码中调用API函数。这使得各类开发人员都可快速上手XTRABYTES DApp的开发。

学习资源： XTRABYTES的Medium博客，XTRABYTES™ (XBY)的Medium博客。

Xtrabytes Reddit | Xtrabytes Github |Xtrabytes Telegram

31. PolkaDot

现状： 不活跃。

说明：

可并行链（Parachain）是区块链的一种简化形式，它将安全付诸于由“中继链”提供，而非自身提供。中继链的名称来自于它不仅为所附着的可并行链提供安全，而且为二者间的安全消息传递提供保证。可并行链的一个关键特性是所执行的计算是天生独立的。在确定哪些交易间会产生“冲突”时，使用图灵完备智能合约的完全通用系统会存在问题，这意味着那些潜在可并行的交易通常是顺序执行的，进而浪费了有价值的计算时间。在可并行链之间划分明显界限，这使得我们可以全部一次性执行各链上的交易，而不用担心交易间会产生冲突。如果有十条可并行链，那么可以使用同一安全源执行十倍的工作。

Polkadot不仅支持直接连接链，而且支持完全托管但可连接链。可并行链，或是使用更多网络共识机制获得共识的原生支持链，将可从Polkadot的安全池机制中获益。安全池还支持每个可并行链（以及中继链）使用整个网络的验证者，向整个网络提供安全。这意味着每个可并行链将从整个生态系统的网络效应中受益。如果可并行链与Polkadot兼容，那么它就可以使用Polkadot共识机制的安全。

图 Parachain和Bridge生态系统

对于其它具有自身状态历史和共识方法的现有项目，Bridge担当支持这些链连接到Polkadot的连接层。Bridge实现将具有智能合约能力的区块链连接到Polkadot，而无需对这些链的原生协议做任何修改。Parity Technologies最初的工作就聚焦于使用Bridge连接两个类以太坊链。例如，它可以在以太坊的PoW链和以太坊的PoA链之间（即两个链之间的账户）相互交换价值。

比特币脚本和EVM这类模型的核心设计目标是互操作性，但是使用这类模型的系统需要实现各个部分而支付不断增长的执行代价，其中不仅仅是那些设计上可被其它运行在同一网络上的其它系统可访问访问的部分。与之相对比，Polkadot的可并行链通过异步消息传递实现相互通信，这样只需在可并行链的接触边界上支付数据唯一性的代价。

注意，创建一种提供完全通用、图灵完备智能合约框架的可并行链是完全可能的。一个简单的例子是EVM提供的可并行链。出于上述原因，在该可并行链上实现的合约不仅将受益于以太坊智能合约的通用性和互操作性，而且也会受限于这些特性。首要差异在于它完全是主动要求加入（opt-in）的。Polkadot的最强大的特性之一，就是在考虑了具备集成一些关注解决方案的能力的同时，保持了完全通用框架的可选择性。

学习资源： PolkaDot的Medium博客, Polkadot。

Polkadot Reddit | Polkadot GitHub | Pokadot Telegram

32. Radix

智能合约语言： JavaScript，TypeScript。

现状： 不活跃。

说明：

Scrypto是一种状态机，它为运行于其上的虚拟机提供安全和功能抽象。如可能，Scrypto将为虚拟机提供接口，进而执行任何语言编写的脚本。

规划实现的JavaScript模块，是一种与Scrypto状态机交互的虚拟机。

学习资源： Radix开发人员入门，Radix DLT的Medium博客。

Radix Reddit | Radix Github | Radix Telegram

33. Exonum

智能合约语言： Rust，并正在考虑与Java的绑定。

现状： 活跃。

说明：

“服务”（Service）实现了指定用于Exonum应用的业务逻辑。服务是Exonum框架的主要扩展点，它具有与其它区块链中智能合约同样的作用。

图 Exonum服务的架构

开发Exonum服务类似于Web或企业平台中的开发服务，二者具有相同的主要组件，分别为：

端点（Endpoints）

一个服务包括了一组实现为REST API的端点。服务使用端点与外部世界交流。Exonum框架担当中间件，在服务间分发请求，并对服务开发人员提供抽象的数据序列化/去序列化、访问控制以及其它常见中间件任务。

Exonmu具有三种类型的服务端点：

Exonum智能合约与区块链使用的其它模型的关键区别如下：

学习资源： Exonum官方文档，Bitfury团队的Medium博客。

Exonum GitHub | Exonum Reddit | Exonum Telegram

34. Universa

智能合约语言： Javascript。

现状： 活跃。

说明：

为了理解Universa智能合约的工作机制，下面我们分各个部分介绍。

参与方（Party）

Universa的每位参与者称为“参与方”（Party）。参与方可以完全匿名，或者是标识的实体。有多种方法标识一个参与方。在根合约中，参与方可如下标识：

参与方可以在合约记录中添加自身的其它细节，例如名字、昵称、社会保险或护照号码等。

合约内容

1.组成部分

Universa网络知道定义和状态，其余部分从不发送到网络。附件是非常重要的部分，其中常常包含敏感的私有信息。尽管该信息在合约状态和定义中被签名引用，因此受到很好的保护，但是最好的保护方式是不将附件传递到Universa网络中。

由此，合约整体只在各涉及的参与方间交换，可使用任何适用的传递方式，例如电子邮件、聊天软件、云、USB Flash等。附件的不可变性由合约中的签名引用保证，进而被参与方签名，并在网络上验证通过。

信任链的工作机制为：

  1. Universa网络批准合约的修改，提供注册时间，确保状态和定义的不可变性。
  2. 对修改签名的参与方通过签名确认状态和定义的正确性，处理所有提及的附件并确认同意。
  3. 状态和定义中的经签名的引用确保了存储在客户存储某次中的相应附件的不可变性。

2. 脚本

没有脚本，就无法体现智能合约的智能。Universa智能合约支持以附件形式添加JavaScript脚本。脚本可以完全自动化地实现客户需要执行的操作、生成新的合约并处理事件。第三代Universa客户甚至可以使用GUI客户端运行自治Web服务或Web应用，以GUI应用方式与用户接口一并执行工作流自动化。Universa的目标是借助于集成Universa平台和服务，支持智能合约实现全功能应用。

Universa也可使用Coffeescript等其它一些可编译为纯JavaScript的语言，甚至可作为附件集成到合约中。但是在执行时，只会使用经签名的编译后JavaScript集合。

脚本被客户软件在客户环境中执行。Universa网络甚至看不到脚本，但是它总是会检查结果，以确认与合约定义和状态的一致性。这意味着，即便脚本会执行一些禁止行为，网络也不会接受执行结果。通常，更简单的方法并非尝试检查脚本源中隐含的漏洞，而是在知道一些许可和条件的情况下限制所允许执行的操作。相比脚本而言，许可DSL更干净并直接。由Univerda远程执行的许可检查也不会被脚本所跳过，检查是本地执行的，不会被传递到Univerda节点上。

脚本的一般执行循环为：脚本被用户或一些事件激活，或是在服务器环境中激活，例如输入合约，或集成比特币服务的支付通知等。进而执行脚本，修改其状态（每个脚本具有可操作的本地存储，并可以访问合约链），创建新的Universa修改并批准，生成合约。如果有必要，合约将通过任何连接通信工具发送到网络。事实上，脚本允许使用HTTPS API连接任何网络。

3. 表示

智能合约是对象（数据结构或哈希）的一种树结构，可使用任何现代格式存储，例如JSON、YAML、XML、BOSS等任何可保存数组、结构、字符串和数字的格式。基于YAML的DSL表示通常用于新合约模板。在网络中，合约通常以BOSS格式序列化，因为这种方式是保存二进制数据的最好方式，在Universa中的键、签名和二进制ID等中广泛使用。

封装（capsule）

每个智能合约被打包为一种受严格保护的、经签名的容器，称为“封装”（Capsule）。封装由封装体和一组扩展签名组成。封装体中打包了二进制合约内容，以及一组扩展签名。每个扩展签名对封装体和属主类型、指纹和时间戳做签名，可以使用很多电子签名类型。相应的公钥（或其匿名ID）通常在合约体中，这样系统可以检查所提及的密钥是否用于对合约签名。

合约的封装包含了加密数据，以此作为Universa网络所知道的合约部分。封装数据中不应该包括任何敏感的私有数据，并必须作为经签名的引用附在合约中（例如，保存在外部文件中），永远不会传递到Univerda网络上。这种设计不仅降低了无必要的网络流量，而且保护了私有信息。

学习资源： Universa官方文档，Universa的Medium博客。

Universa Reddit | Universa GitHub | Universa Telegram

35. Urbit

智能合约语言： Hoon。

现状： 活跃

说明：

Urbit是个人服务器的一种端到端的安全网络，构建于一种完全重建（clean-slate）的系统软件堆栈之上。它使用以太坊实现其功能。

可以将Urbit简单地看成是一种“个人区块链”。和区块链一样，Urbit也是一种确定性的虚拟计算机。其语义定义为将其事件历史映射为当前状态的生命周期冻结函数。不同于区块链，Urbit实例是一个用于单用户的私有计算机，而非所有人均可使用的公有记录。

Urbit的生命周期函数实现为：一个称为“Nock”的微解释器（nano-interpreter）将一种称为“Hoon”的函数式类型语言编译为Nock。使用Hoon编写一种事件驱动的操作系统Arvo。Nock上的所有事物均可在Urbit自身的中继包网络Ames上升级。在使用测试密钥的情况下，Ames是活跃并稳定的。

Urbit解释器可运行于任何Unix系统上。Urbit服务器是一种单层存储，它可以是数据库，也可以是应用引擎。每个Urbit事件是一个交易。Urbit在语义上是冻结的，不能调用Unix。

用户的Urbit实例就是用户的个人服务器。Urbit最终将包含并管理整个数字化生命周期。基于安全或隐私上的权衡考虑，用户可以选择是在家，还是在云上计算。但是，Urbit的形式化语义使得交付比迁移更为棘手，因此用户不应锁定于使用某个计算提供商。

学习资源： Urbit官方文档，Urbit主页。

Urbit GitHub | Urbit Reddit | Urbit Telegram

36. Soil

优点：

与以太坊一致。

不足：

与以太坊一致。

智能合约语言： Solidity。

现状： 活跃。

说明： SOILCoin是一种与以太坊并行的加密货币，它使用了智能合约和DApp，运行在由使用Dagger算法的区块链技术提供安全的“全球计算网络”上。这种EVM是由一种称为“SOIL”的数字代币推动的。SOIL通过PoW挖矿获得，并充当在SOIL币网络上运行计算过程的瓦斯气体。

学习资源： Soil文档。

37. Expanse

优点：

与以太坊一致。

不足：

与以太坊一致。

智能合约语言： Solidity。

现状： 活跃。

说明： Expanse被认为是以太坊的首个稳定分支实现，其智能合约实现与以太坊相同。

学习资源： CryptoZombies，Solidity文档，OpenZeppelin。

38. Ubiq

优点：

与以太坊一致。

不足：

与以太坊一致。

智能合约语言： Solidity，

现状： 活跃，

说明： Ubiq是以太坊的一个分支实现，并做了部分改进。这些改进并未影响以太坊的智能合约实现。

学习资源： CryptoZombies，Solidity文档，OpenZeppelin，Alex Sterk的Medium博客。

39. Ethereum Classic

优点：

与以太坊一致。

不足：

与以太坊一致。

智能合约语言： Solidity。

现状： 活跃。

说明： Ethereum Classic是以太坊的一个分支实现，其智能合约与以太坊相同。

学习资源： CryptoZombies，Solidity文档，OpenZeppelin。

40. Monax

优点：

与以太坊一致。

不足：

与以太坊一致。

智能合约语言： Solidity

现状： 活跃

说明： Monax重新实现了EVM，并提供了SDK。

学习资源： Monax docs

其它一些智能合约平台

其中还包括OmniLayer(dexx)、Ardor等。本文不再一一列举。

结束语

内容到此为止。如果读者发现其中有所遗漏，或是存在错误，欢迎在评论中留言。

感谢阅读。

作者简介

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

添加新批注
在作者公开此批注前，只有你和作者可见。
回复批注