比特币软分叉：货币真的需要这些新的操作码吗？

一些开发者再次推动软分叉，但其共识程度比以前少得多。改变比特币代码并不容易。

一些开发者再次推动软分叉，但共识比以前少得多。

比特币软分叉改变比特币代码并不容易。我们被激励永远不会修改与 2100 万限制相对应的代码部分。

尽管如此，有些改进还是必要的，而另一些则不然。不幸的是，总会有开发人员想要保留他们的坏态度。

代码演变是通过“拉取请求”提出的。大多数是次要的，但有些是主要的。然后它们成为 BIP（比特币改进提案），有时是“软分叉”。

提醒一下，硬分叉是与旧代码不兼容的代码的演变。典型的例子就是BCH（比特币现金）。 BTC 网络节点不会验证 BCH 区块，因为它们可能会超过每个区块 1 MB 的限制。这样的更改会触发硬分叉。

在软分叉的情况下，两个代码共存于同一个区块链上。这称为向后兼容性。例如，我们可以将块大小更改为 0.3 MB。这小于 1 MB 限制，因此向后兼容原始协议。

最新的软分叉是 SegWit (2016) 和 Taproot (2021)。一些开发人员目前正在推动一个新的分叉，以允许通过添加新的 OP_codes 来创建“契约”。

Blockstream Research 最近发布了关于该主题的相当详细的摘要：

了解比特币交易的机制对于理解比特币交易机制至关重要什么是契约。奇迹的发生要归功于一种称为“脚本”的计算机执行语言。这是一种非常简单的语言，指令数量有限。

这些指令称为 OP_codes。将它们视为交易验证后开始运转的小数字齿轮。

具体来说，进行比特币交易意味着从一个（或多个）其他“utxo”创建一个“utxo”，而该“utxo”在此过程中被破坏。 utxo 是一段代码（脚本），它以数学方式将一定数量的比特币链接到比特币地址（公钥）。

本质上，进行交易意味着将金额更改为公钥（比特币地址）。的比特币是相连的。

在交易过程中，星号OP_code是OP_CHECKSIG。这会检查签名是否与已用 utxo 的公钥匹配。如果一切正常，则会创建一个包含接收者公钥的新 utxo。

总的来说，比特币脚本是一种相当简单的“基于堆栈”的编程语言，限制了可能性的领域。

Blockstream 对此写道：

“就目前情况而言，无法预先配置如何使用 utxo 中的比特币或使用它们的速度。唯一的解决方案是修补使用 PSBT（部分签名的比特币交易），除其他限制外，它无法正确包含交易费用。”

“脚本编程语言的简单性虽然是比特币安全模型的核心，但它引入了重要的意义。它支持最基本的智能合约的能力有限。”

更多堆栈中的算术“基于堆栈”是指交易机制所需的数据放在一个“堆栈”中，在其中进行逻辑运算。

交易验证机制的示例：

OP_code OP_DUP 将复制公共utxo 的密钥并将其放入堆栈中。

OP_code OP_HASH 将对这个密钥进行哈希处理（将其转换为比特币在 utxo 中以数学方式链接到的地址）

OP_EQUALVERIFY 验证生成的哈希确实属于有问题的 utxo。

OP_CHECKSIG 验证提供的签名是否与 utxo 的公钥匹配。

比特币脚本有不到 100 个重要的 OP_codes。但是，无法对堆栈中的数据进行乘法、除法或连接（组合）。

中本聪在 2010 年禁用了多个 OP_code（OP_OR、OP_MUL [乘]、OP_DIV [除] 和 OP_CAT [连接]）。这些 OP_code 已被删除，因为它们的原始实现存在可利用的漏洞，可能会危及网络安全。

然而，它们的缺失使得创建某些奇异的支出条件（智能合约）变得困难。值得注意的是，无法根据交易数据定义 utxo 中的支出条件。

Blockstream 解释道：

“如果脚本能够解释交易数据中的更多细节，我们就可以构建更强大的合约来允许特定支出状况。”

契约目前，比特币唯一可能的“智能合约”就是锁定和解锁与公钥关联的比特币的经典行为。本质上是进行交易。

契约旨在创建一种新型的 utxo，允许交易的发送者对接收者随后如何使用比特币施加某些条件。

这里有两个 OP_codes，分组在术语“契约”下” 能力有限

以上是比特币软分叉：货币真的需要这些新的操作码吗？的详细内容。更多信息请关注PHP中文网其他相关文章！