ZeroSync是一个通过使用零知识证明来扩展比特币的协会。近日ZeroSync开发者Robin Linus发布新的比特币提案BitVM，BitVM为未来比特币应用程序开发打开了非常有趣的大门。BitVM可以启用几乎任意的计算，并利用该计算来强制执行比特币链上的操作。

BitVM不需要对比特币进行任何共识更改。诀窍在于将所有这些逻辑移至链下，并且如果对方声称不诚实的结果，能够在链上挑战计算的一些步骤。简而言之，BitVM将以一种可执行的方式，即时地将任意的图灵完备计算引入比特币。

为了真正理解该提案背后的机制，我们需要了解一些有关计算的物理和逻辑基础知识。

每个人都知道，计算机内部只是传递各个1和0来执行所有操作，但这是如何工作的呢？这意味着什么？计算机中的每个芯片核心都由数百万或数十亿个逻辑门组成。

这些小设备接收一个或两个信息位（1或0）作为输入，并对它们执行简单的逻辑操作，以产生1或0的输出，然后将其馈送到下一个逻辑门中。

有许多不同类型的逻辑门，有些只是接收一个位并输出相同的数字（ buffer gate，缓冲门）。其他的接收一个位，并输出与接收到的相反的值（NOT门）。有些接收两个位，并且当两个输入位都是1时输出1，其他任何组合输出0（AND门）。最后，至少在下面的示例列表中，有一个门接收两个位，并在两个输入都是1时输出0，并在所有其他位组合上输出1（NAND门）。

NAND门真值表

NAND门的有趣之处在于你可以仅使用NAND门构建任何其他类型的逻辑门。它肯定不像只制作其他门的特殊版本那样高效，但它能完成任务。因此，鉴于你可以用NAND门构建任何逻辑门，你可以用NAND门构建任意计算的电路。

现在，如何使用现有的比特币脚本构建一个NAND门呢？用哈希锁和另外两个你可能不熟悉的操作码：OP_BOOLAND和OP_NOT。

首先，让我们看看哈希锁。创建一个分支脚本（branching script），可以通过两种方式之一花费，揭示哈希锁A的preimage，或者揭示哈希锁B的preimage。路径A会在堆栈上放置数字1，而路径B会放置数字0。

这使你能够通过提供哈希锁的preimage来“解锁”一个位，以用作我们正在构建的NAND门的输入。你只能使用其中之一完成脚本，而不能同时使用两者，我们很快会讨论其中的原因。这个简单的原语只是为了允许用户一次承诺使用一个位于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门的方式。

那么，既然现在可以在比特币脚本中创建一个单独的NAND门，那么可以做什么呢？你可以创建一个完整的tapleaf树，覆盖任意计算的每一步，就像实际的逻辑门为制造计算机处理器一样。

为了完成复杂的计算，人们将逻辑门连续放在一起，这样一旦将初始输入送入第一个门，每个门的输出就直接作为另一个门的输入。通过在门之间适当地绑定哈希锁，我们在这里完成了同样的事情。即，如果一个门脚本在值C1或C2的输出之间有一个选择，系列中的下一个门将在匹配的输入中使用相同的哈希锁值。这样，有人欺骗关于上一个门的结果的唯一方法是揭示另一个C哈希锁。我们可以将其用于惩罚机制。

两个用户选择他们想要参与的任何计算，并将其分解为仅使用NAND门逐个进行计算的电路。然后，他们采用并对电路中的每个单独门进行编码，每个电路步骤都有适当的哈希锁选择，并将其编码到可以锁定单个UTXO的tapleaf树中。有一个版本的树是供试图证明他们正确执行程序的用户使用的，另一个版本是供验证程序是否正确执行的人使用的。现在，他们要做的是预先签署一系列用于在链上执行的挑战和响应游戏的交易。理想情况下，整个计算在链下运行并得到验证，用户通过共同花费资金将其结算到基于计算结果的适当人员。然而，如果证明者停止合作，验证者可以在链上对其提出挑战。

第一步是将资金加载到方案中。一个脚本路径将允许证明者在时间锁定后单方面主张资金。下一个脚本路径将允许验证者在可以展示当前门的任何输入或输出的可能值的两个preimage的情况下立即索赔资金。下一个脚本路径将允许验证者强制证明者在链上执行任何特定的门合约（即在链下停止合作后的门）。该路径要求验证者发布另一个只有他们拥有的哈希锁preimage，作为对证明者每个门挑战的锁。这保证了证明者只能执行该特定的门。验证者对该路径的预签名交易将其花费到一个脚本中，该脚本具有以下脚本路径：验证者在时间锁定后取走硬币，或证明者执行门并将硬币花费回到类似于第一个的脚本，证明者在时间锁定后可以索赔资金，验证者可以立即索赔资金，如果向任何单个哈希锁对显示两个preimage，或者验证者可以再次挑战证明者。

这个方案只需进行几轮就可以保证合约正确结算。要么验证者用完预签名交易以继续挑战证明者，因为证明者一直在展示每个门的正确执行，证明者会主张这笔资金；或者，证明者不回应挑战，因为这会使他们受到惩罚，而验证者会在时间锁定后索赔资金；或者证明者在链上错误执行了一个门，验证者立即索赔资金。理想情况下，一切都在链下发生，并且通过合作解决，但是如果合作失败，那么在链上进行几轮后，除了正确结算合约之外，没有其他结果。

毫无疑问，这样的提案将在未来的几周内讨论。

需要处理和生成的数据量是巨大的。我们正在讨论叶子编号达数十亿的tapleaf树，并且至少有几跳的预签名交易以确保准确的结算。

链下数据管理成本绝对是巨大的。

另一个重要的限制是，这个方案只能与两个参与方一起使用，一个扮演证明正确执行的角色，另一个扮演验证正确执行的角色。

虽然未来的研究有可能找到将其推广到更多参与方的方法，但至少我看不到完成这一点的明确途径。而且，即使解决了这个特定的问题，我也看不到摆脱这是一种互动协议的方式，该协议要求在合作情况下所有参与方始终参与。

尽管如此，这确实是一个非常有趣的演示，展示了如何使用复杂的程序来强制对比特币进行有条件的控制。在单个叶脚本中可以打包多少逻辑，或者使用不同的操作码可以使整个方案更加高效，这方面肯定还有优化的空间。通过对基本操作和博弈理论平衡的简单拆解，可以使用比特币强制执行任意计算。

本文观点仅供参考，不构成投资建议。币圈波动大，投资需理性。

欢迎关注笔者，在留言区分享您的观点！