Refactor

book.json

@@ -1,16 +1,19 @@
 {
-    "title": "用 golang 从零开始构建区块链系列教程",
+    "title": "区块链系列教程",
     "description": "从基本原型，工作量证明，到交易，网络等各部分的区块链系列教程",
     "author": "liuchengxu",
     "output.name": "site",
     "language": "zh-hans",
     "gitbook": "3.2.3",
-    "root": ".",
+    "root": "./content",
     "links": {
         "sidebar": {
             "Home": "https://github.com/liuchengxu/blockchain-tutorial"
         }
     },
+    "styles": {
+        "website": "styles/website.css"
+    },
     "plugins": [
         "-lunr",
         "-search",

content/README.md

@@ -0,0 +1,14 @@
+区块链教程
+==========
+
+本教程内容涉及：
+
+- 用 golang 从零开始构建区块链系列
+- 区块链基础知识
+- Ethereum
+- Cardano
+- Orchid
+- Polkadot
+- ......
+
+实际上，本教程也是我对于区块链认识的一个剪影。区块链不仅仅是计算机科学，还涉及了政治经济制度，社会分工协作等等很多方面，因此我的关注点不仅在于深度，更在于其广度，更多是站在研究的角度，而非仅仅是一个程序员的视角。

content/fundamentals/byzantine-fault-tolerance.md

@@ -0,0 +1,34 @@
+
+- 无解的两将军问题
+- 拜占庭将军问题
+- 拜占庭容错
+
+## 两将军问题
+
+1975 年首次发表 http://hydra.infosys.tuwien.ac.at/teaching/courses/AdvancedDistributedSystems/download/1975_Akkoyunlu,%20Ekanadham,%20Huber_Some%20constraints%20and%20tradeoffs%20in%20the%20design%20of%20network%20communications.pdf  , 1978 年该问题正式命名为两将军问题(two generals problem)。说的是两个将军商量攻击一个共同的敌人，将军 1 为主，将军 2 为从。无论是将军 1 还是 2，仅凭其自身军队，谁也无法打败敌军。因此，他们必须合作，并在同一时间点同时发起进攻。这个问题看似很简单，却有一个避不开的问题：
+
+将军 1 为了要告诉将军 2 进攻时间，必须要派信使穿过敌方军营通知将军 2。但是，信使可能会被敌方截获，因此信息也就无法送达将军 2。这就会导致将军 1 进攻的时候，将军 2 按兵不动，那么攻击就会失败。
+
+即使将军 1 的信使将进攻时间顺利送达，将军 2 还必须要进行回应，告诉将军 1 确实收到了信息。这有点像三方的 [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol)。那么又会出现上面的问题，信使可能会被敌军抓获。这就会造成无限的 ACK，两个将军永远也无法达成共识。
+
+两将军问题已经被证明是[无解](https://en.wikipedia.org/wiki/Two_Generals%27_Problem#Proof)的。
+
+
+## 拜占庭将军问题
+
+[ Lamport, Shostak and Pease 1982](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.126.9525&rep=rep1&type=pdf)，这是两将军问题的广义版本。还是同一个场景，不同的地方是现在不只有两个将军，而是有更多的将军。此外还有更复杂的一点，这些将军里面可能有叛徒，叛徒会发出错误信心，比如说 9 点攻击，但是实际 9 点并不会攻击。
+
+
+对于任意 m，如果有超过 3m 个将军，至多 m 个叛徒，算法 OM(m) 达成共识。
+
+这表明只要有 2/3 的参与者是诚实的，那么算法就能达成共识。而一旦叛徒超过 1/3，就无法达成共识，无法阻止进攻，敌军自然胜利。
+
+
+>参与者的目标是选择一个大部分都同意的同一个决定，而不是指定某一个决定。
+
+
+7 个将军，两个叛徒，更多内容 [这里](http://marknelson.us/2007/07/23/byzantine/)
+
+参考：
+
+[1] https://medium.com/loom-network/understanding-blockchain-fundamentals-part-1-byzantine-fault-tolerance-245f46fe8419

content/iota/iota_consensus_v1.0.md

@@ -0,0 +1,103 @@
+
+><sup>IOTA Donations: QPLGOG9PMIMUAW9UDMUNZQHPXZPXDNGLBEIHILXHWHIOFHLIHPDDERXAJQKUQDEORMHSUWVZQE9JYSHIWADIIPAOJD</sup>
+
+# IOTA 交易，确认和共识
+
+## 初始 Tangle 状态
+
+![Imgur](https://i.imgur.com/nJEE6Gp.png)
+
+In contrast to blockchain technologies, IOTA does not build a clocked sequence of static blocks, each one containing a number of transactions. Instead, every single transaction can be attached to a by itself and in parallel to other transactions. The following slides will describe how adding transactions, validation and consensus works in IOTA.
+
+The graph above shows a sample of a tangle which will be used in the subsequent slides to walk through some examples. In this and subsequent examples, green transactions are already confirmed by the network with high certainty (You‘ll find out why later. Spoiler: As with blockchain, it is about probabilities and there never going to be 100% carved-in-stone certainty), while the blue ones are only partially confirmed (with lower certainty). The grey (and later “yellow”) boxes represent tips without any validation. Red transactions, on the later slides, are conflicting or invalid ones.
+
+In the graph above transaction “α“ is an example of an unusual transaction. It is referencing transaction „h“ and „l“. Since transaction „h“ is already referenced by transaction „l“, “α“ would select one tip (“l”) and one transaction that is obviously no tip at that time anymore (“h”). Such behavior seems to be no issue and tolerated by the network, currently.
+
+
+
+## 加入一笔交易
+
+![Imgur](https://i.imgur.com/jnl4F7n.png)
+
+In order to add a new transaction to the tangle, a user has to randomly pick two tangle tips (yet unconfirmed transactions) and validate them. Validating means that the user is checking the tip‘s signature, its PoW (little “Proof of Work” as spam protection) and makes sure that the tip is not in conflict with any of the previous (directly or indirectly referenced) transactions. If the chosen tips are legit, the user adds its new transaction by referencing them.
+
+Transactions neither directly nor indirectly referenced by the chosen tips, are irrelevant for the current validation process. Somebody else, or a later transaction will take care of validating and knitting them into the tangle.
+
+## 另一笔交易
+
+![Imgur](https://i.imgur.com/9cLQIS5.png)
+
+At the same time (or earlier or later, whatever) another user might be about to add its new transaction in a different position. It chose the tips “z” and “y”. By doing so, it is validating a large portion of the same transactions as already validated via transaction „1“ (“a” to “k”, “m” and “n”), plus some additional ones that were not in the validation path of transaction „1“ (“l”, “o”, “r”, “t”, “v”, “y” and “z”).
+
+
+
+## 新的 Tangle 状态
+
+![Imgur](https://i.imgur.com/0VrE8BE.png)
+
+By overlaying the validation paths of transaction “1” and “2”, we can see that some of the transactions are only confirmed by one, while others were confirmed by both of them. Transactions validated and confirmed by all of the current tips are considered fully confirmed. Hence, transactions “n” moved deeper into the tangle and turned green now. All subsequent transactions attaching to “1” and/or “2” or its children or theirs again (and so on) will keep re-validating and confirming transaction “n” from now on.
+
+What did we learn?
+- Nobody needs to see and validate all transactions. Every user just needs to select and validate two transactions and their parents. By doing so they are only validating a part of the tangle. As other users select and validate different tips and paths, a collaborative validation of the complete tangle emerges. 
+- After some time, once a transaction is deep enough in the tangle, a direct or indirect path from any of latest tips towards it exists. Such a transaction is considered fully confirmed and is going to be re-validated and re-confirmed again by every single new transaction.  We can assume that it got confirmed by all users (and machines) and has high certainty.
+- In order to check for confirmation, a recipient only needs to check whether the transaction is directly or indirectly referenced all available tips yet (or by a certain rate of them if a lower certainty, such as 80%, is accepted). No re-validation or similar is necessary. Note: There might be thousands of tips. Instead of checking the parents of each of them, it is possible to select a random sample and do a statistical evaluation.
+
+Note that transaction “n” did not just get confirmed because we have less tips now. The next slide shows the same sample with more tips.
+
+
+
+## 确认级别
+
+![Imgur](https://i.imgur.com/s1oERZN.png)
+
+I added some more new tips to show an extended example. For each new tip its validation path is highlighted. By the coloring you can see well which transactions are validated by how many tips and their confirmation levels.
+
+A merchant may choose a custom confirmation/certainty level. If transaction speed is more important than the value of the transaction (e.g. a micro transaction or zero value transaction), or if the sender is a friend, one may accept something such as a 75% confirmation level. At a 75% certainty level (3 out of 4 tips), the transactions “l”, “o” and “t” could be considered as confirmed, as well.
+
+
+
+## 传播延迟
+
+![Imgur](https://i.imgur.com/QLPpmKA.png)
+
+Theoretically it could happen that a slow transaction “5” pops up a bit later, due to slower PoW or due to propagation delays. Now that we know of transaction „5“, the transaction „n“ is not fully confirmed by all tips anymore. However, their confirmation certainty is still quite high with 4 out of 5 tips (in reality there would be thousands instead of 5 tips). Keep in mind, it’s all about a high probability of certainty – just as in blockchain technologies with its confirmations where each block on top increases the probability of certainty. 
+
+Please note that transaction “5” in this example is NOT flipping the transaction’s state from “confirmed” back to “unconfirmed”. It just changes the mathematically exact number of certainty (e.g. if there were 100 tips in total, from 100% to 99%). Once some subsequent transaction references (e.g.) transaction “1” and “5”, the transactions “n” is fully confirmed by all tips again. Such minor confirmation level variations will even less likely happen, the further transactions move into the tangle.
+
+Please note that a confirmation/certainty level of a 100% might be hard to achieve anyways, as there could always be some troll tip around (e.g., referencing something useless or not following the protocol). 
+
+
+
+## 双花
+
+![Imgur](https://i.imgur.com/DUsFpSA.png)
+
+Imagine a situation where a user adds two conflicting transactions in different areas of the tangle (“w” and “y”). Subsequent users might only have one of these conflicting transactions in their validation path (based on their tip selection and maybe due to propagation delays). For example, the users attaching transactions “1” and “2” will not see the conflict and confirm their chosen tips. Hence, the double spend attempt got its first confirmations. However, sooner or later it must happen, that both conflicting transactions are in the path of validation of one transaction. For example, transaction “5” would see the conflict and not attach to the elected tips. Instead it would reselect tips until it found to not conflicting ones in order to be sure itself turns into a valid transaction.
+
+Depending on the tip selection and tangle progress, it might happen that many more users attach their transactions behind “w” OR “y”, before the conflict becomes clear. Depending on where users attached most new transactions, either “w” or “y” will confirm at some point, while the other gets abandoned. All subsequent transactions attached to the abandoned one (as they couldn’t see the conflict coming) will also be abandoned. However, they are not lost but can be taken by anybody (but most likely the payment recipient) and reattached to the tangle for a new chance of confirmation. The PoW would need to be redone, but no fresh signatures from the sender are required.
+
+
+
+## 解决双花
+
+![Imgur](https://i.imgur.com/pbOjVu1.png)
+
+In the previous slide a user tried to connect a transaction “5” to the tips “1” and “2”. Due to a conflict it retried the tip selection, and decided to attach to tips “1” and “4”. Another user (or maybe the same one) chose tips “2” and “3” to attach transaction “7”.  Some kind of branches emerged, but only one can survive, due to the double spend in “w” and “y”. Based on the random selection of tips (and the cumulative weight of the transactions), one of the two branches will receive more child transactions (respectively, weight) until the tangle turns into a state where it is not possible to attach legitimately to one of the segments anymore. In the sample above users could just continue attaching to transactions “5”, “6” and “8” but not to transaction “7” anymore. Hence, transactions “y”, “2”, “3” and “7” will never make it into a fully confirmed state.
+
+As described in the previous slide, transactions “y”, “2”, “3” and “7” could be reattached to the tangle again. As long as they are (still) valid, they have a fresh chance of confirmation. Transactions “2”, “3” and “7” might become confirmed then, while transaction “y” will stay invalid.
+
+
+
+## 离线 Tangle
+
+![Imgur](https://i.imgur.com/C0zaub3.png)
+
+The tangle allows users to continue building transactions while they are offline (e.g. within a company intranet environment, or to continue interacting with neighbors during an Internet outage). To do so, transactions are created and connected to each other as described by the protocol. 
+
+In the sample above, transactions “1” and “2” are the first offline ones. They are connected to the last known tips of the online tangle. Subsequent transactions attach as usual. Once a commit to the main tangle is desired (or possible, in case of an Internet outage), the offline sub tangle is finalized by creating transaction “8”, which is merging the offline tangle with a recent tip of the online tangle. Subsequently, transaction “8” turns into a legit tip and can be selected and validated by later online transactions. The next users attaching to transaction “8” online will include all offline transaction in their validation routine.
+
+Please note, that offline transactions can only become fully confirmed once they made it into the main tangle like any other transaction, just as shown on the previous slides. If any transaction within the offline branch was conflicting with the main tangle, the transactions “1” to “8” would not become confirmed. Again it might take some subsequent transactions until the conflict is visible from all (or the majority) of the main tangle’s tips (as described in slide 8 “Double Spend”).
+
+
+
+

content/misc/articles.md

@@ -0,0 +1,7 @@
+
+- [Fundamental challenges with public blockchains](https://medium.com/@preethikasireddy/fundamental-challenges-with-public-blockchains-253c800e9428)
+- [](https://hackernoon.com/ten-years-in-nobody-has-come-up-with-a-use-case-for-blockchain-ee98c180100)
+
+- [从分布式计算的角度看区块链](http://cs.brown.edu/courses/csci2952-a/papers/perspective.pdf)
+
+- [](https://medium.com/@gustav.simonsson/ethereum-probabilistic-micropayments-ae6e6cd85a06)

content/misc/on-public-and-private-blockchains.md

@@ -0,0 +1,25 @@
+什么是公有链、私有链
+====================
+
+>原文: [On Public and Private Blockchains](https://blog.ethereum.org/2015/08/07/on-public-and-private-blockchains/)
+
+## 公有链（Public blockchain）
+
+任何人都可读，任何人都可以发送交易，任何人都可以参与**共识过程（consensus process）**。所谓共识，就是决定将哪个块加入到区块链，决定当前状态。与中心化或类中心化信任不同，公有链由密码学和经济学保障安全，即将经济激励和使用像 PoW 或 PoS 等机制的密码学验证组合到一起。对于共识过程有个基本原则，简单来说，就是谁有多少经济资源，谁就能对共识过程产生多大的影响。所谓经济资源，PoW 就是算力，PoS 就是代币。这样的区块链，就可以认为是“完全去中心化的”区块链。
+
+## 联盟链（Consortium blockchain）
+
+如果一个区块链能够参与共识的节点是预先选定的，那么就是联盟链。比如一个有着 15 个金融机构的联盟，每个机构维护一个节点，只有至少其中 10 个节点按照顺序签名过的块，才是有效区块。可能所有人都可以读取，也可能只有部分人有读取权限，也可以采用混合方式，比如利用一个开放的 API 进行有限次数的查询。这样的区块链，就可以认为是“部分去中心化的”区块链。
+
+## 私有链（Private blockchain）
+
+如果一个区块链的写入权限由一个组织完全控制，那么这就是私有链。私有链的读取权限可以是公开的，也可以施加任意程度的限制。由于像数据库管理，审计等等应用都是属于公司内部事务，所以很多时候，公开可读其实也并非必要。
+
+私有链，准确来说，就是一个传统的中心化系统附加某种程度的密码学审计功能。
+
+私有链与公有链，各有其长处与短处。
+
+私有链的优势有：
+
+1. 可以很容易地修改区块链的规则，回滚交易，修改余额等等。
+2. 验证人已知，所以不会出现中国矿工共谋的 51% 攻击。

content/orchid/orchidprotocol-whitepaper.md

@@ -0,0 +1,4 @@
+兰花协议
+========
+
+>白皮书：[Orchid: Enabling Decentralized Network Formation and Probabilistic Micro-Payments](https://orchidprotocol.com/whitepaper.pdf)

part-5/address.md → content/part-5/address.md

@@ -104,3 +104,15 @@ Version  Public key hash                           Checksum
 由于哈希函数是单向的（也就说无法逆转回去），所以不可能从一个哈希中提取公钥。不过通过执行哈希函数并进行哈希比较，我们可以检查一个公钥是否被用于哈希的生成。
 
 好了，所有细节都已就绪，来写代码吧。很多概念只有当写代码的时候，才能理解地更透彻。
+
+## 私钥和公钥
+
+ECDSA(Elliptic Curve Digital Signature Algorithm)，椭圆曲线数字签名算法将签名与验证进行了分离。
+
+$$
+y^2 = x^3 + ax + b
+$$
+
+异点相加和同点加倍
+
+[比特币背后的数学](https://mp.weixin.qq.com/s/MigSmfzRfyw-ux1lm0iBhw)

styles/website.css

@@ -0,0 +1,3 @@
+h1, h2 {
+    border-bottom: 1px solid #EFEAEA;
+}