LIC:闪电网络中的 “洋葱路由” 是什么及其工作原理_alice币百倍币

作者：

时间：

原文作者：LORENZO 编译：btcstudy

一个网络中的计算机依据协议跟彼此交流。在这里，“协议” 指的是一套规则系统，指定了消息应该如何传输和解读。闪电网络协议中的支付消息传输部分由 BOLT#4 描述，也叫 “洋葱路由协议（Onion Rounting Protocol）”。

洋葱路由是一种先于闪电网络 25 年诞生的技术。它也被用在 Tor 中，正是 “Tor” 这个名字（“The Onion Router”）的由来。闪电网络使用的是一个稍微修改之后的版本，叫做 “基于来源的洋葱路由”，缩写是 “SPHINX”。在这篇文章中，我们就要讲讲洋葱路由是怎么工作的。

世界上存在许多不同的通信协议，但因为闪电网络是一个支付网络，选择一个尽可能少揭示正被转发的支付的信息的协议，就是合理的。

如果闪电网络使用跟互联网一样的协议，每一个中间人都会知道谁是支付的发送者、谁是接收者、整条路径上的其他中间人是谁。洋葱路由是一个好的选择，因为其特性保证了中间节点：

只知道自己的上一个节点（谁给自己发来了消息）和下一个节点（要把消息转发到哪里去）。

不知道整条路径的长度；

不知道自己在路径中的位置。

我们用包裹作为类比，解释一下洋葱路由是怎么工作的。

假设 Alice 要给 Dina 支付。首先，Alice 要为自己的支付找出一条可行的路径：

Alice → Bob → Chan → Dina然后，她构造出一个 “洋葱”。她要从 Dina 开始（从路径的末端开始）。她把一个秘密消息（支付内容）放在一个发送给 Dina 的包裹中，并且使用一个只有她和 Dina 知道的密钥来上锁。现在，她把这个包裹放到另一个准备发送给 Chan 的包裹中，并且使用只有她和 Chan 知道的密钥，给这个发送给 Chan 的包裹上锁。对以此类推。

比特币闪电网络容量突破3400枚BTC 创历史新高:金色财经报道，据最新数据显示，比特币闪电网络容量已突破3400枚BTC，创下历史新高，本文撰写时为3,400.59 BTC，约合130,720,570.17美元，7日增幅为3%；此外，比特币闪电网络通道数量达到86,455个，7日增幅2.9%，节点数量达到34,181个，7日增幅5.82%。比特币闪电网络容量在2021年12月3日触及3300 BTC，这意味着两个月内增加了100枚BTC。[2022/2/2 9:27:02]

Alice 把最终的洋葱（包裹）发给路径上的第一个中间人，Bob。Bob 使用自己的密钥解锁自己的包裹，然后看到下一个包裹是发送给 Chan 的。于是他把包裹转发给 Chan。Chan 也一样，解开包裹之后，把里面那个包裹转发给 Dina。最后，Dina 打开属于自己的包裹，发现其中的支付消息。

在洋葱路由中，像 Bob 和 Chan 这样的中间人，并不知道给 Dina 的信息的内容，也不知道整条支付路径的长度。他们唯一知道的，就是给他们转发这个包裹的人，以及下一个接收包裹的人。这保证了消息的隐私性和路径的机密性。每一个中间人都只能触及专门为 TA 制作的那一层消息。

在闪电网络的基于来源的洋葱路由中，发送者选择支付路径，并为这条路径构造出完整的洋葱，这可以被视为隐私漏洞（译者注：接收者的网络位置必须向发送者曝光）。别的路由方案比如 “盲化路由”（中文译本），通过向发送者混淆部分支付路径来解决这个问题。不过，在这篇文章中，我们专讲 SPHINX。

现在，我们来了解一下洋葱路由的规范。在一开始，我们需要定义这些东西：

发送者是 “最初节点”（Alice）；

接收者是 “最终节点”（Dina）；

支付路径上的每一个中间节点都是一 “跳”（Bob 和 Chan）；

