目录
1. 以太坊（ Ethereum ）
优点：
不足：
智能合约语言： Solidity
现状： 活跃。
说明：
以太坊是首批在区块链中引入智能合约概念的平台之一，并得到了开发者社区的最大支持。它宣称实现了图灵完备的智能合约平台。合同代码由每位以太坊网络中的矿工在 EVM（以太坊虚拟机）上执行。它是最广为使用的区块链项目平台。
尽管以太坊平台可安全使用，但是其因用户实现代价问题而备受批评。此外，以太坊平台缺乏可扩展性，会导致交易速度不高，不适合当前的现实世界应用。
平台使用 Solidity 语言。Solodity 可以很好地实现图灵完备，但是缺乏现代语言的灵活性，存在的问题包括：
上述问题表明，为适应现代语言的灵活性，该智能合约语言依然需要进一步发展。
有资料列出了 Solidity 存在的 62 个问题。
学习资源： CryptoZombies 主页， Solidity 官方文档， OpenZeppelin ，以太坊的 Medium 博客。
2. Quorum
优点：
- 图灵完备。
- 通过使用 constellation ，添加了支持网络中两个以上参与者间发送私有交易的特性，因此更适用于企业用户。
- 将瓦斯（GAS）价格降至零，但依然保持瓦斯限制。这样 Quorum 在利用瓦斯限制所提供的安全特性的同时，将交易代价（即瓦斯价格 * 瓦斯限制）降至零。
不足：
- 开发人员社区相对不大。
- 因为也使用 solidity 作为合约语言，因此具有和以太坊同样的不足之处。
智能合约语言： Solidity
现状： 活跃
说明：
简而言之：
Quorum 是以太坊智能合约平台的一种版本，它提供免费的交易，并且还能够使用 constellation 完成各参与方间的私有交易。
Quorum 维护了两个账本，即公开的和私有的。公开账本被公开交易修改，私有账本只针对私有交易所涉及的各方，被私有交易修改。
Quorum 与以太坊联系密切，它们使用同一核心平台和语言。因此 Quorum 也同样继承了以太坊智能平台的优缺点。
学习资源： Quorum 文档， CryptoZombies ， Solidity 文档， OpenZeppelin 。
3. Wanchain
优点：
不足：
- 和以太坊一样。
智能合约语言： Solidity
现状： 活跃。
说明：
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
优点：
智能合约语言： Sophia ， Solidity ，Varna
现状： 活跃。
说明：
æternity 智能合约的既定功能目标是支持在链上执行代码。也就是说，代码执行由矿工验证，并且可以改变链状态。
æternity 智能合约的设计和实施还具有下述非功能性目标，按重要性顺序列出为：
- 合约的执行应该是安全的。
- 合约的执行应该是高效的、可扩展的。
- 合约的执行应该是低代价的。
- 具有从以太坊智能合约迁移的简单方式。
目标一：合约执行应该是安全的
安全合约指的是用户可以指定并自动地验证合约的属性。
为了实现安全合约，æ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 依靠比特币实现共识，但它也支持以太坊智能合约。下面给出其在更高层级上的工作机制：
- 用户使用 solidity 或 Serpent 等语言编写智能合约代码，并编译为更紧凑的格式（字节码）。
- Counterparty 将创建并广播一个 publish 交易，将交易代码嵌入到比特币区块链中。这是以一种可花费的方式实现的，并不会“污染”整个区块链。
- 交易一旦发布，智能合约就“存活”于一个指定的地址上，看上去和正常的比特币地址毫无二至，只是地址以字母 "C" 开头。
- 用户进而可以使用 Counterparty 创建并广播 execute 交易，调用智能合约代码中指定的函数或方法。
- 一旦 execute 交易在广播后得到比特币挖矿者的确认，每个在运行的 Counterparty 节点将接收到该请求，并执行其中的方法。智能合约代码在执行中，会修改存储在 Counterparty 数据库中的合约状态。鉴于每个 Counterparty 节点具有相同的合约代码（由比特币机制确保）和相同的 EVM 代码，并且所有代码均为确定性的，因此每个节点将实现同样的状态更改。
- 其他用户也可以向智能合约发送 Counterparty 资产。这些资产将得到保存，并用于今后的 execute 调用。该机制对于融资等类型的合约非常有用。
- 从本质上看，我们所看到的智能合约发布，以及执行合同中特定功能或方法的命令，二者均为比特币区块链上的实际交易。因此，这两个操作会受到比特币约 10 分钟阻塞时间的限制。但是，执行智能合约代码一旦启动，通常会以节点处理速度运行。
比特币的 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
优点：
- 基于广为使用的.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/ 。
| 对比项 | 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 的业务规则经历了近七年的发展。其它大多数区块链在构建时都没有考虑灵活性。
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 是安装在独立节点层面的，而非网络层面。
从结构上看，CorDapps 包括下列主要组件：
- 状态（State），定义了达成共识的事实。
- 状态表示了账本上的事实。
- 要更改状态，首先将当前状态作为历史，然后创建一个更新的状态。
每个节点都具有一个保险存储，用于存储节点本身的所有相关状态。
- 合约（Contract），定义了组成有效账本更改的情况。
合约：
- 一个有效的交易必须被它的每个输入和输出状态的合同所接受。
- 合约是使用 Java 或 Koltin 等 JVM 编程语言编写的。
- 合约的执行是确定性的，合约只根据交易的内容确定是否接受该交易。
- 在一些情况下，交易的有效性取决于一些外部信息，例如兑换率等。在这些情况下，需要先知（Oracle）的参与。
先知：
- 服务（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 官方文档。
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 包括两个层面，一个层面是形式化指定的虚拟机和语言框架，另一个层面是形式化指定的语言，便于自动验证人类可读的智能合约代码。
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 源自于有限状态自动机理论，并在功能中添加了时间上的考虑。因此，我们最好首先了解自动机理论。幸运的是，对此有多种出版物。其中，斯坦福大学给出了如下的很好描述：
“（自动机）是一种执行特定处理的自动化过程……自动机理论针对被称为“自动机”的单机中的计算逻辑。计算机科学家通过自动机理论理解机器的计算功能，并解决问题。更重要的是，自动机理论提出了哪些功能可定义为可计算的，哪些问题可定义为可判定的。”——斯坦福大学教程
如上所述，有限状态自动机是自动机理论的扩展。有限状态自动机是一种建模有限数据逻辑的工具，用于理解自动机最终的生成状态。下面给出一个实际例子。该例子建模了一个自动推拉门，其中左图表示了门，右图表示了状态。
在上例模型中，圆圈表示状态，箭头表示状态转移。图中最左边的箭头表示开始状态。系统（即本例中的滑动门）的状态有两种，开门（OPEN）和关门（CLOSED）。对于本例而言，输出情况如下表所列：
如果系统经历了如下事件序列：“FRONT，REAR，NEITHER，FRONT，BOTH，NEITHER，REAR，NEITHER”，那么状态转移如下图所示：
时间自动机（TA，Timed Automata）将时间引入了自动机的输入。台灯的状态就是一个使用系统时钟的很好示例。如果在一定时间内按下开关，台灯将会变暗，而不仅仅是打开或关闭。台灯的状态图如下所示：
上面给出的调节台灯状态图中，存在三种状态，即 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 不能跟上其它平台的发展。在 2018 年 4 月 4 日发表的一次访谈中指出：
使用 Burst AT 的主要问题在于，矿工运行每个操作代码（即一行代码）都需要一个爆裂币（BRUST）。这使得即便运行从智能合约本身返回一个 BRUST 这样非常简单的合约，也需要花费大约二十个 BRUST。如果合约的运行成本能降低到每个操作码需 0.001 个 BRUST，那么在引入编译器等技术后，该平台才可以与以太坊等其它平台一争高下。
学习资源： BurstAT 的 wiki 页面， Burstcoin_dev 的 Medium 博客。
28. 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 平台不能像以太坊那样很好地支持智能合约。
Byteball 的 DAG 结构
对于以太坊等区块链，链的结构是线性的,开发人员可以定义交易的顺序。但是 DAG 并未过多考虑顺序问题，只是关注交易是否有效，是否会产生冲突。因此，DAG 适用于哪些并不涉及交易顺序问题的交易。
Byteball 与其它 DAG 的不同之处在于，它实现了 Oracle 去解决交易顺序问题。Oracle 的作用是追踪所有交易的执行，维护网络中所有交易的全局顺序。这样通过使用 Oracle，可以实现需要准确交易执行顺序的智能合约。
此外，用户无需具备开发人员技能才能理解或编写合约，也无需开发人员说是什么就信什么。每个用户都可以理解合约的意思，正如正式法律合约一样。
下图显示了 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 共识机制的安全。
对于其它具有自身状态历史和共识方法的现有项目，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 服务类似于 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）。参与方可以完全匿名，或者是标识的实体。有多种方法标识一个参与方。在根合约中，参与方可如下标识：
参与方可以在合约记录中添加自身的其它细节，例如名字、昵称、社会保险或护照号码等。
合约内容
1. 组成部分
- 定义。定义在修改中是不可变的，其中包括发布者、发布时间戳、许可（一些许可也可以更改状态）和创建者希望不可更改的所有内容。
- 状态。状态是在修改中可以更改的可变部分，其中包括修改编号、创建者、时间戳、指向前后修改的引用、可更改角色，在一些情况下还包括许可和任何可变客户数据。
- 附件。在定义或状态中医签名引用形式提及的所有文件。
Universa 网络知道定义和状态，其余部分从不发送到网络。附件是非常重要的部分，其中常常包含敏感的私有信息。尽管该信息在合约状态和定义中被签名引用，因此受到很好的保护，但是最好的保护方式是不将附件传递到 Universa 网络中。
由此，合约整体只在各涉及的参与方间交换，可使用任何适用的传递方式，例如电子邮件、聊天软件、云、USB Flash 等。附件的不可变性由合约中的签名引用保证，进而被参与方签名，并在网络上验证通过。
信任链的工作机制为：
- Universa 网络批准合约的修改，提供注册时间，确保状态和定义的不可变性。
- 对修改签名的参与方通过签名确认状态和定义的正确性，处理所有提及的附件并确认同意。
- 状态和定义中的经签名的引用确保了存储在客户存储某次中的相应附件的不可变性。
- 脚本
没有脚本，就无法体现智能合约的智能。Universa 智能合约支持以附件形式添加 JavaScript 脚本。脚本可以完全自动化地实现客户需要执行的操作、生成新的合约并处理事件。第三代 Universa 客户甚至可以使用 GUI 客户端运行自治 Web 服务或 Web 应用，以 GUI 应用方式与用户接口一并执行工作流自动化。Universa 的目标是借助于集成 Universa 平台和服务，支持智能合约实现全功能应用。
Universa 也可使用 Coffeescript 等其它一些可编译为纯 JavaScript 的语言，甚至可作为附件集成到合约中。但是在执行时，只会使用经签名的编译后 JavaScript 集合。
脚本被客户软件在客户环境中执行。Universa 网络甚至看不到脚本，但是它总是会检查结果，以确认与合约定义和状态的一致性。这意味着，即便脚本会执行一些禁止行为，网络也不会接受执行结果。通常，更简单的方法并非尝试检查脚本源中隐含的漏洞，而是在知道一些许可和条件的情况下限制所允许执行的操作。相比脚本而言，许可 DSL 更干净并直接。由 Univerda 远程执行的许可检查也不会被脚本所跳过，检查是本地执行的，不会被传递到 Univerda 节点上。
脚本的一般执行循环为：脚本被用户或一些事件激活，或是在服务器环境中激活，例如输入合约，或集成比特币服务的支付通知等。进而执行脚本，修改其状态（每个脚本具有可操作的本地存储，并可以访问合约链），创建新的 Universa 修改并批准，生成合约。如果有必要，合约将通过任何连接通信工具发送到网络。事实上，脚本允许使用 HTTPS API 连接任何网络。
- 表示
智能合约是对象（数据结构或哈希）的一种树结构，可使用任何现代格式存储，例如 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 等。本文不再一一列举。
