深入比较以太坊、比特币和比特币现金智能合约之间的差异

以太坊、比特币和比特币现金的智能合约有何不同？ 下面说一下执行方式、编写方式、合约交互等方面。

原标题：《技术分析 | 关于以太坊、比特币和比特币现金的智能合约》

作者：Rosco Kails，CashScript 的发明者

编译：一级仓库（）

尽管以太坊是第一个拥有图灵完备智能合约的平台，但已经可以使用一种称为比特币脚本的语言在比特币上创建基本合约。 比特币现金最近一直在改进其智能合约功能。 虽然不如以太坊先进，但它们都以自己独特的方式和优势支持链上智能合约的存在。

本文重点介绍这三个平台上智能合约之间的显着差异。 由于重点是智能合约和脚本功能，因此这里不会讨论平台或区块链的基础知识。 本文也在此介绍链上智能合约，以及目前存在的几种二层智能合约解决方案，例如RSK。 这些解决方案绝对值得讨论，限于篇幅我就不做很深入的研究了。

以太坊：它有自己的状态并且是图灵完备的

以太坊是迄今为止最大的智能合约平台，其智能合约是使用以太坊虚拟机（EVM）实现的，这是一个图灵完备的虚拟机。 这意味着只要有足够的资源，EVM 就可以计算任何东西。 从概念上讲，这类似于许多其他通用平台，例如用于执行 Java 程序的 Java 虚拟机 (JVM)。

解释EVM

但是那些普通平台和以太坊的EVM最大的区别在于，以太坊的智能合约代码是由所有以太坊节点执行的，以验证交易的有效性。 为了奖励执行此代码的节点，所有 EVM 操作码都有相关的 gas 成本，如下图所示。

图：EVM 费用结构

根据使用的操作码，每笔交易都会花费大量的 Gas。 Gas 费用使用以太坊的原生加密货币 ETH 支付。 为了限制这些节点必须在每个区块上执行的计算量，可以在单个区块中使用的气体量有一个限制，称为“区块气体限制”。

在执行智能合约功能期间，合约可以存储和访问必要的数据。 根据其用途，这些数据可以存储在不同的位置，即不同的数据位置。 第一个是“堆栈”，其中包含计算中使用的值。 堆叠中只有前 16 件物品易于取用，因此不适合长期存放。 使用堆栈的计算如下所示。

图：基于堆栈的计算

其次，作为堆栈的补充，“合约内存”可用于存储、检索和传递当前合约执行期间的数据。 可以从内存中取出这些值用于栈上的计算，并将结果存回内存。 这些值仅在当前执行期间持续存在。 在合约执行结束时，合约内存和堆栈被擦除。

最终，数据所在的地方是“合约存储”，它用于在合约执行期间持久保存数据。 代币余额等持久变量存储在合约存储中。 为了数据持久化，合约内存存储在每个以太坊节点上。 所以它的内存就像 RAM，它的存储就像硬盘或持久数据库。

有关以太坊虚拟机如何工作的更多详细信息，请参阅 MyCrypto 的文章。

编写智能合约

尽管所有智能合约都使用 EVM，但大多数智能合约并不是使用 EVM 字节码手写的，就像大多数 JVM 字节码不是手写的一样。 相反，有几种高级语言可用于在以太坊中编写智能合约，最流行的是 Solidity，还有 Vyper，这是一种面向 EVM 的编程语言。 下图包含一个非常简单的 Solidity 智能合约示例。

与智能合约交互

以太坊中的智能合约以字节码的形式存在于以太坊网络中。 这意味着将 Solidity 代码编译为字节码，然后通过发送部署交易将其部署到网络。 这是一种特殊的交易，没有任何接收者，但以字节码作为交易数据。

这些已部署的合约仅作为 EVM 字节码的“片段”存在于网络中，几乎无法单独使用。 为了与它们“交互”，需要提供应用程序二进制接口 (ABI)，其中包括所有公共函数及其参数的列表。 为了让用户更加了解这些合约，Etherscan 等服务有助于验证合约源代码，以便用户在使用合约之前可以检查代码。

