大家已经看到，区块链正在改变我们的世界。
区块链解决了人类一直面对的一个重大问题，信任问题。区块链可为任何需信任的事物创建一种不可更改的追溯印迹，由此解决信任的问题。
当然，该技术的强大还不止于此。
它在上述特性上继续扩展，用以创建一经制定就必须准守的规则，其中的每个行为都会产生相应的反应。其实，就是智能合约。
本文列出了十种支持或是用于开发智能合约的平台或项目，它们均在不断的演进中。如果读者发现本文存在任何遗漏或错误，希望能在评论中提出。
附： 本文对智能合约平台 / 项目的评估，主要考虑的是影响智能合约功能的一些因素，而不是整体功能评估。
1. 以太坊（Ethereum）
优点：
图灵完备。拥有可能是规模最大的开发人员社区。最支持智能合约的平台。
不足：
它使用 Solidity 语言。与 C++、C#、Python 等现代开发语言相比，Solidity 并不具有优势。如果智能合约编写的效率不高，那么实现代价巨大。
智能合约语言：Solidity
现状： 活跃。
说明：
以太坊是首批在区块链中引入智能合约概念的平台之一，并得到了开发者社区的最大支持。它宣称实现了图灵完备的智能合约平台。合同代码由每位以太坊网络中的矿工在 EVM（以太坊虚拟机）上执行。它是最广为使用的区块链项目平台。
尽管以太坊平台可安全使用，但是其因用户实现代价问题而备受批评。此外，以太坊平台缺乏可扩展性，会导致交易速度不高，不适合当前的现实世界应用。
平台使用Solidity语言。Solodity 可以很好地实现图灵完备，但是缺乏现代语言的灵活性，存在的问题包括：
输入和返回参数不支持多维数组（例如，字符串数组）。对此问题存在替代解决方案。智能合约函数支持的参数数量有限（不能多于十六个）。否则会给出“stack too deep”错误。
上述问题表明，为适应现代语言的灵活性，该智能合约语言依然需要进一步发展。
有资料列出了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
优点：
引入了新的智能合约语言和 VM，实现代码的快速安全执行。使用状态通道和高效的方式执行合约，维持低代价交易。通过提供一种版本的 EVM，简化了将 EVM 合约迁移到?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 上执行同等计算还是要快一些。
智能合约是以数字形式定义的承诺，控制数字资产并涵盖合约参与者约定的权利和义务。它由计算机系统自动执行。在基于区块链的智能合约中，数据管理、事务验证和状态处理都是在区块链上完成的，区块链提供完备的状态机接受和处理各种智能合约程序。