闪电网络节点数量已达31831个:金色财经报道，据1ML.com数据，目前，支撑网络的节点数量达到31831个，相较30天前数据，环比上涨4.9%；通道数量为83355，相较30天前数据，环比上涨3.1%；闪电网络承载能力目前为3303.94BTC，约合1.51亿美元。[2021/12/20 7:51:58]

每一跳之间的通信信息，叫做 “跳的负载”。

一旦 Alice 选出了一条支付路径，她就从 gossip 协议中获得每一条支付通道的信息，以创建每一跳的负载，本质上这就是在告诉每一跳，如何为正在转发的支付创建 HTLC（哈希时间锁合约）。

为了建立一个合适的 HTLC，每一跳都需要：

需要转发的数额；

支付的秘密值；

继续发送洋葱的支付通道的 ID；

时间锁的长度。

这些数据中的大部分，都来自 “通道更新” 消息，这样的消息包含了关于路由手续费、事件所要求、支付通道 ID 的信息。需要转发的总数额，是支付的数额加上后续每一跳所收取的手续费总和；而支付的秘密值则是由 Dina 计算出来并嵌进支付发票中的（由洋葱消息告知路径上的每一跳）。

Alice 从最终节点 Dina 开始。她在包裹中包含转发数额、时间锁时长数值、支付秘密值以及支付数额。注意，她不需要再加入通道 ID，因为 Dina 就是最终节点，不需要再将支付转发给其他人。

乍看起来，提供转发数额是多余的，因为这个数额跟支付数额是一样的，但是，多路径（multipath）支付会将支付总额通过多条路径送达，那时候两个数值就会不一致。

在 Chan 的负载中，Alice 加入 Chan 跟 Dina 的通道 ID。她还添加了转发数额以及时间锁数值。最后，Alice 创建给 Bob 的负载。Chan 为通过自己跟 Dina 的通道的支付收取 100 聪，因此，Alice 需要告诉 Bob 的转发数额是支付额加上手续费。根据 Chan 的通道更新消息，时间锁的数值也提高了 20（以区块为单位）。最后，Alice 也要考虑 Bob 的手续费和时间锁要求，给他一个时间锁长度为 700040、价值为 100200 聪的 HTLC。

闪电网络节点数量已达14931个:金色财经报道，据1ML.com数据，目前，支撑网络的节点数量达到14931个，相较30天前数据，环比上涨4.32%；通道数量为35817，相较30天前数据，环比上涨1%；闪电网络承载能力目前为1061.19BTC，约合1998.38万美元。[2020/12/1 22:47:06]

下一笔，Alice 通过为每一跳（包括最终节点）生成一个共享秘密值（shared secret），准备好洋葱。这个共享秘密值可以由 Alice 和目标那一跳各自生成出来，办法就是用自己的私钥与对方的公钥相乘。

共享秘密值对洋葱路由来说是必要的，这让 Alice 和每一跳可以推导出相同的密钥。然后，Alice 使用这些密钥来混淆洋葱的每一层，而那一跳则使用密钥来解开混淆。

为了保护 Alice 的隐私，她会为一个洋葱创建一个一次性的会话密钥，而不是使用自己的节点公钥，以推导共享秘密值。她给第一跳使用这个会话密钥，然后，对后续的每一跳，Alice 都将最新的密钥乘以一个盲化因子，从而确定性地随机化密钥。这些用来创建共享秘密值密钥，我们叫做 “临时密钥” 。

Bob、Chan 和 Dina，都需要跟 Alice 得到相同的秘密值，因此，他们需要知晓用在自己的会话中的临时密钥。Alice 只将第一个密钥放到洋葱中，以节约消息的体积。每一跳都计算下一个临时密钥，并将它嵌在给下一个节点的洋葱中。各跳可以使用自己的公钥和共享秘密值计算出 Alice 所用的盲化因子，从而确定下一个临时密钥。

如前所述，共享秘密值会被用来生成一些密钥，Alice 和对应跳可以用这些密钥对洋葱做一些操作。我们来看看每一个密钥的用途。