所有智能合约都可以通过连接到以太坊节点并使用其 JSON-RPC 接口直接访问。 然而，许多智能合约是通过连接到节点并管理 ABI 的前端应用程序访问的。 这可以使用许多不同的以太坊 SDK 之一（例如 web3.js 或 ethers.js）来完成，它们可以在后台调用 JSON-RPC。 这为合同用户提供了更好的体验，因为最困难的部分是可视化的。

可以通过两种不同的方式与智能合约进行交互：调用和交易。 调用是对合约函数的本地调用，它不会向区块链广播任何内容。 因此，调用过程是“只读”的，不能对合约状态做任何改变，也不会产生任何费用。 交易是真正的“写操作”，确实会广播到网络并包含在区块链中，并会产生矿工费。 以ERC20代币为例，通过调用获取代币余额，通过发起交易转移代币。

智能合约之间的互操作性

以太坊的这些属性（具有图灵完备的 EVM 和持久存储）允许创建在链上运行的任何类型的去中心化应用程序。 一个很好的例子是 DeFi 生态系统，其中包括 Maker、Uniswap 和 Compound 等应用程序，以及 ERC20 和 ERC721 代币标准。 这些应用程序允许具有无限数量的动态参与者的复杂功能。

图：rDai 中的 DeFi 互操作性

最重要的是，智能合约本身可以成为其他智能合约的“参与者”，实现这些合约之间的强大集成和组合。 例如，持有代币余额并将其借给 Compound 或与 Uniswap 进行交易所的智能合约，或者使用 rDai 自动投资 DAI 并将应计利息捐献给慈善机构。

虽然智能合约可以相互交互，但链上的每一笔交易都必须来自外部账户。 因此，以太坊智能合约之间的交互仍然必须由用户通过初始交易来触发。 在这个初始触发之后，合约之间的交互类似于直接访问。

也就是说，一个智能合约可以调用其他智能合约的“只读函数”或触发“写操作”（交易）。 由于只有外部账户才能触发交易，因此智能合约之间的交易称为内部交易或消息调用，以区别于用户发起的交易。

比特币：无状态且简单

所有比特币交易（包括常规转账）均由一种称为“比特币脚本”（Script）的基于堆栈的编程语言支持。 如上所述，以太坊的 EVM 是为图灵完备和可互操作的智能合约而设计的，而比特币脚本有意添加了各种限制并以根本不同的方式工作。

解释比特币脚本

就像 EVM 一样，Bitcoin Script 使用 Stack 来保存值并对这些值执行计算。 但与 EVM 不同的是，堆栈是比特币脚本中唯一可用的数据位置。 这意味着很难存储多个值供以后在合约执行中使用。 更重要的是，这意味着不可能存储或修改在合约执行期间持续存在的值（但 EVM 可以）。

这是以太坊的智能合约与比特币最大的区别。 以太坊的模型是有状态的，而比特币是无状态的。 通俗的理解是，可以认为以太坊类似于常见的命令式可变数据编程范式，而比特币类似于函数不变的数据编程范式。

比特币的模型允许对交易进行独立且更有效的验证，这使得并行化和分片交易变得更加容易。 然而，没有任何可变数据存储，在比特币上创建像以太坊这样复杂的智能合约变得更加困难，例如，ERC20 合约必须跟踪代币余额并进行更改。

除了这些状态差异之外，还有其他因素限制了比特币智能合约的复杂性。 值得注意的是，比特币脚本不支持某些算术函数以及任何形式的循环或递归。 它的合约也有 520 字节的有效大小限制，最多只能包含 201 个操作码。

比特币上的大多数智能合约都属于几类简单合约。 例如，可供多个参与者使用的多重签名合约，或哈希时间锁定合约（HTLC）。

一流的仓库知识：关于哈希锁，可以举个简单的例子。 例如，如果您从我这里购买视频，则通过密码访问该视频。 然后在交易合约里面，我也把视频的访问密码改成了其中一个。 key，如果你想做交易，这个key必须让你知道； 并且一旦你知道（你拿到视频），钱就会付给我以太坊的复杂，整个交易过程必须在规定的时间内完成，如果超过时间，合约也会自动触发。

