Skip to content

Commit 3b53df5

Browse files
berryjamgitbook-bot
authored andcommitted
GITBOOK-75: No subject
1 parent 3de6fe9 commit 3b53df5

14 files changed

+242
-95
lines changed

.gitbook/assets/14.5.png

58.8 KB
Loading

.gitbook/assets/14.6.png

66.8 KB
Loading

.gitbook/assets/14.7.png

124 KB
Loading

SUMMARY.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -292,6 +292,12 @@
292292
* [状态通道 - 基本概念和术语](di-shi-si-zhang-.-er-ceng-ying-yong/zhi-fu-tong-dao-he-zhuang-tai-tong-dao/zhuang-tai-tong-dao-ji-ben-gai-nian-he-shu-yu.md)
293293
* [简单支付通道示例](di-shi-si-zhang-.-er-ceng-ying-yong/zhi-fu-tong-dao-he-zhuang-tai-tong-dao/jian-dan-zhi-fu-tong-dao-shi-li.md)
294294
* [创建无需信任的通道](di-shi-si-zhang-.-er-ceng-ying-yong/zhi-fu-tong-dao-he-zhuang-tai-tong-dao/chuang-jian-wu-xu-xin-ren-de-tong-dao.md)
295+
* [非对称撤销承诺](di-shi-si-zhang-.-er-ceng-ying-yong/zhi-fu-tong-dao-he-zhuang-tai-tong-dao/fei-dui-cheng-che-xiao-cheng-nuo.md)
296+
* [哈希时间锁合约(Hash Time Lock Contracts -HTLC)](di-shi-si-zhang-.-er-ceng-ying-yong/zhi-fu-tong-dao-he-zhuang-tai-tong-dao/ha-xi-shi-jian-suo-he-yue-hash-time-lock-contracts-htlc.md)
297+
* [路由支付通道(闪电网络)](di-shi-si-zhang-.-er-ceng-ying-yong/lu-you-zhi-fu-tong-dao-shan-dian-wang-luo/README.md)
298+
* [基本闪电网络示例](di-shi-si-zhang-.-er-ceng-ying-yong/lu-you-zhi-fu-tong-dao-shan-dian-wang-luo/ji-ben-shan-dian-wang-luo-shi-li.md)
299+
* [闪电网络传输和路径查找](di-shi-si-zhang-.-er-ceng-ying-yong/lu-you-zhi-fu-tong-dao-shan-dian-wang-luo/shan-dian-wang-luo-chuan-shu-he-lu-jing-cha-zhao.md)
300+
* [闪电网络的好处](di-shi-si-zhang-.-er-ceng-ying-yong/lu-you-zhi-fu-tong-dao-shan-dian-wang-luo/shan-dian-wang-luo-de-hao-chu.md)
295301

296302
## 附录A. 比特币白皮书(by中本聪)
297303

