Skip to content

Latest commit

 

History

History
210 lines (168 loc) · 16.6 KB

BitVM 2:比特币的无许可验证.md

File metadata and controls

210 lines (168 loc) · 16.6 KB

BitVM 2:比特币的无许可验证

原始的 BitVM 设计仅限于两方参与的场景。后续的研究通过并行和冗余实例引入了基于 "1-of-n 诚实性假设" 的多方配置。这类合约的一个主要限制是所有验证者都必须在编译时预先定义。此外，随着验证者数量的增加，设置成本也随之上升。这意味着要破坏合约，总是存在一个有限数量的参与方可以被贿赂。

BitVM 2 是一种新颖的变体，在该系统中任何人都可以充当验证者。尽管仍需要基于“n方中至少有一方诚实”的假设进行一次性设置，但在运行时，任何人都可以对无效的声明提出质疑，而无需成为初始 n 方组的一部分。这克服了先前方案的局限性，并改进了其信任假设。此外，它简化了整体设计，将最长验证过程缩短为两轮。

跨链桥仍然额外需要一些预定义的m个Operators集合，并且其中至少有一个必须保持诚实。然而，即使所Operators都不诚实，他们也不能窃取任何押金，最坏的情况下只能销毁这些存款。

最坏的情况：这里应该是所有Operators都丧失活性不工作，导致多签中的资产无法取出。

BitVM2相比较与BitVM改进：

  1. 将两方参与改为了1-n方参与，任何人都可以作为验证者对无效的声明发起挑战
  2. 将挑战的轮数由大约50轮缩短到了1轮
  3. BitVM2中不是基于哈希时间锁而是将资产直接转移到多签地址中

缺点：

  1. 引入了初始化的信任假设
  2. 如果Operators丧失活性而导致资产无法取出

引言

对于给定的程序 f，我们希望验证在某些输入x和输出y的情况下，断言 f(x) = y 成立。例如， f可以是一个 SNARK 验证器，像 Groth16 证明系统中的验证器一样。此时， x是一个证明， y 是某个输出状态，而 SNARK 用于证明该输出状态的有效性。

对于 SNARK 验证器，程序规模过大，无法在单个比特币脚本中表示。例如，若实现一个 Groth16 验证器，脚本可能会达到 20MB。然而，比特币脚本的最大大小限制是 4MB，即比特币区块的大小。即使能将Groth16验证器的脚本缩小到4MB，这个规模在实际应用中显得过于庞大且不切实际。

原生解决方案

Lamport签名 提供了一种将程序 f(x) = y 分解为多个步骤的方法。对于 n = 42 步的情况：

  • 每一步都可以通过使用单个签名进行验证。这意味着整个计算过程可以被分解成 42 个独立的计算步骤，而不是在一次执行中完成。
  • 每个步骤的结果都会通过签名确保其正确性，下一步的输入依赖于上一步的输出，从而形成链式验证。
  • 这种方法不仅能够减少一次性计算的复杂性，还能在比特币的限制内执行更大的程序，同时保证每个步骤的安全性和正确性。

这样，尽管程序规模庞大，使用分步验证可以适应比特币的脚本大小限制。

f1(x)  = z1
f2(z1) = z2
f3(z2) = z3
...
f42(z41) = z42
f43(z42) = y

通过使用 Lamport 签名，可以将程序 f 的计算分散到一系列的 43 笔交易中，分布在多个区块中执行。每笔交易的输入状态是前一笔交易的输出状态，形成一个链式的计算过程。如果证明者在任何步骤中对某个中间状态 zi 进行欺骗（即提供冲突的状态），任何人都可以使用冲突的 Lamport 签名作为欺诈证明。

Lamport 签名是一种基于哈希函数的单次使用签名方案，由计算机科学家 Leslie Lamport 在 1979 年提出。它被设计为一种抗量子计算攻击的数字签名方案，意味着即使在未来量子计算机能够破解当前常用的公钥加密算法（如 RSA 和 ECC），Lamport 签名依然是安全的。

原理概述

Lamport 签名利用单向哈希函数（如 SHA-256）来生成一组密钥对。它通过生成多个不同的密钥来保证签名的唯一性，每次签名只能使用一次。

步骤

  1. 密钥生成：
    • 生成一个由两部分组成的私钥：对于每一个消息位（假设消息为二进制表示），生成两组随机数，分别作为0和1的密钥（即每一位有两个可能的密钥）。
    • 对每个私钥进行哈希运算，生成公钥。
  2. 签名过程：
    • 要对消息进行签名时，将消息转换为二进制。
    • 根据消息的每一位是0还是1，选择相应的私钥部分并暴露出来，作为该位的签名。
  3. 验证过程：
    • 验证者使用暴露出来的签名部分，通过哈希函数得到相应的哈希值。
    • 然后将其与发布的公钥进行比较。如果全部匹配，签名即被验证为有效。