而且由于比特币上的这些合约非常简单，大部分价值都是通过将不同的合约与其他链下应用程序逻辑相结合来获取的。 通过这种方式，可以组合简单的合约来创建复杂的解决方案，例如闪电网络或跨链拍卖等。

解释比特币交易

比特币中的每一笔交易都是通过所谓的“交易输出”来实现的。 当这些交易输出在一个账户中可用时，它们被称为未花费的交易输出（UTXO）。 这些 UTXO 由锁定脚本（或 scriptPubKey）和指定的使用条件锁定。 当尝试花费 UTXO 时，会提供一个解锁脚本（或 ScriptSig），然后这些脚本一起执行计算。 仅当脚本执行无误且结果值为 TRUE 时，事务才会生效。

与 EVM 一样，所有比特币节点都执行这些脚本来验证交易，但比特币区块链没有 gas 成本的概念，因此矿工按交易数据的字节数付费。 为了限制一个节点要做的工作量，对一些比较密集的脚本操作也做了一些限制。

与智能合约交互

比特币智能合约的编写采用P2SH模型（一级仓注：有翻译为“支付给脚本哈希”）。 P2SH 模式中的锁定脚本包含脚本哈希，需要为完整脚本（称为赎回脚本）提供解锁脚本，并为该赎回脚本提供解锁脚本。 下图显示了这种模式。

图：P2SH模式

一级仓知识：引入P2SH模式简化复杂脚本的使用（传统机制是P2PKH），将复杂的锁定脚本编译成简单的20字节哈希脚本，就像比特币地址是A 20基于 Base58 编码的字节公钥。 P2SH 与传统的 P2PKH 方式最大的区别在于，设置转账条件的人从发送方变成了接收方。 通过在赎回脚本中添加各种转出条件，可以实现多种形式的交易，如多重签名交易。

比特币节点分两个阶段验证这些智能合约交易。 首先，对兑换脚本进行哈希处理，并根据锁定脚本中的哈希值进行检查。 如果它们匹配，则使用“锁定脚本”解锁“救赎脚本”，就好像“救赎脚本”是原始锁定脚本一样。

因为只有字节码的哈希值存储在链上，所以完整的字节码必须存储在链外并包含在任何合约执行的解锁脚本中。 因此，比特币智能合约的“部署”是免费的，但后来执行合约的成本更高。 相反，以太坊的初始部署成本相对较高，而后期的合约执行成本较低。

这些部署差异鼓励结合使用这两种类型的智能合约。 一个很好的例子是 LocalCryptos，它支持以太坊和比特币的非托管本地交易。 对于以太坊，它使用一个大的智能合约来跟踪所有交易，而对于比特币，它为每笔交易创建单独的合约。

编写智能合约

虽然以太坊有多种高级语言可以编译成 EVM 字节码，但比特币对此关注较少。 尽管可以使用比特币脚本构建的系统很复杂，但合约本身通常很简单。 因此，几乎不需要抽象出底层系统。 而且由于比特币合约有大小限制和每个额外字节的高成本，因此保持合约“尽可能小”很重要。

虽然这些高级语言在比特币中不那么重要，但它们确实存在。 Ivy 是比特币中“最精致”的高级语言，由 Dan Robinson 于 2017 年创建。下图显示了一个用 Ivy 编写的智能合约示例。 该合约可用于发送资金，如果接收方没有及时花费，发送方可以收回这些资金。

最近，Blockstream 的几位研究人员发布了 Miniscript，这是一种专注于智能合约的分析和可组合性而不是抽象底层系统的语言。 鉴于比特币合约通常缺乏抽象的复杂性，这似乎是正确的选择。

比特币现金：可组合的功能

以上一方面是以太坊，它能够创造出许多强大且有用的智能合约，完全存在于以太坊链上，同时，由于其有状态（Stateful）的特性，也带来了可扩展性问题。 另一方面，比特币的智能合约无状态（Stateless）模型允许对智能合约交易进行独立简单的验证，但其脚本系统限制了合约的实用性。

