# Annoy - 闪电网络：技术与用户体验（三）：路由 (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/38436378) **Source**:: #from/readwise #from/reader **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Annoy]] **Full Title**:: 闪电网络：技术与用户体验（三）：路由 **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **Document Tags**:: #work **URL**:: [www.btcstudy.org](https://www.btcstudy.org/2024/02/23/lightning-network-technology-improvement-and-users-experience-part-3/) **Host**:: [[www.btcstudy.org]] **Highlighted**:: [[2024-03-06]] **Created**:: [[2024-03-08]] ## Highlights - 值得一提的是，有一种信息并不是全网公开的信息：每一条通道的双方实时余额。 ([View Highlight](https://read.readwise.io/read/01hrb1nsq55ezsh6st3g5yqm8w)) ^689078015 - 发票中包含了接收方节点的签名，可用于复原出接收方节点的公钥，也即其 `node_id`，从而允许我们定位到闪电网络中的具体一个节点。发票中也包含了支付额以及支付哈希值，允许支付方使用这个哈希值来建立 HTLC。发票还可以包含要求支付方写明的备注、支付过期时间等信息。 ([View Highlight](https://read.readwise.io/read/01hrb1qn3425f077b3vt0178p5)) ^689078218 - 当前闪电网络的两个主要客户端实现 LND 和 Core Lightning 都使用 Dijkstra 算法[4](https://www.btcstudy.org/2024/02/23/lightning-network-technology-improvement-and-users-experience-part-3/#note4) 的某个变种[5](https://www.btcstudy.org/2024/02/23/lightning-network-technology-improvement-and-users-experience-part-3/#note5) [6](https://www.btcstudy.org/2024/02/23/lightning-network-technology-improvement-and-users-experience-part-3/#note6)。该算法常常用于在固定一个起点时寻找触达其它点的最短路径。 ([View Highlight](https://read.readwise.io/read/01hrb1r9gcq2gj3vkmzckdxnbe)) ^689078239 - 发送者在一开始计算好路径之后，就构造出给每一个转发节点的指令，然后以加密的方式，确保相应的指令只能被相应的节点知晓。因此，每一个节点都不知道后续的节点收到的是什么样的指令。 ([View Highlight](https://read.readwise.io/read/01hrb1v3hqg8cptem1t2gpb956)) ^689078631 - 每个节点在解密、删去自己可读的消息之后，往下一个节点传递加密数据包时，会用垃圾数据将它填充到自己所获得的加密数据包的长度，所以，每一个节点收到的加密数据包的长度都是相同的。 ([View Highlight](https://read.readwise.io/read/01hrb1w2zeb1v0a7gm0z1yt653)) ^689078679 - 这是使用一种叫做 “Sphinx” 的消息构造技术实现的。其关键是按支付路径的倒序构造支付指令和加密包，并且层层加密 ([View Highlight](https://read.readwise.io/read/01hrb1y5ywyrznkbzr3e9x3hgw)) ^689079032 - 与加密包伴随的是一段元数据，可被对应的节点用来解密（但对其他人是无用的）。给下一个节点的元数据总能依据本节点得到的元数据构造出来，所以 Alice 只需构造给 Bob 的元数据就可以了。 ([View Highlight](https://read.readwise.io/read/01hrb1yq616hr1pnk0qqsvrrtj)) ^689079052 - 最终，每个转发节点收到的消息都是 1366 字节，其中 1300 字节是加密数据包；而剩余的 66 字节则是元数据。 ([View Highlight](https://read.readwise.io/read/01hrb1yy6xpa91q5xytzqk4bpj)) ^689079300 - 这种在构造时层层加密、读取时层层解密的消息，非常类似于洋葱（onion），这就是为什么整套协议被命名为 “洋葱路由”。 ([View Highlight](https://read.readwise.io/read/01hrb1zsw3vebvkwgh892593ww)) ^689079466 - 发送者可以将一笔支付额拆成多笔更小额的支付，每一笔都使用相同的哈希值建构 HTLC，然后使用不同的支付路径送达。这就是所谓的 “多路径支付（MPP）”。 ([View Highlight](https://read.readwise.io/read/01hrb2380myq3n8my6wy3q30gp)) ^689079843 - 拆开的多笔支付不一定能同时送达，甚至可能只有一些会送达，而另一些会失败。这该怎么办呢？如果接收者在只收到一部分支付碎片时就回传原像，岂不就遭遇了损失？答案是，不怎么办 —— 只要接收者节点不在所有支付碎片都到达之前回传原像，就不会遭遇经济损失，而这是接收者节点出于自己的利益，会自然而然采取的行为。 ([View Highlight](https://read.readwise.io/read/01hrb23rqfe7vjvr77m9tf8gvd)) ^689079882 - LND 客户端实现了一种叫做 “原子化多路径支付” 的技术。顾名思义，就是可以保证所有支付碎片要么一起成功，要么一起失败 —— 尽管仍可能遭遇一些支付碎片无法送达的情形，但接收者却一定不会遭遇损失，不会在只收到部分碎片的时候就返回原像。这是因为，用来构建 HTLC 的哈希值并不是由接收者给出的，而是由发送者指定的，并且发送者将原像的信息分散在不同路径的支付转发消息中。只有所有消息都到达，发送者才能抽取完整的原像信息，并让所有支付路径都回传原像。 ([View Highlight](https://read.readwise.io/read/01hrb24pvk791fe0axa4b07g7t)) ^689079952 - 发送者可以创建一种基于 PTLC 的、可以收到支付证据的、原子化的多路径支付：生成 n 个秘密值 `s_i`，这些秘密值的和为 `s`；在不同支付碎片的支付转发消息中告诉接收者不同的 `s_i`，并在支付路径的最后一跳中要求检查 `S + A` 的秘密值，也即 `s + a`。 仅当所有的支付转发消息（支付碎片）都送达的时候，接收者才能知道 `s`，然后才能在所有支付路径中回传秘密值。而发送者也可以收到支付证据 `a`。 ([View Highlight](https://read.readwise.io/read/01hrb26gq2vqs8gvq3n4tq49fm)) ^689080017 - “蹦床路由（Trampoline payments）” 就是一种解决这个问题的技术，其思路是：假定 Franky 具有完整的拓扑图，而发送者 Alice 没有，但是知道 Franky 的闪电网络位置；那么，Alice 先找出触达蹦床节点 Franky 的路径，然后再由 Franky 找出触达接收者 Diana 的路径。这就把保存和更新拓扑图、规划路径的工作外包给了 Franky。 ([View Highlight](https://read.readwise.io/read/01hrb28gdxv81684n5y29qt26g)) ^689080157 - 因为洋葱路由的采用，闪电支付的发送方享有非常好的隐私性：支付路径上的转发节点并不知道自己前面有多少跳，也就难以确定发送方的位置。但是，接收者的隐私性，相对来说就没有那么好。转发节点可以通过 HTLC 的持续时间和数额猜测自己跟最终接收者的距离；接收者的节点位置首先要暴露给发送者，还有可能被发送者暴露给第三方（蹦床节点）。这些都是接收者隐私性的瑕疵。 ([View Highlight](https://read.readwise.io/read/01hrb2abx288bnwchwp47qq86t)) ^689080241 - “路径盲化（route blinding）” 就是旨在解决这个问题的尝试。其想法是，接收者向发送者暴露的不是自己的闪电网络位置（`node_id`），而是一条可以触达自身的路径；并且，这条路径所经过的节点和通道，是不向发送者暴露的（“盲化”）；发送者能知道的仅有这条路径的 “入口节点”，即第一个节点。 ([View Highlight](https://read.readwise.io/read/01hrb2bbajq5bzd11b0awx6x01)) ^689080282 - 值得一提的是，蹦床路由和路径盲化实际上可以相结合。Eclair 客户端就实现了将两者相结合的特性 [13](https://www.btcstudy.org/2024/02/23/lightning-network-technology-improvement-and-users-experience-part-3/#note13)。 ([View Highlight](https://read.readwise.io/read/01hrb2bt7nx1vhx6waykmhs7n3)) ^689080295