观点 | 关于 Fraud Proof 的沉思，Part-2

观点 | 关于 Fraud Proof 的沉思，Part-1

在我深入更多技术细节之前，为了避免有人因为听不懂而掉队，我将以故事的形式再次说明 “整个逻辑”。

3. 讲个故事

故事由“ Fred ”(全节点)，和“ Sally ”（SPV 节点）主演。 为了简化，故事聚焦于第一类缺陷和第二类缺陷。 第三类缺陷需要通过下载额外的数据来解决，第四类缺陷能够转化为第一类缺陷（见第 7 章）。

对话 I

• Fred： “这笔交易是你要找的嘛？ Wow，这笔交易记录了——转给 Sally 300 btc！ ”

• Sally： “是的，我卖给 Peter Thiel 一艘太空船，他能去木星啦。 ”

• Fred： “赞哦。 这是你需要的 Merkle Branch，还要有最近一段时间的所有区块头。 ”

• Sally： “太好了，我可以简单计算几个哈希值来检查 Merkle Branch，也能轻松确认这些区块头都满足难度要求。 赞美中本聪！ ”

• F： “中本聪牛啤 ！ ”

• S： “不过，我要怎么确定这些区块头是合法的呢？ 没准这些区块头来自恶意 or 懈怠的矿工。 Peter Todd 说过 SPV 节点很烂……。 ”

• F： “噢，那你可能会对我的一些附加服务感兴趣。 ”

• S： “说来听听？ ”

对话 II

• F： “第一项服务叫 ‘无效保险’（Invalidity Insurance），你需要支付 0.007 刀给我； 假如你通过 hashMerkleRoot 发现区块中有无效（或双花）交易，我会理赔你 1000 刀。 ”

• S： “任何区块错误都会理赔吗？ ”

• F： “没错，任何类型的无效区块都能理赔。 ”

• S： “哇，看来你非常有把握缺陷不会发生，不然你不会愿意这么做的。 ”

• F： “因为我已经用电脑检查过所有区块和其中的所有交易； 它们都是有效的。 ”

• S： “有意思！ ”

• F： “提醒一下，如果 12 小时内（72 个区块之后）你没有发现任何问题，你的保险也就到期啦。 ”

• S： “我明白了。 不过这个区块会在 10 分钟内完全传播到整个网路中的全节点对吧？ ”

• F： “对，而且你要想想，12 小时可比 10 分钟足足长了 72 倍呢。 ”

• S： “这么说也是，只要全节点有动力将 “某区块有缺陷” 的消息传出去，12 个小时肯定足够传播给所有人了。 ”

• F： “对的，激励的存在至关紧要！ ”

对话 III

• S： “等等，也许你给我的不是完整的区块？ 我听说矿工有时候会无脑出块，完全不管里头的内容是不是有效的！ 如果他们这么做会如何？ 我们又有什么方法能够检查呢？ ”

• F： “Hmmm，我这里保存的的确是完整的区块。 ”

• S： “真的吗？ ”

• F： “千真万确。 ”

• S： “你能不能提供证明？ ”

• F： “当然，实际上这是我提供的第二项服务。 ”

• S： “太棒了！ ”

• F： “首先给你这个，这是该区块的最末尾交易。 你可以相信我，因为这棵 Merkle Tree 始终向右下延伸； 如果出现了向左延伸的情况，那就说明我们给同一对象哈希了两次，也就是在默克尔树的那一层原本只有奇数个对象（为了把 Merkle Tree 的完整而补了一个对象进去）。 你可以将这个 Merkle Branch 和我前面给你的 Merkle Branch 进行对比，他们会有相同的 Merkle Root。 ”

• S： “没错！ 你给我的的确是这个 Merkle Branch （包含我的交易）中的最末尾交易。 ”

对话 IV

• F： “这棵 Merkle Tree 有 11 层，所以你知道这个区块中至多有 2^11 = 2048 笔交易。 而且你知道自己对某对象做哈希运算的次数以及时间，所以你知道 Merkle Tree 的外观。 尤其是，你知道它里面装着的东西的确切长度（大小）。 ”

• S： “Wow，原来我知道的事情比我想象得多！ 我真的知道所有内容吗？ ”

• F： “当然！ ”

• F： “Merkle Tree 中所有东西的位置必然相同，否则无法匹配——除非某人能找到一个 X ，对其进行两次哈希计算所得到的哈希值要与一笔 “真实交易” 的哈希值相同； 换句话说，“uneven Merkle Tree ” 要求创建者找到这么一个 X，使得 h(h(x)) = h(真实交易)。 但这就像要找到“哈希碰撞“（理论上行不通）——因此不可能找到 X。