在分叉之前，比特币现金和比特币有着相同的历史，因此它们的底层脚本系统在功能上是相同的，而比特币现金也从这些相同的方面受益。 从那时起，比特币现金社区的很大一部分已经认识到需要“更有用的智能合约”。 比特币现金启用了新功能，使其智能合约更有用，同时保留了允许对比特币进行无状态验证的基本属性。

BCH功能升级

要了解比特币现金智能合约的可能性，我们需要看看它一年两次的网络升级。 自 2017 年最初的硬分叉以来，每年 5 月和 11 月都会进行这些网络升级。我们专门讨论了对比特币脚本引擎的更改，尽管也进行了一些其他改进，例如 Schnorr 签名。

在比特币的早期，一些操作码由于不安全的使用而被禁用。 在比特币现金分叉后的第一年内以太坊的复杂，比特币-ABC 节点的开发人员解决了这些问题并重新引入了功能略有修改的操作码，如下图所示。 最重要的是，升级使得在比特币脚本中编码和解码结构化数据成为可能。

图：BCH在2018年5月启用了一个新的操作码

半年后，另一个新的操作码在 2018 年 11 月的比特币现金网络升级中发布。 其中包括更新 OP_CHECKDATASIG，它允许用户验证比特币脚本中任何消息的签名。 如果我们结合 2018 年引入的脚本更新，这些更新可用于为比特币现金引入新的和有用的智能合约功能。

编写智能合约

相对于原始的比特币脚本，比特币现金的新功能为其智能合约增加了许多额外的复杂性。 这使得拥有一个通过高级语言、SDK 和工具提供更高级别抽象层的生态系统变得更加重要。

目前正在研究这个问题的两个大项目是 Spedn（由笔名 Tendo Pein 创建）和 CashScript（由本文作者 Rosco Kalis 创建，灵感来自以太坊的 Solidity 语言）。 尽管它们仍在积极开发中，但这些工具可以更轻松地使用比特币现金中的智能合约。 下面使用 CashScript 代码片段说明了一些功能。

神谕

当过去的比特币脚本更新汇集在一起​​时，它们允许您通过可信的预言机将外部数据带入比特币现金的智能合约。 结构化数据可以编码为字节数组并由 oracle 提供商签名。 然后智能合约可以验证签名并解码结构化数据。

可以在下面的 HODLVault 示例合约中查看这方面的示例。 该合约强制执行 HODLing，直到达到某个 BCH/USD 价格。 所需的 BCH/USD 喂价由预言机提供商发布，并由用户传递到合约中。 为了增加去中心化，可以将智能合约设置为使用多个数据源，而不是信任单个集中式服务。

担保合同（Covenants）

第二个大用例是一项名为“盟约”的技术，它的名字来源于财产法中用来限制物品使用的术语。 就比特币现金而言，它限制了该货币在智能合约中的使用。 因此，虽然比特币中的智能合约只能授权一般的货币支出，但比特币现金合约能够对可支出的金额或接收者的身份施加限制。

转移比特币时，发送者必须提供签名以授权交易。 为了生成此签名，发送方签署交易的哈希表示。 此哈希称为 Sighash，实际交易数据包含在 Sighash 原像中。

通过使用具有相同签名的 _OP_CHECKSIG_ 和 _OP_CHECKDATASIG_，我们可以访问 Sighash 数据。 数据格式可以在规范中检查并包含在下图中。 一个重要的字段是 scriptCode，它包含智能合约本身的字节码。 另一个是 hashOutputs，它允许用户强制执行交易输出。

图：比特币现金Sighash数据格式

很高兴知道保证合同在技术层面上是如何工作的，但 CashScript 已经抽象掉了与合同相关的大部分复杂性。 使用 CashScript 编写智能合约时，这些字段很容易获得，无需手动验证和解码 Sighash 原件。