@@ -310,9 +316,3 @@
310316
* [Icons](fu-lu-c.-bi-te-bi-gai-jin-jian-yi/icons.md)
311317
* [Buttons](fu-lu-c.-bi-te-bi-gai-jin-jian-yi/buttons.md)
312318
* [Inputs](fu-lu-c.-bi-te-bi-gai-jin-jian-yi/inputs.md)
313-
314-
## 索引
315-
316-
* [Icons](suo-yin/icons.md)
317-
* [Buttons](suo-yin/buttons.md)
318-
* [Inputs](suo-yin/inputs.md)
Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
# 路由支付通道(闪电网络)
2+
3+
\
4+
闪电网络(LN)是一个提议的双向支付通道的路由网络,连接端到端。这样的网络可以允许任何参与者在不信任任何中间人的情况下将支付从一个通道路由到另一个通道。LN[最早由Joseph Poon和Thadeus Dryja于2015年2月描述](https://lightning.network/lightning-network-paper.pdf),建立在许多其他人提出和详细阐述的支付通道概念之上。
5+
6+
“闪电网络”指的是一个用于路由支付通道网络的特定设计,目前至少有五个不同的开源团队实现了该设计。这些独立的实现由一组在[闪电技术基础(BOLT)存储库](https://github.com/lightning/bolts/blob/master/00-introduction.md)中描述的互操作性标准协调。
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
# 基本闪电网络示例
2+
3+
让我们看看这是如何工作的。 在这个示例中,我们有五个参与者:Alice、Bob、Carol、Diana和Eric。这五个参与者之间已经建立了支付通道,成对连接。Alice与Bob有一个支付通道,Bob与Carol连接,Carol与Diana连接,Diana与Eric连接。为简单起见,让我们假设每个通道由每个参与者提供2比特币的资金,因此每个通道的总容量为4比特币。 
4+
5+
图14-6显示了闪电网络中的五个参与者,通过双向支付通道相连,可以将支付从Alice发送到Eric(请参见第332页的“路由支付通道(闪电网络)”)。
6+
7+
<figure><img src="../../.gitbook/assets/14.6.png" alt=""><figcaption><p>图 14-6. 一系列双向支付通道连接在一起形成一个闪电网络,可以将支付从Alice发送到Eric。</p></figcaption></figure>
8+
9+
Alice想要支付给Eric 1比特币。然而,Alice与Eric之间没有通过支付通道连接。创建支付通道需要一笔资金交易,这笔交易必须被提交到比特币区块链上。Alice不想打开一个新的支付通道并承诺更多的资金。有没有一种间接支付给Eric的方法呢?&#x20;
10+
11+
图14-7显示了从Alice到Eric的支付通过一系列连接参与者的支付通道上的HTLC承诺的逐步过程。
12+
13+
<figure><img src="../../.gitbook/assets/14.7.png" alt=""><figcaption><p>图 14-7. 使用LN 的支付路由步骤</p></figcaption></figure>
14+
15+
Alice要向Eric支付1比特币。然而,Alice与Eric之间没有通过支付通道连接。创建支付通道需要一个资金交易,这必须提交到比特币区块链上。Alice不想开启一个新的支付通道并投入更多的资金。有没有一种方法可以间接地支付给Eric呢? 图14-7展示了从Alice向Eric路由支付的逐步过程,通过连接连接参与者之间的HTLC承诺的一系列支付通道。&#x20;
16+
17+
步骤1:Alice的LN节点跟踪着她与Bob的支付通道,并且能够发现不同通道之间的路由。此外,Alice的LN节点能够通过互联网连接到Eric的LN节点。Eric的LN节点使用随机数生成器生成一个秘密R。Eric的节点不会向任何人透露这个秘密。相反,Eric的节点计算了秘密R的哈希H,并以发票的形式将哈希传输给Alice的节点。&#x20;
18+
19+
步骤2:现在Alice的LN节点在Alice的节点和Eric的节点之间构建了一条路由。Alice的节点使用路径查找算法找到了一个有效的路由。
20+
21+
然后,Alice的节点构建了一个HTLC,付给哈希H,设置了10个区块的退款超时(当前区块 + 10),金额为1.003比特币。Alice向Bob提供了这个HTLC,从她与Bob的通道余额中扣除了1.003比特币,并将其分配给了HTLC。 HTLC的含义是:“如果Bob知道这个秘密,Alice承诺将通道余额中的1.003比特币支付给Bob,如果10个区块后Alice将其回收。” Alice的余额通过与Bob的通道的承诺交易来表达,其中包含三个输出:2比特币给Bob,0.997比特币给Alice,1.003比特币被提交给了Alice的HTLC。 Alice的余额减少了HTLC提交的金额。&#x20;
22+
23+
步骤3:Bob现在有了一项承诺,如果他能在接下来的10个区块内获得秘密R,他就可以获得Alice锁定的1.003比特币。有了这个承诺,Bob的节点在他与Carol的支付通道上构建了一个HTLC。Bob的HTLC承诺了1.002比特币给哈希H,持续9个区块,卡罗尔可以在其中拥有秘密R的情况下赎回。 Bob知道,如果Carol能够声明他的HTLC,她必须提供R。如果Bob在9个区块内获得R,他可以用它来获取Alice向他的HTLC。如果Carol无法获取他的HTLC并且他无法获取Alice的HTLC,一切将恢复到之前的通道余额,没有人会损失。 Bob和Carol之间的通道余额现在是:2给Carol,0.998给Bob,1.002由Bob提交给了HTLC。&#x20;
24+
25+
步骤4:现在,Carol有了一项承诺,如果她在接下来的九个区块内获得秘密R,她就可以获得Bob锁定的1.002比特币。现在,她可以在她与Diana的通道上进行HTLC承诺。她对哈希H承诺了1.001比特币,持续8个区块,Diana可以在其中拥有秘密R的情况下赎回。从Carol的角度来看,如果这样做可以获得0.001比特币,并且如果失败,她不会损失任何东西。她向Diana的HTLC只有在R被揭示后才有效,此时她可以从Bob那里获得HTLC。Carol和Diana之间的通道余额现在是:2给Diana,0.999给Carol,1.001由Carol提交给了HTLC。&#x20;
26+
27+
步骤5:最后,Diana可以向Eric提供一个HTLC,承诺1比特币给哈希H,持续7个区块。Diana和Eric之间的通道余额现在是:2给Eric,1给Diana,1由Diana提交给了HTLC。&#x20;
28+
29+
在这一步的路由中,Eric知道秘密R。因此,他可以要求Diana提供的HTLC。他将R发送给Diana并领取了1比特币,将其添加到他的通道余额中。&#x20;
30+
31+
现在,Eric和Diana之间的通道余额是:1给Diana,3给Eric。 现在,Diana知道了秘密R。因此,她现在可以要求Carol提供的HTLC。Diana将R发送给Carol,并将1.001比特币添加到她的通道余额中。现在,Carol和Diana之间的通道余额是:0.999给Carol,3.001给Diana。 Diana参与了此支付路由,获得了0.001的收益。&#x20;
32+
33+
通过路由返回,秘密R使每个参与者都能够要求未完成的HTLC。 Carol从Bob那里要求了1.002,将他们的通道余额设置为:0.998给Bob,3.002给Carol。最后,Bob从Alice那里要求了HTLC。 他们的通道余额更新为:0.997给Alice,3.003给Bob。&#x20;
34+
35+
Alice向Eric支付了1比特币,而不需要向Eric开启一个支付通道。支付路由中的任何中间方都不必互相信任。通过在通道中短暂承诺他们的资金,他们能够赚取一小笔费用,唯一的风险是如果通道关闭或路由支付失败,会有一小段时间的退款延迟。
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
# 闪电网络传输和路径查找
2+
3+
\
4+
闪电网络节点之间的所有通信都是点对点加密的。此外,节点具有用作标识符和相互验证的长期公钥。
5+
6+
当节点希望向另一个节点发送付款时,首先必须通过连接具有足够容量的付款通道来构建网络路径。节点会广播路由信息,包括它们打开的通道、每个通道的容量以及它们收取的路由费用。路由信息可以通过各种方式共享,随着LN技术的发展,不同的路径查找协议也应运而生。当前实现的路径发现使用P2P模型,其中节点以“泛洪”模式将通道公告传播给它们的对等节点,类似于比特币传播交易的方式。
7+
8+
在我们之前的例子中,Alice的节点使用这些路径发现机制之一找到连接她的节点和Eric的节点的一个或多个路径。一旦Alice的节点构建了一条路径,她将通过将一系列加密的和嵌套的指令传播到相邻的每个支付通道来初始化该路径。
9+
10+
重要的是,此路径仅为Alice的节点所知。付款路由中的所有其他参与者只看到相邻的节点。从Carol的角度来看,这看起来像是Bob向Diana支付的付款。Carol不知道Bob实际上是在转发Alice的付款,她也不知道Diana将要向Eric转发一笔付款。
11+
12+
这是LN的一个关键特性,因为它确保了付款的隐私,并且使得很难对其进行监视、审查或黑名单。但是,Alice如何建立这个付款路径而不向中间节点透露任何信息呢?
13+
14+
LN实现了一种基于名为Sphinx的方案的洋葱路由协议。此路由协议确保付款发送方可以构建和传输一条通过LN的路径,以便:
15+
16+
* 中间节点可以验证和解密它们的路由信息的一部分,并找到下一个跳点。
17+
* 除了前一个和下一个跳点之外,它们无法了解路径中的任何其他节点。
18+
* 它们无法确定付款路径的长度或自己在该路径中的位置。
19+
* 路径的每个部分都以一种方式加密,以使网络级攻击者无法将路径的不同部分的数据包相互关联。
20+
* 与互联网上的洋葱路由匿名协议Tor不同,没有“出口节点”可以被监视。付款不需要传输到比特币区块链上;节点只需要更新通道余额。
21+
22+
使用这种洋葱路由协议,Alice将路径的每个元素都包装在一层加密中,从最后开始,逐层向后处理。她使用Eric的公钥对一条消息进行加密,以将消息发送给Eric。然后,将此消息包装在一个加密的消息中,发送给Diana,同时将Eric标识为下一个接收者。对Diana的消息再次被包装在一个加密的消息中,发送给Carol,同时将Diana标识为下一个接收者。对Carol的消息被加密到Bob的公钥。因此,Alice构建了这个加密的多层“洋葱”消息。她将其发送给Bob,后者只能解密并解开外层。在内部,Bob发现了一条地址给Carol的消息,他可以转发给Carol,但自己无法解读。随着路径的传递,消息被转发、解密、转发,以此类推,一直到Eric。每个参与者只知道前一个和下一个节点在每一跳中。
23+
24+
路径的每个元素包含有关必须传递给下一跳的HTLC、发送的金额、要包括的费用以及HTLC的CLTV锁定时间(以区块为单位)到期的信息。随着路由信息的传播,节点将HTLC承诺转发到下一个跳点。
25+
26+
这时,您可能会想知道节点如何不知道路径的长度和自己在该路径中的位置。毕竟,他们收到一条消息并将其转发给下一个跳点。这条消息不是变得更短了吗,以便他们可以推断出路径的大小和自己的位置?为了防止这种情况发生,数据包的大小是固定的,并填充了随机数据。每个节点只能看到下一个跳点和一个固定长度的加密消息以转发。只有最终的接收者看到没有下一个跳点。对于其他人来说,似乎总是还有更多的跳点要走。
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
# 闪电网络的好处
2+
3+
闪电网络是一种第二层的路由技术。它可以应用于支持一些基本功能的任何区块链,如多重签名交易、时间锁和基本智能合约。
4+
5+
闪电网络建立在比特币网络之上,为比特币增加了显著的容量、隐私、细粒度和速度,同时不损害无需中介进行无信任操作的原则:
6+
7+
_隐私_&#x20;
8+
9+
&#x20; 闪电网络支付要比比特币区块链上的支付更加私密,因为它们不是公开的。虽然路由中的参与者可以看到沿着它们的通道传播的支付,但他们不知道发件人或收件人。
10+
11+
_可替换性_&#x20;
12+
13+
&#x20; 闪电网络使对比特币进行监视和黑名单的难度大大增加,增强了货币的可替代性。
14+
15+
_速度_&#x20;
16+
17+
&#x20; 使用闪电网络的比特币交易在毫秒内结算,而不是像使用HTLCs在交易提交到区块之前需要数分钟甚至数小时的时间。
18+
19+
_细粒度_&#x20;
20+
21+
&#x20; 闪电网络可以实现至少与比特币的“尘埃”限制一样小的支付,甚至可能更小。
22+
23+
_容量_&#x20;
24+
25+
&#x20; 闪电网络通过几个数量级增加了比特币系统的容量。可以通过闪电网络路由的每秒支付数量的上限仅取决于每个节点的容量和速度。
26+
27+
_无信任操作_&#x20;
28+
29+
&#x20; 闪电网络使用各个节点之间作为对等方的比特币交易。因此,闪电网络保留了比特币系统的原则,同时显著扩展了其运行参数。
30+
31+
我们仅仅探讨了使用比特币区块链作为信任平台构建的一些新兴应用。这些应用将比特币的范围扩展到了支付之外。
32+
33+
_**现在您已经读到了本书的末尾,您会如何运用您所获得的知识呢?数百万甚至数十亿人知道“比特币”这个名字,但只有很少一部分人像您现在这样对比特币的工作原理了解得很多。这种知识是宝贵的。更宝贵的是像您这样对比特币充满兴趣,愿意花时间阅读几百页内容的人。**_
34+
35+
如果您还没有开始行动,请考虑以某种方式为比特币做出贡献。您可以运行一个全节点来验证您收到的比特币支付,构建可以让其他人更轻松使用比特币的应用程序,或者帮助教育其他人了解比特币及其潜力。您甚至可以采取罕见的步骤,为开源比特币基础设施软件做出贡献,比如比特币核心,与一小部分非常聪明的人一起精心构建工具,尽管没有人会为此付费,但可能有数十亿人会依赖这些工具。
36+
37+
无论您的比特币之旅是什么样子,我们都感谢您将《精通比特币》纳入其中。

di-shi-si-zhang-.-er-ceng-ying-yong/zhi-fu-tong-dao-he-zhuang-tai-tong-dao/chuang-jian-wu-xu-xin-ren-de-tong-dao.md

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -22,3 +22,14 @@ Emma 不能冒险进行 2-of-2 多重签名资金,除非她有一种保证的
2222

2323
<figure><img src="../../.gitbook/assets/14.4.png" alt=""><figcaption><p>图 14-4 . 每个承诺交易都设置了较短的时间锁,使其可以在先前的承诺变为有效之前被消费</p></figcaption></figure>
2424

25+
每个后续的承诺交易都必须设置更短的时间锁,以便在其前身和退款交易之前进行广播。提前广播承诺交易的能力确保它能够支出资金输出,并阻止其他任何承诺交易通过支出输出来赎回。比特币区块链提供的保证,防止双重支付并强制执行时间锁,有效地使每个承诺交易都能使其前身无效。
26+
27+
状态通道使用时间锁来跨时间维度执行智能合约。在本示例中,我们看到时间维度保证了最近的承诺交易在任何早期承诺之前生效。因此,最新的承诺交易可以被传输,支出输入并使先前的承诺交易无效。使用绝对时间锁来执行智能合约可以防止其中一方作弊。这种实现除了绝对事务级别的锁定时间外,不需要任何其他内容。接下来,我们将看到如何使用脚本级别的时间锁,CHECKLOCKTIMEVERIFY 和 CHECKSEQUENCEVERIFY,来构建更灵活、有用和复杂的状态通道。
28+
29+
时间锁不是使前期承诺交易无效的唯一方法。在接下来的章节中,我们将看到如何使用吊销密钥来实现相同的结果。时间锁是有效的,但它们有两个明显的缺点。首先,在通道首次打开时,通过建立最大时间锁,它们限制了通道的寿命。更糟糕的是,它们迫使通道实现在允许长期存在的通道和迫使其中一方在提前关闭时等待很长时间以获得退款之间取得平衡。例如,如果通过将退款时间锁设置为30天来允许通道保持开放30天,则如果其中一方立即消失,另一方必须等待30天才能获得退款。终点越远,退款的时间就越长。
30+
31+
第二个问题是,由于每个后续的承诺交易必须递减时间锁,因此对于可以在各方之间交换的承诺交易数量有明确的限制。例如,一个30天的通道,将时间锁设置为未来的4320个块,只能容纳4320个中间承诺交易,然后必须关闭。将承诺交易之间的时间锁定间隔设置为1个块存在风险。通过将承诺交易之间的时间锁定间隔设置为1个块,开发人员为通道参与者创造了一个非常高的负担,他们必须保持警惕,保持在线并监视,并准备在任何时候传输正确的承诺交易。
32+
33+
在之前描述的单向通道示例中,消除每次承诺的时间锁是很容易的。在Emma从Fabian那里收到定时退款交易的签名后,不会在承诺交易上设置时间锁。相反,Emma向Fabian发送每个承诺交易的签名,但Fabian不会向Emma发送任何承诺交易的签名。这意味着只有Fabian拥有承诺交易的两个签名,因此只有他可以广播其中之一。当Emma完成视频流时,Fabian总是倾向于广播支付他最多的交易,即最新的状态。这种构造称为Spillman风格的支付通道,它最早是在2013年首次描述和实现的,尽管它们只能与见证(segwit)交易一起使用,这些交易直到2017年才可用。
34+
35+
现在我们了解了如何使用时间锁来使前期的承诺无效,我们可以看到通过广播承诺交易来合作关闭通道和单方关闭通道之间的区别。在我们之前的示例中,所有的承诺交易都有时间锁,因此广播承诺交易总是涉及等待直到时间锁到期。但是,如果双方就最终余额达成一致,并知道他们都持有最终将实现该余额的承诺交易,他们可以构建一个不带时间锁的结算交易来代表相同的余额。在合作关闭中,任何一方都可以采用最新的承诺交易并构建一个完全相同的结算交易,只是省略了时间锁。双方都可以签署此结算交易,因为知道没有任何作弊的方法,并且无法获得更有利的余额。通过合作签署和传输结算交易,他们可以立即关闭通道并兑现余额。最糟糕的情况是,其中一方可能会小气,拒绝合作,并迫使另一方通过最新的承诺交易进行单方关闭。如果这样做,他们也必须等待他们的资金。

0 commit comments

Comments
 (0)