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

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

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

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

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

正文：

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

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

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

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

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

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

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

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

           a93e64a691d5aff8f78cd63130cf23b89182d235

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

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 具有三种类型的服务端点：

• 对应于 REST 中 PUT/POST 请求的交易；

• 对应于 REST 中 GET 请求的读取请求；

• 代币管理和维护端点的私有 API，通常外部世界不可访问。

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

• 受限的环境：Exonum 只执行预定义的请求类型，不允许执行从客户接收的非信任代码。这导致更受控的环境，易于实现智能合约的安全性。

• 无隔离：请求处理与系统核心在同一执行环境中处理。这对于提高性能非常有好处，但存在一定的安全危险。

• 本地状态。Exonum 服务可能会定义特定于运行服务节点的本地状态。本地状态可用于管理一些保密信息，例如私钥等。本地状态可使用私有服务端点管理。通过使用本地状态，服务比其它区块链中的服务更加活跃。例如，锚点服务使用本地状态完全自动化锚点交易签名。

• 交易分割处理。交易验证是交易处理中的一个独立步骤。它是在接收到交易后并在交易应用到区块链状态之前立刻执行。验证可能包括认证检查（例如，验证交易签名），以及其它对交易内容的结构检查。同时，交易验证不能访问当前区块链状态。

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

Exonum GitHub | Exonum Reddit | Exonum Telegram

34. Universa

智能合约语言： Javascript。

现状： 活跃。

说明：

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

参与方（Party）

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

• 使用合约内容中的公钥。例如，发布者或属主。

• 使用匿名公钥 ID，支持识别参与方的公钥，并在首次使用之前无需公开。例如，匿名购买。

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

合约内容

1.组成部分

• 定义。定义在修改中是不可变的，其中包括发布者、发布时间戳、许可（一些许可也可以更改状态）和创建者希望不可更改的所有内容。

• 状态。状态是在修改中可以更改的可变部分，其中包括修改编号、创建者、时间戳、指向前后修改的引用、可更改角色，在一些情况下还包括许可和任何可变客户数据。

• 附件。在定义或状态中医签名引用形式提及的所有文件。

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

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

信任链的工作机制为：

1. Universa 网络批准合约的修改，提供注册时间，确保状态和定义的不可变性。

2. 对修改签名的参与方通过签名确认状态和定义的正确性，处理所有提及的附件并确认同意。

3. 状态和定义中的经签名的引用确保了存储在客户存储某次中的相应附件的不可变性。

4. 脚本

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

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

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

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

1. 表示

智能合约是对象（数据结构或哈希）的一种树结构，可使用任何现代格式存储，例如 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