例子

假设我想要签署一个 2 位二进制消息 10，步骤如下：

  • 生成密钥：我生成4个随机数，分别为：

    • 第一位的0密钥：A0
    • 第一位的1密钥：A1
    • 第二位的0密钥：B0
    • 第二位的1密钥：B1

    我对这些密钥做哈希运算，生成公钥（假设分别是h(A0)，h(A1)，h(B0)，h(B1)）。

  • 签名：要签署消息 10，我会：

    • 选择第一位的 1 对应的密钥，暴露 A1
    • 选择第二位的 0 对应的密钥，暴露 B0

  • 验证：验证者拿到 A1 和 B0，计算它们的哈希值 h(A1) 和 h(B0)，并检查是否与公钥中的 h(A1) 和 h(B0) 匹配。如果匹配，签名就有效。

优缺点

优点：

  • 抗量子攻击：由于仅依赖于哈希函数，量子计算机无法有效破解这种签名方案。
  • 简单性：Lamport 签名方案的数学基础相对简单，安全性基于哈希函数的安全性。

缺点：

  • 一次性使用：每个密钥对只能用于签名一次，这使得在大多数实际应用中其不便于重复使用。
  • 公钥和私钥的体积较大：每个密钥对需要多组哈希值，公钥和私钥体积较大，导致存储需求增加。

尽管 Lamport 签名本身的效率较低，现代抗量子密码系统依然可以从中借鉴关键思想，并且它也是许多后续抗量子签名方案的基础。

这种方法提供了一种无需许可的方式来挑战证明者，任何人都可以在证明者作出错误计算时提出质疑。然而，该方案存在几个主要局限：

  1. 链上负担过重：由于证明者仍然需要执行整个计算过程，因此每一步的状态更新都必须记录在链上，导致大量链上数据操作。这增加了对区块链的存储和计算需求，可能会造成网络拥堵和较高的交易费用。
  2. 状态转换开销：通过 Lamport 签名 来转换状态为每一步提供安全验证，但这也引入了额外的计算和存储开销。签名生成和验证过程在每个步骤都需要执行，这进一步加大了链上的资源消耗。

平衡的解决方案

我们可以通过将一部分繁重的工作从证明者转移到验证者的欺诈证明中，显著减少链上的负担。现在，证明者只需要一次性承诺输入 x、输出 y 以及所有中间结果 z1,z2,…,z42

一次性承诺：证明者只需要在链上提交输入 x、输出 y 以及所有中间状态 z1,z2,…,z42 的承诺，而不是在每一步都提交中间状态。这将大幅减少链上的数据量。

欺诈证明：如果验证者怀疑证明者提交的承诺中存在错误，他们可以针对特定的中间状态提出欺诈证明。验证者并不需要立即重现整个计算，而是可以通过选择性挑战某个中间状态 zi 来检查其正确性。

交互式验证减少：通过这种机制，大多数情况下不需要验证整个计算的所有步骤。只有在验证者发现不一致时，才会通过欺诈证明机制逐步展开检查，从而有效减少链上的计算和验证成本。

任何验证者都可以反驳任何错误的断言。在设置过程中，我们定义了一个包含43个脚本的单一Taptree，以反驳f1、f2、f3等计算的任何结果。任何人都可以在满足某个断言的情况下，从这些脚本中提取资金。

f_i( z_(i-1) ) == z_i

这将总的最坏情况计算简化为由验证者执行的单个步骤 f_i，这个步骤可能仍然需要一个相当庞大的脚本实现。从理论上讲，只要它适合单个块，或者更好的是400kb的标准大小，就可以了。

比特币节点广播区块的限制在400kb，因此单个脚本的需要小于400kb

在实践中，对于某个特定的 f 的实现，我们会尝试在证明者的承诺大小和验证者的脚本大小之间找到一个最佳平衡。

实际上，这使得任何人都可以在证明者做出任何错误断言时破坏其输出。否则，如果没有人反驳任何计算部分，则脚本会超时，允许诚实的证明者花费输出。这样总共最多只有两个回合。

这个机制可以作为去中心化桥接验证的基本构件。

乐观的解决方案

以下协议在提高上述设计的顺畅路径（希望是最常见的路径）的同时，引入了两个额外的交互回合，以应对最坏情况：

  1. 证明者对输出状态 y 进行承诺。
  2. 如果不正确，任何人都可以发起挑战。
  3. 证明者对中间结果 z1, z2, z42 进行承诺。
  4. 如果不正确，任何人都可以反驳断言 fi 。

去中心化跨链桥设计

限制：费用

在上述设计中，证明者可能会盗取一些费用。在这种情况下，押金仍然是安全的，但验证者失去了他们的抵押品。