有趣的是，有些内容无法既是 Sha256 又是合法的比特币交易。 比特币小白可能不知道： 最小的比特币交易大小为 60 bytes（比 32 byte 的哈希值体积要大得多）。

• S： “我明白了——当不存在重复交易的时候，Merkle Tree 在几何上就像个等腰三角形； 当最末尾交易被复制多次的时候，Merkle Tree 看起来像直角三角形。 最后一笔交易所在的深度，就是整棵 Merkle Tree 的高度，根据重复规则，我只要知道右边缘啥样，就能知道有多少底部元素（三角形最底层的元素）是重复的。 “

• F： “包含你这笔 300 btc 交易的区块，它的 Merkle Tree 深度为 11 单位——也就是三角形高度是11层。 通过我给你的最末尾交易，你知道区块只在最后进行了一次重复哈希计算。 这样一来，你就能确定这个 Merkle Tree 包含了 2047 笔交易。 “

• S： “噢，解释的好清楚。 如果今天 Merkle Tree 深度为 10 单位，所有交易（当然，第一笔交易除外）都只做了一次哈希计算，那么我就能知道这个区块有 513 笔交易！ “

• F： “没错！ “

• S： “Wow！ “

• F： “假设我现在给你新的 Merkle Tree，以及带了 Merkle Path = [A, (self), B, C, (self)] 的新的 “最末尾交易”，你能知道什么？

• S： “它有 5 层，而且共包含 23 个独立的元素。 “

• F： “完全正确！ “

• S： “我真的学到好多。 “

• F： “还有最后一件事： 每个最终的元素要么已知，要么未知； 在已知的情况下，这个元素可能是合法的交易或不是合法交易。 整理一下，区块中包含的所有元素可以分为【1】合法交易； 【2】非法交易； 【3】一条没人能看见的消息。 “

• S： “嗯，很直观！ “

对话 V

• F： “好的，现在你能看到你的区块内有 L = 2047 笔交易。 “

• S： “对！ “

• F： “现在介绍我的第二项服务： 你只需要支付 0.0001 刀—— 比刚才还少。 你可以随机从 1 到 L 中挑选一串整数  5 ，然后我会给你对应的交易和 Merkle Path 。 如果我做不到，那我会赔偿你一大笔钱。 ”

• S： “你好像很有自信呢！ “

• F： “那当然！ 你可以找你的智囊团，研究出我可能遗漏的交易。 不过我保证，你们绝对找不到。 “

• S： “好，这个服务我也要了！ “

• F： “还有件事要注意，如果我们达成协议，但你不告诉我你选的整数，别人还是会以为我没完成挑战对吧。 我的意思是，我完全有能力展示你要看的交易，但你不说要看哪个，所以我没法展示。 所以如果你没有在规定的时间内给我你的选择，我要收取全额的查询费用，甚至更多！ “

• S： “ Emmm，好吧，我想对于我这笔 300 btc 的交易，我不应该吝啬于锁定一定数额的查询费用。 “

• F： “相信我，你只需要锁定几秒钟。 换做是我也不愿意自己的钱在任何时间点，被毫无意义的锁在某个通道里。 “

• S： “ Ok！ “

• F： “好的，现在我们的支付通道处于状态 (A, B)，你需要创建状态 (C, D)，等我们迁移过去之后再告诉我你选择的整数串。 “

对话 VI

• S： “好，我已经选好了一些 Rs（随机数），也创建好了 C 和 D（支付通道的下一个状态）。 来，我将 D 签署给你，轮到你行动了。 “

• F： “谢谢！ Hmmm……看来你把所有内容都按照所需格式填写正确了。 “

• S： “给，这里是我选择的随机数……“

• F： “慢着，慢着！ 你等会儿再给我啊！ “

• S： “噢，不好意思。 “

• F： “没事。 “

• S： “还有个问题，如果我向你展示的是 Rs 的哈希值 Hs，你有什么方法确定 R 是否遵循规定呢？ 我有可能不在（1，L）的范围内选择整数，我有可能不是选择（5, 470, 4,……），而是无意义的随机字符（‘ fish ’, 0x78965, ‘_’, 987987987, ……）。 当你拿到这样的随机数，你不可能返回对应随机数 “fish” 的交易给我对吧！ ？ “

• F： “啊……这是个好问题。 事实上，有很多专业的密码学家提出很多种方法应对这个事。 我会选择其中一种方法，要求你要向我发送 “Gs” 而不是 “Rs”。 ”