第一个使用保证合约技术的智能合约是 Licho 的 Last Will，这是一个允许用户将死者的遗产转移到自己的智能合约。 合约定义了三种不同的功能。 第一个允许继任者在 180 天后领取资金。 第二个允许以任何方式使用所有者的冷密钥（ColdKey）。 第三种允许所有者的热键通过强制将整个合约余额发送回合约来刷新 180 天的期限。

下面包含 Last Will 的 CashScript 版本，但原始版本是由 Spedn 编写的，可以在此处查看。

这是有用的保证合同的简单示例之一，但保证合同可以实现更复杂的功能。 在签署 Last Will 合同后，其创建者 Karol Trzeszczkowski 继续创建 Mecenas，这是一家在 Patreon 等网站上强制执行定期付款的公司。

保证合约最初是在一篇名为“比特币契约”的论文中提出的，它需要一个新的操作码 _OP_CHECKOUTPUTVERIFY_。 接下来是其他建议，例如 _OP_CHECKTEMPLATEVERIFY_ 或 _OP_CHECKSIGFROMSTACK_。 后者与比特币现金的契约实施非常相似。 有关担保合同的更多信息，请参阅 Tendo Pein 的文章。

模拟状态

查看“Last Will”合同，在合同到位时更换继任者可能很有价值。 由于我们可以通过查看当前合约的字节码来强制发送到当前合约，因此我们可以通过稍微更改此字节码来强制发送到稍微不同的合约。 可以创建一个函数，将整个合约的余额发送到具有完全相同的字节码但继承人不同的合约。

我们只能使用已知大小（例如 20 字节）的构造函数参数来执行此操作。 构造函数参数始终是合约字节码的第一个数据，这就是我们如何轻松地将旧数据替换为新数据的方式。 继承者是第一个构造函数参数，其大小为 20 个字节，因此我们可以应用该技术，如下所示。

通过使用这种技术，可以在保留合同相同规则的同时更改合同中的某些变量。 我们称它为“模拟状态”，因为它提供了合约状态的一些好处，而没有像以太坊这样的有状态系统的可扩展性问题。 这种方法还有其他缺点，因为必须在某处进行权衡。

主要问题是我们实际上并没有改变原始合约中的任何变量，因为由于比特币现金的无状态性质，这是不可能的。 相反，创建一个新合约（使用新地址），并将全部余额转移到该新合约中。 由于新地址，这会导致用户体验问题，但可以通过对这些智能合约进行良好的应用层抽象来缓解这些问题。

在字节码中替换这些变量会让人觉得很麻烦，尤其是在尝试替换字节码中更深的变量时。 这个功能应该用高级语言抽象，以便通过提供新参数自动生成新的字节码。 这个抽象可能看起来像这样：

许多抽象是以更大的合同为代价的，从而导致更高的费用。 但比特币现金的交易费用普遍较低，因此它是两全其美的。 但比特币现金与比特币具有相同的大小限制，因此这些抽象确实让其更难保持在限制范围内。 这导致许多开发人员不得不手动优化编译后的字节码。

综上所述

每种加密货币都在其智能合约系统中发挥作用。 以太坊是最常用的智能合约平台，具有最广泛的功能。 比特币通过其无状态脚本系统提供了更基本的智能合约版本，验证效率更高但功能更差。 比特币现金与比特币具有相同的基础，但增加了新功能，试图在高效验证和有用的智能合约之间取得妥协。 最后，所有人都朝着相似的目标前进。

展望未来

本文写于 2019 年第四季度，反映了平台的当前状态。 加密货币是一个快节奏的领域，因此参与这些平台的人一直在努力进行改进，以改变生态系统的格局。

以太坊正在开发主要的以太坊 2.0 版本，其第 0 阶段计划于 2020 年第一季度上线。以太坊 2.0 旨在通过转向权益证明、实施分片、和其他改进。 ETH2.0 的完整路线图尚未确定，可能需要数年时间才能推出。 但是，如果这次重大更新实现其目标，它可以为以太坊提供强大的支持。

比特币中的智能合约研究致力于进一步提高智能合约的效率和隐私，这包括 Taproot 和无脚本脚本等解决方案。 比特币现金继续致力于实现额外的智能合约功能，并使这些变化更容易获得。