与BitVM有关的重要信息
最后更新于
这有帮助吗？
最后更新于
这有帮助吗？
惧怕巫师。不是那些巫师，而是真正的巫师。
ZeroSync 的开发者 Robin Linus 今天宣布， BitVM是一项为比特币应用程序开发打开非常有趣的大门的提案，该协会成立的目的是通过使用零知识证明来帮助扩展比特币。它几乎可以实现任何任意计算，并使用该计算来强制执行链上比特币发生的情况。
它根本不需要对比特币进行共识改变。诀窍是将所有逻辑提升到链外，并且如果另一方声称结果不诚实，则能够挑战链上计算的几个步骤。简而言之，今天，BitVM 将以可执行的方式为比特币本身带来任意图灵完备计算。
为了真正掌握该提案背后的机制，我们需要了解一些计算的物理和逻辑基础。
每个人都知道，在底层，你的计算机只是传递各个 1 和 0 来完成它所做的一切，但它是如何工作的呢？这是什么意思？计算机中的每个芯片的核心都是由数百万或数十亿个称为逻辑门的个体组成。
这些小设备采用一个或两个“位”信息（1 或 0），并对它们执行简单的逻辑运算以产生 1 或 0 作为输出，然后将其馈送到下一个逻辑门。
有许多不同类型的逻辑门，有些只接受一位并输出相同的数字（缓冲门）。其他的则采用单个位并输出与其接收到的相反值（非门或反相器）。有些采用两位，如果两个输入位均为 1，则输出 1，而任何其他组合则输出 0（与门）。最后，至少今天在这个示例列表中，有一个门，它采用两个位，如果两个输入都是 1，则输出 0，而对于所有其他位组合，则输出 1（与非门）。
与非门的有趣之处在于，您可以仅从与非门构建任何其他类型的逻辑门。它肯定不会像只制作另一扇门的特殊用途版本那么有效，但它会完成工作。因此，既然您可以用 NAND 门构建任何逻辑门，那么您就可以用 NAND 门构建用于任意计算的电路。
现在如何使用现有的比特币脚本构建 NAND 门？哈希锁和您可能不熟悉的其他两个操作码：OP_BOOLAND 和 OP_NOT。
首先，让我们看一下哈希锁。您创建一个分支脚本，可以使用以下两种方式之一：向哈希锁 A 显示原像，或向哈希锁 B 显示原像。路径 A 将数字 1 放入堆栈，路径 B 将数字 0 放入堆栈。
这允许您通过向散列锁提供原像来“解锁”一个位，以用作我们正在构建的 NAND 门的输入。您只能使用其中之一来完成脚本，而不能同时使用两者，我们很快就会对此进行探讨。这个简单的原语只是允许用户一次提交单个位以在 NAND 门脚本中使用。
现在回想一下什么是与非门，它需要两位并输出一位。如果输入位均为 1，则输出必须为零。如果输入位是任何其他组合，则输出为 1。您可以使用上面的双路径哈希锁技巧来提交两个输入以及输出，您只需要一种方法来验证输出是否正确。这就是 OP_BOOLAND 和 OP_NOT 发挥作用的地方。
在选择了要指定为输入的值以及要验证的输出值后，您可以利用一个巧妙的技巧。OP_BOOLAND 的作用与 NAND 完全相反，如果两个输入均为 1，则输出为 1。其他所有值都输出 0。OP_NOT 接受输入的任何值并将其反转，1 变为 0，反之亦然。这允许您获取两个输入值并在脚本堆栈上实际对它们执行 NAND 操作。然后，您可以使用 OP_EQUALVERIFY 对照哈希锁技巧提交的断言输出来验证其输出。如果在堆栈上创建的实际 NAND 操作输出与用户声称它将产生的输出不匹配，则脚本将不会通过评估。
现在，您已经在比特币脚本中实现了一个 NAND 门，实际上可以通过比特币脚本强制虚拟 NAND 门正确运行。
那么现在你可以做什么，你可以在比特币脚本中制作单个 NAND 门呢？您可以创建一个完整的 Tapleaf 树，涵盖任何任意计算的每一步，就像制造计算机处理器的实际逻辑门一样。
为了完成复杂的计算，人们将逻辑门串联在一起，这样一旦将初始输入输入第一个门，每个门的输出就会直接输入另一个门作为输入。通过在门之间适当地将哈希锁绑定在一起，可以完成同样的事情。即，如果一个门脚本可以在值 C1 或 C2 的原像之间进行选择作为输出，则该系列中的下一个门在匹配输入中使用那些相同的散列锁值。这样，某人对前一个门的结果撒谎的唯一方法就是揭露另一个 C 哈希锁。我们可以将其用于惩罚机制。
两个用户都可以进行他们想要进行的任何计算，并将其分解为仅由 NAND 门组成的电路，逐个门进行计算。然后，他们对电路中的每个单独的门进行编码，并为每个电路步骤选择适当的哈希锁选择，并将其编码成单个 UTXO 可以锁定的 Tapleaf 树。该树有一种版本供用户尝试证明他们正在正确执行程序，另一种版本供人员验证程序是否正确执行。现在他们所做的是预先签署一系列可以在链上执行的挑战和响应游戏的交易。理想情况下，整个计算是在链下运行和验证的，用户根据计算结果将资金一起花给适当的人来合作解决。然而，如果证明者停止合作，验证者可以在链上挑战他们。
第一步是将资金注入该计划。一个脚本路径将让证明者在时间锁定后单方面索取资金。如果验证者能够显示当前门的任何输入或输出的可能值的原像，则下一个脚本路径将让验证者立即领取资金。下一个脚本路径将允许验证者强制证明者在链上执行任何特定的门合约（即在他们停止与链下合作后立即执行的合约）。这条路径要求验证者释放另一个只有他们拥有的哈希锁原像，作为对证明者的每个门挑战的锁。这保证了证明者只能执行该特定的门。验证者针对该路径的预签名交易会将其花费到具有以下脚本路径的脚本：验证者在时间锁后获取代币，或者证明者执行门并将代币花回脚本中，如第一个脚本，即证明者可以在时间锁后领取这笔钱，如果向任何单个哈希锁对显示两个原像，验证者可以立即领取这笔钱，或者验证者可以再次挑战证明者。
该方案只需进行几轮即可保证合约正确结算。要么验证者用完预签名的交易来继续挑战证明者，因为证明者不断证明每个门的正确执行，并且证明者声称该资金；或者，证明者不回应挑战，因为这会让他们受到惩罚，并且验证者在时间锁定后领取资金；或者证明者实际上确实在链上错误地执行了门，并且验证者立即索取资金。理想情况下，一切都发生在链下并通过合作解决，但如果合作失败，在链上经过几轮之后，除了正确解决合约之外，实际上没有其他结果。
当然，如此规模的提案将在未来几周内进行讨论。
需要处理和生成的数据量是巨大的。我们谈论的是带有数十亿叶子的taptree，以及与它们一起至少有几个跳跃长度的预签名交易，以确保准确的结算。
链下数据管理成本绝对是巨大的。
另一个很大的限制是该方案只能与两方合作，一方扮演证明正确执行的角色，另一方扮演验证执行的角色。
虽然未来的研究有可能找到一种方法将这一点推广到更多的参与者，但我至少没有看到实现这一目标的明确途径。此外，即使解决这个特定问题，我也看不出有什么办法可以解决这个问题：这是一个交互式协议，需要合作案例中所有参与者始终参与。
尽管如此，这是一个非常有趣的演示，展示了如何使用复杂的程序来对比特币实施条件控制。在可以将多少逻辑打包到单个叶脚本中，或者使用不同的操作码可以做什么以使整个方案更加高效方面，肯定存在优化的空间。对基本操作和博弈论平衡的简单解构可以使用比特币强制执行任意计算。
真正是奇才的创造。