• S： “好的，我已经用选择的 Rs 生成了 Gs，给！ “

• F： “嗯，从你给我的 Gs，我可以确定Hs的确是从范围（1，L）选取的整数。 因为我有所有的 L 条交易，我很自信能满足你的挑战。 ”

• S： “太棒了，那下一步呢？ ”

对话 VII

• F： “来，给，这是我签过名的 C。 我已经把 B 弃用了（根据支付通道迭代规则）。 ”

• S： “好的，不需要我也作废 A 吗？ ”

• F： “需要，但即使你不这么做，我还是能广播 D。 ”

• S： “如果我抢先把 A 广播出去呢？ ”

• F： “这就相当于这笔交易（300 btc）从没发生过……”

• S： “啊哈，我可以作弊啦！ 既然你愿意接受挑战，那你肯定知道这个区块是合法的！ ”

• F： “（摊手）啥意思？ ”

• S： “……（你要是不知道那个区块是合法的，就不会愿意接受挑战了，那么你一接受，我就已经得到了我想要的）也就是说，现在我已经得到想要的信息，而且不用支付任何费用啦！ ”

• F： “并不，虽然你知道我已经接受挑战，但你无法确定我是不是真的有能力完成这个挑战对吧。 ”

• S： “……（沉默）”

• F： “你要明白，在开始这个过程之前，我只是 接受挑战 而已。 看来你还有要学习的地方，不然我不明白你现在退出是图什么。 ”

• S： “……（沉默）”

• F： “也许我猜到你会想退出，所以事先做了份假的审核，实际上我根本不知道这个区块的有效性。 ”

• S： “……（沉默）”

• F： “对比一笔太空船的价格，万分之一刀真的是少到不能再少了。 ”

• S： “好好好，我已经作废 A 了。 ”

对话 VII

• F： “OK，你现在可以说出你的 Rs。 ”

• S： “我选择的是 453、531、14，和 2011。 ”

• F： “选的好！ 这里是你要的交易 #453、#531、#14，和 #2011； 还有它们对应的Merkle Branch。 你可以看到，我的确有该区块的完整交易。 ”

• S： “太酷啦！ 我爱错误性证明。 ”

我在介绍无效保障（Invalidity Insurance）和完整性审核（Fullness Audits）之前，我想先回顾一下支付通道和闪电网络。

4. 支付通道概述

A. 常规（无通道）支付

常规（无通道）支付的含义是，表示资金转移的 “消息” 会在网络中传播，一旦消息被记录到区块链上，资金转移即告完成。

就像现在朋友 A 发了封邮件，告诉你 “我的 12 个 btc 有 4 个是你的了”，然后你点击 “回复所有人”，声明 “我的 4 个 btc 中有 2.7 个是老 Q 的了”。 一旦这些 “邮件” 的副本进入了区块链，这些邮件对应的交易就被认为已经发生了。

B. 支付通道

要使用支付通道，收付双方首先要使用自己的 btc ——把钱 “存入”（或者说 “创建”、“开启”）一个通道，然后再付还给自己。 例： 我拿出 90 btc 然后付还给自己，你拿出 15 btc 然后付还给自己，这些操作合并为一笔交易，就像其他普通交易一样广播出去。

不过，虽然开启通道的操作是类似的，参与者在通道中的收付行为可能有所不同。

沿用上面的类比： 所谓的支付通道模式就是，在我们发送 “电子邮件” 之前，我们保留了多个未发送的 “邮件草稿”。 对于同一份草稿，始终存在两个并行的版本——我手上会有一份对你更有利的版本，而你手上也会有对我更有利的一个版本——你已经对我手上的那份草稿签过名，我自己还没签名； 反之亦然，你手上的那份草稿我已经签名了，但你自己还没这么做（签名）。

C. 更新支付通道

支付通道参与者将共同通过切换状态（我称之为 “势能（potential）” 状态和 “动能（kinetic）” 状态）来循环更新平行的草稿对。

通道大部分时间处于静止、无变化的 “势能” 状态。 一旦有人要启更新这个通道，状态会切换成 “动能” 状态，然后再快速切换回“势能”状态。

上图： “动能” 状态——2 btc（粉色，双框）正等待被触发，但实际上这个过程非常短暂。 通道大部分时间处于“势能”状态，反映了各方最新的 btc 余额是多少。

如我前面提到的，如果 “区块链” 记录了这些“邮件”的副本，那这些交易就已经发生了。

