深度文章：如何在BCH上实现ETH风格的智能合约？

微博：BCH爱好者BruceLee

顺序

众所周知比特币宣布破产fix，由于 BCH 脚本的限制（其他 Bitbit 分支也是如此），开发者只能在 BCH 主链上实现无状态智能合约，这限制了 BCH 智能合约的功能。 但最近，BCH 的高级开发人员 Chris Pacia 发现 BCH 可以像 ETH 一样升级为实现有状态的智能合约。

------以下为译文-----

Malfix是一项涉及共识变更的BCH提案，旨在解决交易延展性BUG。 这是一个相当有争议的提议，部分原因是这将是 BCH 最重要的硬分叉变化，但也因为许多人认为这是不必要的。 在这篇文章中，我将介绍一个我们以前从未考虑过的Malfix的用例——赋予BCH以太坊式完整的智能合约编程能力。

乍一看，这似乎有点疯狂。 修复交易延展性的提案如何使 BCH 成为以太坊的竞争对手？ 让我们深入挖掘。

以太坊 (ETH)

ETH 的核心功能是允许用户在链上创建合约。 通过这些合约，用户可以保存数据。 合约定义了很多功能，当用户通过新的交易连接到合约时，用户可以读取数据，以某种方式操作它，并将其保存到合约中。

这是在区块链上存储数据的核心功能（我们现在开始称它为“状态”），而比特币一直缺乏这种读写合约数据的能力。 在比特币中，我们有一种脚本语言，但它只允许我们在从地址释放硬币时设置一些条件。 大多数人会告诉您，这些脚本无法将状态保存到区块链，并且脚本无法像 ETH 那样从任何其他交易中读取状态。

或许，他们真的可以？

OP_CHECKDATASIG

2018 年 11 月，BCH 添加了一个操作码 OP_CHECKDATASIG。 当时，BSV 的粉丝们极力阻止将这个操作码添加到协议中，但最终都以失败告终。

这个操作码看起来很基础，它所能做的就是接受任意签名、公钥和消息，并验证签名。

OP_CHECKDATASIG

这种类型的功能对于加密货币非常重要，以至于它最初没有包含在比特币中是相当令人惊讶的。

虽然这个操作码可能看起来相当缺乏想象力，但它实际上非常有用，而且我们每天都在从中学习越来越多的功能。

合同

OP_CHECKDATASIG 启用的第一个主要功能是称为合同的东西。 在OP_CHECKDATASIG出现之前，比特币脚本只能在放币时设置一些条件，仅此而已。 例如，脚本可以说“如果 A 向该脚本提供有效输入，他可以解锁并在该地址花费硬币。但是一旦解锁硬币，他就可以将硬币发送到任何地址。”

合约可以限制A只能将币发送到某个地址。 OP_CHECKDATASIG 是如何实现这个限制的？考虑下面的脚本

OP_CHECKSIG

这是典型比特币交易的花费脚本。 OP_CHECKSIG 操作码对交易数据进行哈希处理，并检查签名对于给定的公钥和交易哈希是否有效。

现在假设我们使用与上面完全相同的签名和公钥，如果通过 OP_CHECKDATASIG 操作码进行散列和检查。

OP_CHECKDATASIG

如果消息（message）与本次交易的原始交易数据一致，则脚本运行的结果为真（true）。 由于OP_CHECKDATASIG会对这条消息进行哈希处理，并根据公钥和哈希值进行签名验证，如果同一个签名和公钥都通过了OP_CHECKSIG和OP_CHECKDATASIG的校验，那么我们就知道留在栈中的消息一定是原始消息本次交易的数据。

它非常聪明。 我们现在可以访问原始数据并可以使用脚本来解析它，确保交易中的输出将硬币发送到我们希望它们发送到的地址。 换句话说，我们可以使用脚本语言来限制交易只能将硬币发送到特定地址。

那么我们可以用它做什么呢？ 我们可以做很多有趣的事情。 比如一个叫last的智能合约会实现dead man switch（注：dead manswitch，不知道怎么翻译），使用热私钥和冷私钥，使得盗币变得异常困难。

我们还可以创建经常性交易。 请注意，比特币脚本本身不能循环，它就是这样设计的。 但是我们可以在脚本上放置一个合约，强制硬币返回到它发送的地址。 基本上，一旦硬币到达那个地址，它就永远在那里，没有办法把它取出来。 我将这种脚本称为“循环”，因为每次有人从这个地址消费时，都会再次执行相同的脚本。 只要有人愿意发送交易（当然，这需要支付交易费用），这个脚本就会继续运行。

但这似乎没有用，我们为什么要这样做？

创建 ETH 风格的智能合约

一旦原始交易数据在堆栈上，我们就可以做更多的事情。 我们可以将之前的交易压入栈中，通过对之前的交易进行哈希处理，与当前交易的输出哈希值进行比较，来验证这是否是之前的交易。

但是等等，还有更多！

通常，当脚本执行作为脚本本身的一部分计算的任何数据时，所有意图和目的都会丢失。 计算结果（如果有的话）不会保存在区块链的任何地方，当然也不能被其他交易访问。 但是，使用合约，我们可以将计算结果存储在交易的 OP_RETURN 输出中。 这需要资金的花费者在他的本地计算机上运行大部分脚本来确定计算。 计算完成后，合约会将结果保存在OP_RETURN中。

