作者：waxwing

来源：https://groups.google.com/g/bitcoindev/c/pjv6bL_42kg

能在派对上露一手的部分是这样的：在一条闪电通道中玩国际象棋、让赢家拿走奖金，并且是 “免信任的” 。“21 点” 也一样，作为一个隐藏信息的游戏更加有趣。至于不能拿来炫耀的应用，待会再说。

在我们解决那个带有引号的部分之前，先来讲讲主要的概念：你总是可以在比特币上玩这样的 挑战-响应 游戏，只是有一些复杂性限制；你要利用这样的想法：“要证否一些东西，可能比证明一些东西的代价要小得多”，比如，我证明棋盘上某个位置有个棋子，所以你的走法是犯规的；等等。但想在链上玩这样的游戏，走 50 步来得出结果，是根本 不实用/不吸引人/不经济的/不可扩展的。所以你肯定 想 在一条通道或类似构造中来玩。

问题在于，就像这篇文章的结论说的，“闪电通道无法裁决沉默”。所以，拖延总是会迫使游戏回到链上。对闪电通道自身（这种游戏）来说，就还好，总共只有 3 回合。因此，这里的技巧是处理沉默，并且，具体来说，仅在我们说的 “场地（venue）” 中裁决。

解决争议的基本过程是这样的：

（犯规走法或不走）-> Alice 发布交易 “声明” 并说 “Bob 在步数 d 时不走棋或者走法是犯规的” -> （可能）Bob 发布交易 “反驳” 并说 “这是我在步数 d 的走棋，而这是 venue 给出的见证”-> （可能）Alice 发布 “证否” 说 “这是你的走棋的具体属性，是犯规的” 或者 “这里是一个证据，venue 见证了你根本没有及时走棋”。

通常来说，不会需要再纠缠，但最多只需要 3 笔交易（或者说 4 笔，就看你怎么数了），就能解决，因此复杂度是 O(1) ， 跟出现争议的程序本身的复杂性无关（后文会继续说明；因为一些因素，比如堆栈的限制，如果你的做法太过直接，往往不能使这种属性成立，虽然国际象棋和类似的程序是可以的）。

（这些交易中，体积最大的可以证明是 “反驳”，但似乎也不会超过 20-40 kvB，应该是可以接受的；如上所述，堆栈限制才是先碰到的瓶颈。）

回到 “免信任的” 的说法：

有趣的是，一个 “venue” 并不非得是一个发布出版证明（proof of publication）的 账本 。也就是说，并不需要强制执行使得只有一种版本的历史（有没有发布出版证明才是关键）。它只需要说 “签过名的消息 X 则时间 T 以前没有发布过”，就可以了。来自合约参与者的签名即可解决歧义，venue 并不需要直到 X 是什么意思（类似于 “客户端验证”）。

作为一个单点故障，这样的 “venue” 算不上理想。Alice 和 Bob 缔结了合约。作为 venue 的 Vernon 跟 Bob 串谋。当 Alice 走棋的时候，Bob 就不动。Alice 发布 “他不走棋” 声明交易，然后 Bob 就在下一步交易中发布他的有效走棋作为反驳；他的走法是符合规则的，所以 Alice 既不能否决他，又 不能 说 “venue 说他没有及时走棋”，因为 Vernon 会拒绝提供见证。所以，串通可以拖延时间、逃避惩罚。

但即使在这个腐化版本中，Vernon 也不持有资金，这已经能消除一些攻击，并允许用纯粹的比特币缔结复杂的合约。而且，在时间尺度较慢的游戏中，Vernon 说话是完全可以公开证明的，这会影响他们的声誉、未来的手续费收入，甚至可以使用带有时间锁的保证金。

LN-GAP 做的事情是：venue 是一个委员会（实际上最多能多达几百个委员，但因为技术原因，无法更多了，样品使用了 5 个委员），可以从一个较大的集合中随机抽选。可以要求他们存入带有时间锁的保证金。至关重要的是，他们可以使用我称为 “EC-OTS（椭圆曲线一次性签名）” 这样的构造，通过闪电通道原子化地收取出版手续费（详见论文），所以他们是有参与的正向激励的。活性要求是 1 of N，即，只需一位委员愿意出版你的 走棋/状态更新 。但如果要见证某人没有在截止时间之前走棋，就需要满足阈值多数，而这就是解决 “拖延” 问题的机制。对于实际发布的 非法走棋/非法状态转换，我们就应用上述 “证否更简单” 原理：在一棵 tapscript 树的一个叶子中证明非法。

总之，我在论文中论证了，如何让一些公开实体（有声誉资产可以损失的参与者）（没有托管用户资金的头疼问题；他们甚至不知道合约要仲裁什么 —— 他们的律师想必会很高兴！），与匿名但存储了带有时间锁的保证金的实体组成一个委员会；后者的子集会帮助保持活性假设为真，但可能更容易被女巫攻击；前者有助于可信度，因为他们有很多声誉资产可以损失（相比可能投入较低保证金的匿名实体；虽然你 可以 主张所有实体都应该保持匿名）。