攻击场景如下：

  1. 证明者是恶意的。
  2. 证明者执行的 KickOff_Tx是一个不合法的PegOut_Tx。
  3. 证明者等待挑战者执行 Challenge_TX，并支付给证明者以执行挑战。
  4. 证明者不执行挑战，而是简单地停止响应。

在这种设计中，证明者等待一个挑战者执行 Challenge_TX，即由挑战者发起挑战交易并支付证明者以执行挑战。这个机制可以鼓励公开验证，同时减少证明者的负担。

机制概述：

  1. 挑战发起：

    • 挑战者怀疑证明者提交的某些结果有误，或者希望对结果进行验证。挑战者需要发起 Challenge_TX 来启动挑战。
    • 挑战者通过 Challenge_TX 支付一定的费用（奖励）给证明者，作为证明者执行挑战的动力。这个费用可以作为挑战者发起挑战的成本，同时为证明者提供激励。

  2. 挑战执行：

    • 证明者在接收到 Challenge_TX 及相应的付款后，开始执行与挑战相关的计算。证明者需要展示正确的中间状态或者解决挑战者质疑的计算步骤。
    • 如果证明者能够证明提交的结果是正确的，则挑战者支付的费用作为奖励发放给证明者。

  3. 欺诈证明：

    • 如果证明者无法证明计算正确（例如提供的中间状态无效），则挑战者可以进一步提交欺诈证明。这通常会触发智能合约中的罚则，证明者可能会失去押金或面临其他经济惩罚。
    • 欺诈证明机制确保了即使证明者不诚实，也能通过验证者（挑战者）的质疑来维护系统的公正性。

优点：

  1. 激励机制：通过要求挑战者支付费用，确保只有在有强烈怀疑时才发起挑战，避免滥用挑战功能。同时，证明者获得执行挑战的报酬，保障了其参与的积极性。
  2. 减少链上负担：证明者不需要在每个步骤都提交证明，只有在出现挑战时才需要参与。这减少了链上的操作负担。
  3. 公平性：挑战者通过支付费用，证明者通过接受挑战并执行计算，双方都能从机制中获益。如果证明者行为不端，挑战者有权提交欺诈证明并惩罚证明者。

挑战者动机：

  • 经济动机：挑战者可能会获得系统的额外奖励或者可以获得错误证明者的押金。
  • 系统健康性：对于系统中的参与者，确保计算结果正确符合其自身利益，这激励了他们主动发起挑战。

总结：

通过让挑战者发起 Challenge_TX 并支付证明者执行挑战，系统引入了一种有效的激励机制。它确保只有当有充分理由时才进行验证，同时为证明者提供执行挑战的动力。这种机制可以平衡链上计算成本和系统的安全性，确保在不增加链上负担的前提下维护系统的公平性和正确性。

以下图的修改解决了费用问题。这需要两个额外的 n-of-n 预签名交易。

限制：诚实的操作员

该设计要求至少有一个诚实的操作员，否则资金最终会变得无法使用。在实际操作中，活性失效（即系统或协议无法正常运行）可能被恶意利用来进行勒索攻击。例如，恶意操作员可以冻结资金并提出勒索条件：“只有在你支付我 50% 的赎金后，我才会解冻你的资金。”

具体风险：

  1. 诚实操作员依赖：如果所有操作员都是不诚实的，资金将被永久冻结，任何一方都无法解锁。这为恶意操作员提供了勒索的机会。
  2. 活性失效的利用：恶意操作员可以通过拒绝继续参与协议或提交所需的状态更新，导致资金无法流动。这种情况下，用户的资金虽然没有被盗，但会陷入冻结状态，无法正常使用。
  3. 勒索模式：恶意操作员可以威胁说，除非受害者支付赎金，否则将永远保持资金冻结状态。由于系统要求至少一个操作员保持诚实和活跃，如果所有操作员联合作恶，这种攻击极具破坏性。

潜在解决方案：

  1. 超时机制：在协议中引入超时机制，如果操作员在指定时间内未能履行其职责，资金可以自动返还给用户或进入一个安全的托管地址，避免被永久冻结。这可以防止恶意操作员通过活性失效进行勒索。
  2. 自动解锁方案：设计成如果一定时间内没有诚实操作员出现，资金会自动解锁，避免恶意操作员对资金的控制权。
  3. 分布式信任模型：引入更多的去中心化机制，不依赖于少数操作员。例如，使用分布式验证者网络，确保即使部分操作员不诚实，系统仍能正常运作。
  4. 经济惩罚机制：要求操作员提供押金（质押），如果他们参与勒索攻击或导致系统活性失效，押金将被没收。这样可以增加操作员不诚实行为的成本，减少勒索攻击的动机。

总结：

活性失效问题确实为恶意操作员提供了勒索的机会。通过引入超时机制、自动解锁方案以及分布式信任模型，能够有效减少资金被冻结和勒索攻击的风险。同时，经济惩罚机制也能进一步抑制恶意操作员的行为。