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

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

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

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

正文：

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

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

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

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

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

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

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

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

           a93e64a691d5aff8f78cd63130cf23b89182d235

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

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，简化了形式化验证。形式化验证工具有助于开发人员推理合约，并验证智能合约行为的特定属性。这些验证工作是一些强大的工具，可用于标出并消除一些存在于合约中的漏洞，其中包括非法输入处理、类型不匹配、不明显的非预期代码路径、对作用范围的模糊认识、输入错误、溢出等。例如，如果能够证明没有可以更改契约所有者的代码路径，就可以防止导致奇偶性 multisig 钱包同时被利用（https://paritytech.io/blog/security-is-a-process-a-postmortem-on-the-parity-multi-sig-library-self-destruct.html）的漏洞。现在回头看来，显然该特定属性是有必要的。因此，一些重要的属性完全有可能并未包括在正式规范之中，只有在被一些漏洞利用后才发现其重要性。因此，虽然形式化验证是一种非常强大的工具，但它的有效性仅取决于人类在创建规范时覆盖所有基础的能力。

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），而投注了代币的用户可以对提案进行投票。提案可以是：

• 冻结智能合约/去中心化应用：网络可能会冻结一些用于违法行为的去中心化应用。

• 可撤回交易：一旦在智能合约中出现软件缺陷，会导致上百万美元失窃或损失（例如众所周知的 DAO 和 Parity 事故），网络可以通过投票返还损失的资金，无需对网络做硬分叉。

• 编辑智能合约代码：假定一个 DApp 已发布到网络上，并被上百万用户的使用。一旦在应用中发现软件缺陷，如果是在以太坊网络上，那么人们对于修复该 DApp 束手无策，唯一的做法是取出代码并做修复，然后发布全新的智能合约。但是在 DFINITY 中，人们可以通过向网络提交提案，并在得到社区投票通过后对软件缺陷进行修复。要在以太坊上实现同样的智能合约修复，硬分叉是唯一的手段。

• 升级协议：假定比特币采纳了其后提出的各种代币的全部特性。如果比特币只是要为私有交易、智能合约等添加一些新功能，那么是否完全没有必要为 Zcash（大零币）、以太坊等创建新的代币。这是 DFINITY 潜在的强大之处。BNS 可以在不需要硬分叉的情况下实现协议升级，而比特币则无法做到这一点。原因主要归结为两个方面。第一，人们无法就哪些特性应该添加到比特币中达成协议；第二，添加上述新协议特性只能通过硬分叉实现。而 DFINITY 解决了上述问题。

学习资源： 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具有五个主要组件：

• 关联数据：表示了数据库用于理解语言的属性，即日期、标题、编号和特性等。

• 词汇表：将语言分解为基础定义，即概念和关系。

• 查询：用于从数据库检索信息的工具。

• 推理：用于处理并解释所收集数据的推理器，即通过规则，或合并来自多个数据源的各种数据。

• 垂直应用：这是指 W3C 的业务风险部门。它通过与各个行业的合作，改进研发及协作。其具体内容与本文无关。

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

优点：

• 使用 FAE（快速适用引擎，Fast Adaptation Engine）。FAE 可以将自然语言或其它所需编程语言转译为智能合约代码，进而扩展了智能合约的使用人群。

现状： 活跃。

说明：

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

本篇小结

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

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