摘要： 智能合约是以数字形式定义的承诺，控制数字资产并涵盖合约参与者约定的权利和义务。它由计算机系统自动执行。在基于区块链的智能合约中，数据管理、事务验证和状态处理都是在区块链上完成的，区块链提供完备的状态机接受和处理各种智能合约程序。我们在此系统列举四十种支持或是用于开发智能合约的平台或项目，并介绍影响智能合约功能的主要因素。本文是该系列文章的第二篇，给出了其中 10 种支持平台，其中包括著名的 Hyperledger Fabric、Corda 等。
正文：
大家已经看到，区块链正在改变我们的世界。
区块链解决了人类一直面对的一个重大问题，信任问题。区块链可为任何需信任的事物创建一种不可更改的追溯印迹，由此解决信任的问题。
当然，该技术的强大还不止于此。
它在上述特性上继续扩展，用以创建一经制定就必须准守的规则，其中的每个行为都会产生相应的反应。其实，就是智能合约。
本文列出了四十种支持或是用于开发智能合约的平台或项目，它们均在不断的演进中。如果读者发现本文存在任何遗漏或错误，希望能在评论中提出。此外，随着本文作者对这些平台或项目的进一步研究，本文内容将会定期更新。
原文提供在Github上，读者可以拉取下来提出修改建议。
附： 本文对智能合约平台/项目的评估，主要考虑的是影响智能合约功能的一些因素，而不是整体功能评估。
这篇文章花费了原作者数天时间才完成。如果读者喜欢阅读此类内容，想表达感谢和支持，可在此处或下面的 ETH 地址请作者喝杯咖啡：
下面详细列出四十种智能合约平台/项目。本文是该系列文章的第二篇，我们继续给出 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
优点：
基于广为使用的.NET Framwork。
Stratis 使用了由微软提供的 C#软件包，这些软件包经过了全面的验证和测试。
智能合约语言： 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/。
SSC 可使用任何已由 Stellar 社区提供 API 的语言编写，包括 JavaScript、Python、Golang、PHP 等。读者可在Github代码库中找到智能合约的 PHP 例子代码。
SSC 表示了使用各种限制连接在一起并执行的交易组合。下面列出了在创建 SSC 中需要考虑实现的一些限制：
多签名（MultiSig）：指定操作需要哪些密钥验证？特定步骤的执行需要哪一方的同意？MultiSig 指一个账户发起的交易需要多方的签名。签名权重和阈值表示了各方在所创建签名中的重要性。
批处理/原子性：那些操作必须一并发生或一同失败？要强制所有操作失败或通过需要什么机制？批处理表示在一个交易中包括多个操作。原子性保证了给定的一系列操作一旦提交网络，如果其中一个操作失败，那么该交易中的所有操作都会失败。
序列：如何确定一系列操作的处理顺序？其中的局限性和依赖关系如何？在 Stellar 网络中，序列以顺序编号表示。在交易操作中使用序列编号，可确保存在其它交易提交执行情况下指定交易不会成功执行。
时间范围：何时可以开始处理一个交易？时间范围指定了一个交易有效的时间区间限制。使用时间范围实现了 SSC 中的对时间的限制。
学习资源： Stellar智能合约官方文档, Stellar
18. HyperLedger Fabric
优点：
高度模块化的平台。支持用户对性能、扩展性和安全性的高度可控。
不足：
由于合约是部署在节点上而非网络上的，因此用户必须在网络中的每个节点上部署合约。
现状： 活跃。
说明：
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）的一名大二学生。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论