动态 | 闪电网络节点数量已达11592个:金色财经报道，1ML数据显示，闪电网络节点数量呈持续上升趋势。目前，支撑网络的节点数量达到11592个，在过去的30天中上涨4.05%；通道数量为36277，在过去的30天中增长0.96%。闪电网络承载能力目前为896.05BTC，约合865.86万美元。[2020/2/22]

Rho key

Rho key 被 Alice 用来加密一层洋葱；这样会混淆负载的内容，使外人无法解读。只有 rho key 的主人可以解密负载。这就是收到洋葱的节点要做的事：使用跟 Alice 的共享秘密值推导出 rho key，然后解密洋葱、阅读内容。

Mu key

Alice 使用 mu key 来为每一个负载创建一个校验和。她也会把校验和交给接收洋葱的那一跳。反过来，这一跳会使用 mu key 生成所收到的负载的校验和，检查是否与 Alice 给出的相匹配。这是为了检查负载的完整性，验证它没有被篡改过。

Pad key

这个密钥仅为 Alice 所用，用来生成随机的 “垃圾” 数据。这些数据也是洋葱的一部分，而且它跟支付路径的长度、洋葱已经通过多少跳无关，它让洋葱总是保持相同的体积，即使其某些内容需是无关紧要的。这就是洋葱路由如何隐藏路径长度的，实际上就是在保护发送者和接收者的隐私。

Um key

这个密钥也用来检查洋葱内包含的数据的完整性，但仅在回传错误时使用。没错，它叫做 “um” 是因为这是 “mu” 的倒写。在支付出错的情形中，发现错误的那一跳将使用 um key 创建一个校验和，当前一个节点收到这个报错时，也使用 um key 来验证消息的完整性。

最终的洋葱包裹看起来是这样的：

现在，Alice 拥有了给每一跳的负载，以及给每一跳的共享秘密值。我们来看看 Alice 如何将这些信息转化为最终的洋葱。她先从最终节点开始，然后一步一步往回推。

声音 | Blockstream CSO：很快就可以在Liquid和闪电网络之间进行比特币资产交换:区块链技术公司Blockstream的CSO Samson Mow发推特称，人们很快就可以在资产发布平台Liquid和闪电网络（LN）之间进行比特币资产交换。LiquidNetwork是连接所有与BTC兼容应用的桥梁。[2019/7/18]

她先创建一个空的、长为 1300 字节的域，这也是所有洋葱负载的总长。然后，她使用 pad key创建一段长为 1300 字节的随机串，这就是对任何一跳都没用的垃圾。做这一步，是为了确保每一层洋葱看起来都是一样的，所以既无法看出路径的总长（有多少跳），也看不出谁是发送者、谁是接收者。

然后，她给需要使用的负载创建一个校验和，并放在负载的末尾。在给最终节点的消息中，校验和全部为 0，以告知 Dina，她就是这个洋葱的最终接收者。把校验和添加到负载的末尾之后，Alice 就把负载（以及校验和）放到垃圾的开头，并删去整条消息超过 1300 字节的部分，以保证整个消息的长度就是 1300 字节。

然后，Alice 使用 rho key 创建一个随机字节串，并对上一步得到的洋葱负载使用异或（XOR）运算，得到混淆后的负载。负载的原文可以通过对混淆文使用这个随机字节串的 XOR 运算得到（译者注：换言之，这里的 XOR 就是对称加密的算法，而随机字节串就是密钥）。XOR 操作会逐比特对比洋葱负载和（由 rho key 生成的）随机字节串，仅当其中一个数据的比特是 1 时，才会输出 1；这就得出了一个混淆后的负载。XOR 操作巧妙的地方在于，只要你得到了对的那个随机字节串以及混淆后的负载，只需用两者再次运行 XOR 操作，就可以得到混淆之前的负载。

因为收到洋葱的节点可以推导出相同的 rho key，可以他们可以生成跟 Alice 一样的随机字节串。这就是沿路的各个节点可以解开混淆、读到内容的办法。

准备好一跳的混淆洋葱后，Alice 就给下一个节点重复相同的步骤。关键区别在于，完成 Dina 的洋葱之后，她就不再需要生成垃圾了。她只需在有用的负载和校验和之后接上上一步所生成的混淆洋葱，再剪去超过 1300 字节的部分。下面这个 GIF 演示了整个过程：https://youtu.be/FzedRXqZDyY