现在注意我们有什么？ 这个脚本运行并完成了很多计算，计算结果保存在交易中比特币宣布破产fix，交易数据可以被下一次交易访问。 换句话说，现在 Bitcoin Script 可以将状态保存在区块链中，以便以后的交易可以读取此状态，执行一些计算并以某种方式更改它，并将其保存到区块链上级。 基本上，我们在BCH上实现了ETH的功能！

比特币命名系统

这只是一个例子。 ETH 上有一个叫做 ENS 的东西——以太坊命名系统（Ethereum Naming System）。 这是一个智能合约，允许人们在链上注册一个名称（或域名）并将其映射到特定数据，例如 IP 地址或 ETH 钱包地址。

利用上面的方案，我设计了一个叫做BNS（Bitcoin Naming System）的智能合约，它基本上和ENS做了一样的事情，就是上面说的任何人都可以消费的循环合约。 当有人想要注册一个名字时，他们将当前交易、之前的交易、要注册的名字和一个 merklix 排除证明压入堆栈。 合约会从之前的交易中加载合约状态树的根哈希，验证之前声明的merklix根的排除证明，证明之前没有人注册过那个名字，然后更新根哈希并将新状态保存在交易。 就像以太坊上的 ENS 智能合约一样，BNS 管理一个名称状态数据库并防止重复注册。 名称可以转换为 SLP 代币并用于交易。

快完成了

在遇到大问题之前，我们已经使用这种方法完成了 99%。 入栈时，BCH的共识规则要求数据大小必须小于520字节。 当您将最后一笔交易入栈时，如果数据大于 520 字节，交易将失败。

可以想象，单笔交易的交易量可以低于 520 字节，但这个交易量会随着新的交易不断增长。 看看这个：

事务 B 将之前的事务 A 压入堆栈。

事务 C 将包含事务 A 的事务 B 压入堆栈。

事务 D 将包含事务 A 和 B 的事务 C 压入堆栈。

. . .

经过 1、2 笔交易，我们超过了 520 字节的限制。 我们已经非常接近 ETH 风格的智能合约，但由于空间不足，我们失败了。

恶意软件

Malfix 引入了新的交易版本 V3。 这个版本的交易有两个交易 ID。 一种是常见的知名TXID； 另一个是UTXID，是去掉输入脚本的交易哈希值。 在大多数地方，您可以像往常一样使用 TXID。 唯一的区别是，当导入交易输出之前输入的 V3 版本交易时，您应该改用 UTXID。

这样做的效果是，当我们将之前的交易入栈时，我们不需要将输入脚本入栈。 这将使我们的数据永远保持在 520 字节以下（它们不会像以前那样随着每次交易而增长）

这个相对较小的变化就是我们所需要的。

马尔菲克斯的问题

从全节点的角度来看，Malfix实现起来还是比较简单的。 它的主要问题是，与BCH之前的硬分叉升级不同，这次升级相当激进。 所有钱包都需要升级才能处理 V3 交易。

如果未升级的钱包收到 V3 交易，则无法使用其中的币。

我们可以通过增加比特币现金地址格式中的版本字节（或保留位）来缓解这种情况。

升级后的钱包可以编程为： 向旧版本字节发送硬币时只构建 V1 或 V2 版本交易（可选）； 将硬币发送到新版本字节时使用 V3 版本交易。 这主要是为了防止未升级的钱包接收 V3 交易，并允许它们按照自己的节奏进行升级。

可能还有其他类型的服务会被 Malfix 中断，我们将不得不长期认真地考虑可能是哪些服务以及如何简化升级。

与以太坊的比较

那么这是不是意味着BCH具备了ETH的所有功能呢？ 不完全是。 请记住，ETH 是从头开始设计的，以这种方式运行。 比特币在设计时显然没有考虑到这种功能，我们只能用更聪明的方式来突破比特币的天然局限性。 我觉得像ETH这样的智能合约总是比较容易开发的，虽然像Spden这样的高级语言也能在一定程度上帮助BCH开发者体验智能合约。

BCH 保存状态的方式也不同于 ETH。 在ETH中，只要你愿意支付gas，你就可以在合约中保存任何类型的数据。

在BCH中，我们最多只能在op_return中保存220字节的数据，只够保存一些哈希值。 这意味着我们的状态需要是数据树的根，而不是数据本身，就像前面的 BNS（比特币命名系统）示例中那样。 使用合约的人将自己负责存储实际数据（尽管可以通过扫描合约的所有交易来重建状态）

最后，ETH 上的合约可以对其他 ETH 合约进行函数调用。 我不确定这在 BCH 上是否可行，因为我还没有深入考虑过。

如果 Malfix 提案最终能够通过，那么在 BCH 上创建 ETH 风格的智能合约是可行的。 我们可能无法实现 ETH 的所有功能，但这仍然是脚本语言的大规模升级。

原作者：Chris Pacia（BCHD全节点开发者）

原文链接：

------翻译结束-----

结论

我怀着无比激动的心情读了这篇文章，前后看了很多遍。 我觉得国内的BCH社区非常有必要了解这项革命性的技术，所以花了几个小时翻译了这篇文章。 文中难免有错误和疏漏之处，敬请谅解。

智能合约的重要性不言而喻。 像BitJesus前几天上线的OTC平台，其核心功能是使用OP_CHECKDATASIG操作码构建的智能合约。

如果Malfix的提案真的落地，BCH可以做很多事情。 按照我的理解，在BCH上实现这种ETH风格的智能合约，不会像现在的ETH那样出现性能瓶颈。 而且这是BCH主链上的智能合约，所以这些合约可以支持零确认交易，届时BCH将变得极具竞争力。 画面太美了，简直不敢想象。 希望 11 月的升级能够通过该提案。