但支付通道不一样——当双方共同从一对草稿 “转移” 到新的草稿，这笔交易就被认为是发生。 而且，“转移” 过程本身也大不相同——并不是说我们一起创建、签名、交换了新草稿的数据就算完成了 “转移”； 我们还必须采取额外的步骤来创建、签名和交换 ”表明弃用旧草稿对的信息“。 只有到那时候，付款才算真正“发生”。

D. 哈希锁定合约/闪电网络

我们一般说的 “动能” 状态，也称为“哈希锁定合约（hash locked contract）”。 当部分动能状态，通过支付通道的通路（即人际网络）分享出去，就能建立起 “闪电网络（ Lightning Network ）”。 细节如下：

1. 有个 “顾客” 要付 10 btc 给 “店家”。

2. 顾客创建一个秘密随机数 R，以及 R 的可公开版本 H 。 H 就是 R 的哈希值，h(R)。

3. 顾客找出一条能使自己与店家连接起来的支付路线，把 H 发送给这条支付路线上的所有人。

4. 顾客沿着条 “通路”，向边上的 “朋友 #1” 发出一个动能更新； 特别的是，顾客承诺，如果 “朋友 #1” 能猜出 R 是什么，顾客会向他支付 10.004 btc。

5. “朋友 #1” 不知道 R ，但是他确定很快这个 R 就会被公布，而且他也不会有任何损失，因此朋友 #1 兴冲冲的接下这个活。 这时候，【顾客，朋友 #1】间的支付通道就被激活了，从 “势能” 状态转为 “动能” 状态。

6. 接着“朋友 #1” 和 “朋友 #2” 重复上述行为，在整条【顾客，店家】通路中，朋友 #2又比朋友 #1 更靠近店家。 如果朋友 #2 能够猜出 R，朋友 #1 会向其支付 10.0003 btc。

7. 整个过程继续重复进行，朋友 #3 会得到 10.0002 btc、朋友 #4 会得到 10.0001 btc； 最后，只要商家能猜到 R是什么，他就能从朋友 #4 那里得到 10 btc。

8. 现在整条通路已经完成了。 顾客把 R 发给商家，商家就能凭 R 向朋友 #4 索取 10 btc。

9. 商家向顾客发货。

10. 商家和朋友 #4 不想用常规交易来支付（这会需要付交易手续费，而且要等待）。 因此商家向朋友 #4 展示 R ，要求更新支付通道的状态。 接着支付通道状态就从 “动能“ 状态转回 ”势能“ 状态，只不过在新的势能状态下，商家多了 10 btc，而朋友 #4 少了10 btc。

11. 其他的通道对也重复进行步骤 10 。 （【朋友 #4，朋友 #3】、【朋友 #3，朋友 #2】、【朋友 #2，朋友 #1】、【朋友 #1，顾客】）（译者注： 即每个从下家处拿到 R 的人都向上家要求兑现承诺，直至最后一个中继者（即 “朋友”）从 “顾客” 处得到最后一笔的支付）。

E. 伸缩性

有趣的是，动能交易可不止是 HTLC（即 “你给我出示 R 我就给你付款“）而已。 闪电网络交易（LN-txn）能完成基于区块链的一切行为。

我们首先要求区块链能做两件事： “无效保障“和“完整性审核”。 只要底层区块链能够支持这种 “智能合约”，我们就能将其应用到支付通道中。

F. 支付通道解决了什么

支付通道能帮助实现错误性证明，因为：

1. 能以接近实时的速度进行需要的操作，帮助错误性证明在关键的 20-30 分钟内“获取足够的信息”。

2. 协助小额的交易（支付非常非常小的金额）。

3. 可抵御暂时的出块错误（因为它们有较长的 “挑战窗口期”）。

4. 通过以下行为支持反向证明： 【1】索要某些信息，【2】为此提供小额奖励，【3】给对方足够长的时间来提供它。 当然，如果他们没有接受挑战，那很有可能是因为他们无法完成。

现在我们可以来介绍 “无效保障“ 和 “完整性审核” 了。

- Max Pixel 的河流艺术作品-

注 5：实际上，Sally 和 Fred 可以一次只使用一个随机数。这样的话，在最糟糕的情境下的脚本大小会小一些，但他们需要执行多次交互。

（未完）

（未完）

（文内提供了许多超链接，请点击阅读原文到 EthFans 网站上获取）

原文链接:

http://www.truthcoin.info/blog/fraud-proofs/

作者:  Paul Sztorc

翻译 & 校对:IAN LIU & 阿剑