成为 venue 的一个成员是非常简单的；没有计算负担，也没有存储包袱。真正头疼的是，对活性的需求很高，对于合约参与者和 venue 成员都是如此。如果你离线太长时间，就会遭受损失。

应用：游戏很有趣，也是这种想法的显然应用，是多回合的、规则明确的交互。其它应用有：传统的 filecoin 应用，但稍加调整：服务供应商给用户提供的是这样的合约：他们证明自己会持有 1TB 文件，每天都使用某种默克尔证据方案给出一个证据，用户就来付费；调整之处在于，如果服务商某一天无法提供证据，就要放弃一大笔钱（实际上就是保险赔付，用于赔偿用户因为数据丢失而造成的损失）。这种机制是本提议独有的；无论 filecoin/sia ，还是其它的方案，都从未提出这种 “裁决沉默” 的机制来补偿受害者。

计算证据也类似于存储证据。对比一下：“混淆电路（garbled circuits）” 方案，虽然通常来说开销很大，但可以通过一段复杂的运算来实现一笔支付的一次性结算，无需 “venues” 这样的基础设施。但它们并不能解决拖延问题（当然它也从没说自己可以解决）。ZKCP（零知识的条件式支付）也有类似的情况。这里有许多细微差别，在此不表。

真正有趣的地方是我为 “任意” 一词作的辩护。使用这个词时，我们的意思是任意复杂性的任意程序。这对于一个内部状态非常大的程序来说，显然是做不到的，因为哪怕 taproot 可以通过它的 MAST 树来解析数量极其庞大的谓词，Bitcoin Script 也不支持深度超过 1000 的堆栈。

在短论文的第 7 章，它主张你可以做到跟 BitVM【1】一样多的事情；这是最初的 BitVM【2】想法的一种延伸，就是：你可以使用二分法来解决争议。BitVM 在链上工作，而且回合次数不是小数目，可能有 30 轮。如果我们在 链外 使用二分法，基本上跟上面使用 venue 的方式一样，从而在解决争议时保持 O(1) 的链上足迹（虽然公平地说，BitVM 已经做到了 O(log n)，但依然有可能太大了）。当前，代码库里只有一个概念验证案例，证明这是可行的，虽然已经接近了堆栈限制【3】。这几乎适用于 任何 guest program，所以标题才敢说 “任意程序”。

我粗略地想了想这种机制如何启用（比如说）rollup 侧链的桥接合约，我猜测在理论上是可以做到的，尽管它会颠覆我们对 “桥接” 的理解（因为钱币不会到别的地方去；需要流动性，等等）。这让我得出了最后一些评论：

这种思路有一个主要部分：“尽管一个使用固定流动性的双边合约是非常局促的，但因为是闪电通道，它在隐私性、可扩展性和速度上都有许多优势”。双边合约并非多方合约， 但不难想象可以在多个这样的合约中，使用共同的事实做一样的事情。想象，比如说，拍卖。我原本对这个想法非常感兴趣，但后来被耽搁了 : )

如论文指出的，venue 跟 DLC 断言机有类似之处（实际上，EC-OTS 观测跟 DLC 观测是非常相似的），但它是一种非常特殊的断言机：它见证的是自我认证的事实（棋手的走棋以及对应的签名）的出现时机，而不是外部世界的事件。所以，通常在 DLC 语境下会讨论到的 “断言机委员会” 在这里甚至更有意义，因为它们只负责记录事件，而且时间尺度较慢，而且只涉及客观事实。

【1】https://arxiv.org/abs/2405.06842 BitVMX-CPU

【2】观念如潮水，Arbitrum、TrueBit，甚至更早的一些学术论文都有这样的想法，我记不太清了

【3】我从论文的长版本中引用一些具体的细节：

“该程序是 BitVMX 的 Groth16 验证器，是一个基于配对的验证器的 RISC-V 编译版，用于验证一个 guest program 的一个 STARK 接收证据的 RISC0 【12】 证据的有效性。对于真实有效的证明，验证器在 478,727,216 步后成功停止。当被挑战时，BitVMX 的搜索代码需要进行 29 轮运算（在链下需运行约九分钟），这是一个深度为 119 层的合约：包括 2,058 个预签名交易、1,919 个证否叶子和 62 个证明叶子，这些叶子位于第一阶段的最终深度。该阶段的全部 59 次操作均由验证方密封，在 regtest 中争议内容包括声明（220 vB）、反驳（24.3 kvB，在一个较小规模的程序重新测量得出，其大小取决于头的数量而非程序本身）以及叫停 ecall 的证明（58.5 kvB）。链上成本不依赖于程序长度。这些叶子体积较大（一个证明叶子大约包含 228 KB 脚本，峰值栈深度为 948，而允许的最大值为 1,000），但仅取决于合约密钥，因此每份合约只构建一次，通道更新时可重复使用。再次强调栈大小才是真正的限制因素。此外，性能并不受 guest program 复杂度的影响，因为我们裁决的是 Groth16 证据本身。”