Merge branch 'master' of github.com:yeasy/blockchain_guide

bitcoin/lightning_network.md

@@ -22,7 +22,7 @@ Recoverable Sequence Maturity Contract，中文可以翻译为“可撤销的顺
 
 不太恰当的例子，约定一定时间内，有人知道了某个暗语（可以生成匹配的哈希值），就可以拿到这个指定的资金。
 
-推广一步，甲想转账给丙，丙先发给甲一个哈希值。甲可以跟先乙签订一个合同，如果你在一定时间内能告诉我一个暗语，我就给你多少钱。乙于是跑去跟丙签订一个合同，如果你告诉我那个暗语，我就给你多少钱。丙于是告诉乙暗语，拿到乙的钱，乙又从甲拿到钱。最终达到结果是甲转账给丙。这样甲和丙之间似乎构成了一条完整的虚拟的“支付通道”。
+推广一步，甲想转账给丙，丙先发给甲一个哈希值。甲可以先跟乙签订一个合同，如果你在一定时间内能告诉我一个暗语，我就给你多少钱。乙于是跑去跟丙签订一个合同，如果你告诉我那个暗语，我就给你多少钱。丙于是告诉乙暗语，拿到乙的钱，乙又从甲拿到钱。最终达到结果是甲转账给丙。这样甲和丙之间似乎构成了一条完整的虚拟的“支付通道”。
 
 HTLC 的机制可以扩展到多个人，大家可以想象一下，想象出来了就理解了闪电网络。
 

distribute_system/bft.md

@@ -14,17 +14,17 @@
 
 对于拜占庭问题来说，假如节点总数为 N，叛变将军数为 F，则当 $$N \ge 3F+1$$ 时，问题才有解，即 Byzantine Fault Tolerant (BFT) 算法。
 
-例如，$$N=3，F=1$$ 时。
+例如，$$N=3, F=1$$ 时。
 
 提案人不是叛变者，提案人发送一个提案出来，叛变者可以宣称收到的是相反的命令。则对于第三个人（忠诚者）收到两个相反的消息，无法判断谁是叛变者，则系统无法达到一致。
 
 提案人是叛变者，发送两个相反的提案分别给另外两人，另外两人都收到两个相反的消息，无法判断究竟谁是叛变者，则系统无法达到一致。
 
-更一般的，当提案人不是叛变者，提案人提出提案信息 $$1$$，则对于合作者来看，系统中会有 $$N-F$$ 份确定的信息 $$1$$，和 $$F$$ 份不确定的信息（可能为 $$0$$ 或 $$1$$，假设叛变者会尽量干扰一致的达成），$$N−F > F$$，即 $$N > 2F$$ 情况下才能达成一致。
+更一般的，当提案人不是叛变者，提案人提出提案信息 $$1$$，则对于合作者来看，系统中会有 $$N-F$$ 份确定的信息 $$1$$，和 $$F$$ 份不确定的信息（可能为 $$0$$ 或 $$1$$，假设叛变者会尽量干扰一致的达成），$$N-F > F$$，即 $$N > 2F$$ 情况下才能达成一致。
 
-当提案人是叛变者，会尽量发送相反的提案给 $$N-F$$ 个合作者，从收到 1 的合作者看来，系统中会存在 $$\frac{N-F}{2}$$ 个信息 1，以及 $$\frac{N-F}{2}$$ 个信息 0；从收到 0 的合作者看来，系统中会存在 $$\frac{N-F}{2}$$ 个信息 0，以及 $$\frac{N-F}{2}$$ 个信息 1；
+当提案人是叛变者，会尽量发送相反的提案给 $$N-F$$ 个合作者，从收到 $$1$$ 的合作者看来，系统中会存在 $$\frac{N-F}{2}$$ 个信息 $$1$$，以及 $$\frac{N-F}{2}$$ 个信息  $$0$$ ；从收到 $$0$$ 的合作者看来，系统中会存在 $$\frac{N-F}{2}$$ 个信息 $$0$$ ，以及 $$\frac{N-F}{2}$$ 个信息 $$1$$ ；
 
-另外存在 F−1 个不确定的信息。合作者要想达成一致，必须进一步的对所获得的消息进行判定，询问其他人某个被怀疑对象的消息值，并通过取多数来作为被怀疑者的信息值。这个过程可以进一步递归下去。
+另外存在 $$F-1$$  个不确定的信息。合作者要想达成一致，必须进一步的对所获得的消息进行判定，询问其他人某个被怀疑对象的消息值，并通过取多数来作为被怀疑者的信息值。这个过程可以进一步递归下去。
 
 Leslie Lamport 证明，当叛变者不超过 $$\frac{1}{3}$$ 时，存在有效的算法，不论叛变者如何折腾，忠诚的将军们总能达成一致的结果。如果叛变者过多，则无法保证一定能达到一致性。