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

区块链技术的精华：四十种智能合约支持平台（一）

正文：

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

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

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

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

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

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

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

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

           a93e64a691d5aff8f78cd63130cf23b89182d235

下面详细列出四十种智能合约平台/项目。本文是该系列文章的第二篇，我们继续给出10种支持平台，其中包括著名的EOS、HyperLedger Fabric、Corda等。

11. EOS

优点：

使用WASM快速执行合约。
无交易费用。
智能合约语言使用C++，增加了编程的灵活性。

不足：

想要“超越”以太坊，依然需要得到大量的社区支持。

智能合约语言： 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中需要考虑实现的一些限制：

多签名（MultiSig）：指定操作需要哪些密钥验证？特定步骤的执行需要哪一方的同意？MultiSig指一个账户发起的交易需要多方的签名。签名权重和阈值表示了各方在所创建签名中的重要性。
批处理/原子性：那些操作必须一并发生或一同失败？要强制所有操作失败或通过需要什么机制？批处理表示在一个交易中包括多个操作。原子性保证了给定的一系列操作一旦提交网络，如果其中一个操作失败，那么该交易中的所有操作都会失败。
序列：如何确定一系列操作的处理顺序？其中的局限性和依赖关系如何？在Stellar网络中，序列以顺序编号表示。在交易操作中使用序列编号，可确保存在其它交易提交执行情况下指定交易不会成功执行。
时间范围：何时可以开始处理一个交易？时间范围指定了一个交易有效的时间区间限制。使用时间范围实现了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的合约结构非常简单，其中四个最重要的函数是：

PutState：创建新的资产（asset），或更新已有资产。
GetState：检索资产。
GetHistoryForKey：检索更改历史。
DelState：“删除”资产。

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

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

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

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

19. Corda

优点：

专门设计用于金融领域。

不足：

每个Corda的去中心化应用CorDapp是安装在独立节点层面的，而非安装在整个网络层面。

智能合约语言： Java, Kotlin
现状： 活跃。
说明：

CorDapp简介

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

图 CorDapp的架构。

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

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

状态表示了账本上的事实。
要更改状态，首先将当前状态作为历史，然后创建一个更新的状态。

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

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

合约：

一个有效的交易必须被它的每个输入和输出状态的合同所接受。
合约是使用Java或Koltin等JVM编程语言编写的。
合约的执行是确定性的，合约只根据交易的内容确定是否接受该交易。
在一些情况下，交易的有效性取决于一些外部信息，例如兑换率等。在这些情况下，需要先知（Oracle）的参与。

先知：

事实（fact）可作为命令组成部分包括在交易中。而先知就是一种服务，它只签名那些其中包括的事实为真的交易。

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

节点是一种JVM运行时，提供运行Corda软件中的唯一网络标识。
节点提供两种与外界交换的接口：
- 网络层：用于与其它节点交互。
- RPC：用于与其他节点所有者交互。

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

持久层，用于存储数据。
网络接口，用于与其它节点的交互。
RPC接口，用于与其他节点所有者的交互。
服务中枢节点，支持节点工作流调用节点的其它服务。
CorDapp接口和提供者。通过安装CorDapp可实现节点的扩展。

序列化白名单（Serialisation whitelistes）

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

编写CorDapp

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

工作流子类FlowLogic；
状态的接口实现ContractState；
合约的接口实现Contract；
服务子类SingletonSerializationToken。

学习资源： 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官方文档。

本篇小结

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

作者简介：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

创作场景

区块链技术精华：四十种智能合约支持平台（二）