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

微博：BCH 爱好者 BruceLee

顺序

众所周知，由于BCH脚本的限制（其他太比特分支也一样），开发者只能在BCH主链上实现无状态智能合约，这使得BCH智能合约能做的事情非常有限。但最近，BCH 高级开发人员 Chris Pacia 发现 BCH 可以升级以实现有状态的智能合约，就像 ETH 一样。

------以下是翻译-----

Malfix 是一个涉及共识变更的 BCH 提案，旨在解决交易延展性问题。这是一个颇具争议的提议，部分原因是这将是 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的智能合约会使用冷热私钥实现一个死人开关（注意：死人开关，我不知道如何正确翻译），使得盗币变得非常困难。

我们还可以创建定期交易。请注意，比特币脚本本身不能循环，它就是这样设计的。但是我们可以在脚本上放置一个合约，强制硬币回到它发送的地址。基本上，一旦硬币进入该地址，它就会永远存在并且无法取出。我将这种脚本称为“循环”，因为每次有人从这个地址开始消费时，都会再次执行相同的脚本。只要有人愿意发送交易（当然，这需要付费），这个脚本就会继续运行。

但是好像没什么用如何查看币的合约地址，我们为什么要这么做？

创建 ETH 风格的智能合约

一旦我们在堆栈上拥有原始交易数据，我们就可以做更多事情。我们可以将之前的交易压入栈中，通过对之前的交易进行hash并比较当前交易输出的hash，我们可以验证这是之前的交易。

但等等，还有更多！

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

现在请注意我们有什么？这个脚本运行并做了一堆计算，结果存储在事务中，下一个事务可以访问事务数据。换句话说，现在比特币脚本可以将状态保存在区块链中，以便以后的交易可以读取该状态，执行一些计算并以某种方式对其进行更改，并将其保存到区块链上级。基本上，我们在 BCH 上实现了 ETH 的功能！

比特币命名系统

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

使用上述方案，我设计了一个名为 BNS（比特币命名系统）的智能合约，它与 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 的问题

从全节点的角度来看，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 主链上的智能合约，所以这些合约可以支持 0 确认交易，BCH 将变得极具竞争力。画面太美了，我想都不敢想。希望 11 月的升级能够通过这个提议。返回搜狐，查看更多