最后，Alice 拿到最终的混淆洋葱并添加一个校验和，这样 Bob 就可以验证这个洋葱的完整性。然后，Alice 加入会话公钥，这样 Bob 就可以使用这个公钥来计算共享秘密值。最后，她还要加上一个表示版本的字节，告知其它节点如何解读其中的数据。对 BOLT#4 所描述的版本来说，版本字节应为 0。

为了发送这个洋葱包裹，发送者创建一条 update_add_htlc 消息，包含下列字段：

通道 ID：这个消息所关乎的具体通道。

ID：这个 HTLC 的标识符。

数额：这个 HTLC 的价值。

支付哈希值：由支付的接收方创建。

过期时间：这个 HTLC 将在一定区块之后过期。

洋葱包裹：为这笔支付创建的洋葱，也就是上面讲到的东西。

额外的数据：用来指定额外的数据。

准备好消息后，Alice 就把消息发送个 Bob。收到消息后，Bob 就可以开始解码属于自己的洋葱了。他先从洋葱包裹中获得会话密钥，然后使用它推导出跟 Alice 的共享秘密值。

有了共享秘密值，Bob 生成 mu key，以验证嵌在洋葱包裹中、负载的校验和。如果负载没有被篡改过，校验和应该能匹配上。

为了防止路径中的其他节点知道路径有多长，Bob 会在洋葱包裹内增加一个 1300 字节长、充满了 0 的字段。然后，Bob 从 rho key 中生成一个 2600 字节长的随机字节串。Bob 使用这个随机字节串，对填充了 0 的洋葱负载作 “异或” 运算。

还记得我怎么跟你说混淆洋葱负载的吗？使用混淆后的洋葱负载作为输入，跟相同的字节串运行 “异或” 操作，就能得到混淆前的洋葱负载。因为 Alice 和 Bob 使用相同的共享秘密值，生成了相同的 rho key，Bob 可以解开混淆。这样做的额外好处是，它又将 1300 字节长的填充字符变成了随机字节。

Bob 解开混淆的负载中包括了他这一跳的负载数据以及一个指纹。Bob 保存这个指纹，以便将它添加到发送给 Chan 的洋葱包裹中。在 Bob 将属于自己的负载从洋葱消息中分离出来后，他将洋葱包裹转回 1300 字节的原始大小，并跟 Alice 一样随机化自己的会话密钥。最后，Bob 加上版本字节、会话密钥以及他准备放在洋葱负载中的指纹，就通过 update_add_htlc 消息将洋葱包裹转发给 Chan。

这个过程会一直持续，直至消息送到最终节点，Dina。当 Dina 收到 update_add_htlc 消息时，她可以揣进到自己所生成的秘密值的哈希值，这说明这个 HTLC 就是要发给她的。因此，Dina 只需检查指纹、解开洋葱消息、揭晓属于自己的负载。这个动图演示了整个过程：https://youtu.be/NhHAE6m9L6A

我们介绍的是一个成功案例，也就是一切都按部就班的案例，但如果这个过程发生了一些错误，那就必须一路回传一条消息，以通知所有节点出了问题。这个过程跟常规的洋葱路由类似。发现一个错误的故节点需要从共享秘密值中推导出 um key，并使用它生成一个随机字节串，然后使用异或运算来混淆返回的洋葱包裹。

发现错误的节点将给支付路径的上一个节点回传一条消息。每一跳都使用 um key 和 ammag key 作相同的操作，直到发送者收到这个包裹。最后，发送者分别使用 ammag key 和 um key 解开包裹的混淆并验证。

错误可能由洋葱包裹、节点或通道引起。如果你经常使用闪电网络，你可能遇到过这样的错误，比如 “通道不可用” 或 “手续费不足”。

参考文献

Mastering the Lightning Network

BOLT #4: Onion Routing Protocol

BTCStudy

个人专栏

阅读更多

金色早8点

金色财经子木

欧科云链