-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathprint.html
2536 lines (2464 loc) · 160 KB
/
print.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML>
<html lang="en">
<head>
<meta charset="UTF-8">
<title></title>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<meta name="description" content="">
<meta name="viewport" content="width=device-width, initial-scale=1">
<base href="">
<link rel="stylesheet" href="book.css">
<link href="https://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,800italic,400,300,600,700,800" rel="stylesheet" type="text/css">
<link href="https://fonts.googleapis.com/css?family=Source+Code+Pro:500" rel="stylesheet" type="text/css">
<link rel="shortcut icon" href="favicon.png">
<!-- Font Awesome -->
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css">
<link rel="stylesheet" href="highlight.css">
<link rel="stylesheet" href="tomorrow-night.css">
<link rel="stylesheet" href="ayu-highlight.css">
<!-- Custom theme -->
<!-- MathJax -->
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
<!-- Fetch Clipboard.js from CDN but have a local fallback -->
<script src="https://cdn.jsdelivr.net/clipboard.js/1.6.1/clipboard.min.js"></script>
<script>
if (typeof Clipboard == 'undefined') {
document.write(unescape("%3Cscript src='clipboard.min.js'%3E%3C/script%3E"));
}
</script>
<!-- Fetch JQuery from CDN but have a local fallback -->
<script src="https://code.jquery.com/jquery-2.1.4.min.js"></script>
<script>
if (typeof jQuery == 'undefined') {
document.write(unescape("%3Cscript src='jquery.js'%3E%3C/script%3E"));
}
</script>
<!-- Fetch store.js from local - TODO add CDN when 2.x.x is available on cdnjs -->
<script src="store.js"></script>
</head>
<body class="light">
<!-- Set the theme before any content is loaded, prevents flash -->
<script type="text/javascript">
var theme = store.get('mdbook-theme');
if (theme === null || theme === undefined) { theme = 'light'; }
$('body').removeClass().addClass(theme);
</script>
<!-- Hide / unhide sidebar before it is displayed -->
<script type="text/javascript">
var sidebar = store.get('mdbook-sidebar');
if (sidebar === "hidden") { $("html").addClass("sidebar-hidden") }
else if (sidebar === "visible") { $("html").addClass("sidebar-visible") }
</script>
<div id="sidebar" class="sidebar">
<ul class="chapter"><li><a href="./Intro.html"><strong>1.</strong> Intro</a></li><li><a href="./DagHistory.html"><strong>2.</strong> History</a></li><li><a href="./Wallet.html"><strong>3.</strong> Wallet</a></li><li><ul class="section"><li><a href="./Deterministic_wallet.html"><strong>3.1.</strong> Deterministic Wallet</a></li><li><a href="./Mnemonic.html"><strong>3.2.</strong> Mnemonic</a></li></ul></li><li><a href="./Testnet.html"><strong>4.</strong> Testnet & faucet</a></li><li><ul class="section"><li><a href="./BTC_testnet.html"><strong>4.1.</strong> Bitcoin Testnet</a></li><li><a href="./ETH_testnet.html"><strong>4.2.</strong> Ethereum Testnet</a></li><li><a href="./GByte_testnet.html"><strong>4.3.</strong> Byteball Testnet</a></li></ul></li><li><a href="./Address.html"><strong>5.</strong> Address</a></li><li><ul class="section"><li><a href="./btc_addr.html"><strong>5.1.</strong> Bitcoin Address</a></li></ul></li><li><a href="./Data_Structure.html"><strong>6.</strong> Data Structure</a></li><li><ul class="section"><li><a href="./Transcation.html"><strong>6.1.</strong> Transcation</a></li><li><a href="./btc_tx.html"><strong>6.2.</strong> Bitcoin Transaction</a></li><li><a href="./MerkleTree.html"><strong>6.3.</strong> MerkleTree</a></li><li><a href="./PatriciaTree.html"><strong>6.4.</strong> PatriciaTree</a></li><li><a href="./IAVL_Tree.html"><strong>6.5.</strong> Merkleized IAVL+ Tree</a></li><li><a href="./MerkleDAG.html"><strong>6.6.</strong> MerkleDAG</a></li></ul></li><li><a href="./Data_Storage.html"><strong>7.</strong> Data Storage</a></li><li><ul class="section"><li><a href="./btc_datastore.html"><strong>7.1.</strong> Bitcoin</a></li></ul></li><li><a href="./Consensus.html"><strong>8.</strong> Consensus algorithm</a></li><li><ul class="section"><li><a href="./Consensus_POS_Ouroboros.html"><strong>8.1.</strong> IOHK/Ouroboros</a></li><li><a href="./DFINITY.html"><strong>8.2.</strong> DFINITY</a></li><li><a href="./Stellar.html"><strong>8.3.</strong> Stellar(SCP)</a></li><li><a href="./Matrix.html"><strong>8.4.</strong> Matrix</a></li><li><a href="./Ripple.html"><strong>8.5.</strong> Ripple</a></li><li><a href="./Casper.html"><strong>8.6.</strong> Casper</a></li><li><a href="./PoA.html"><strong>8.7.</strong> POA(Parity)</a></li><li><a href="./Terndermint.html"><strong>8.8.</strong> Tendermint</a></li><li><a href="./Delegated_Consensus.html"><strong>8.9.</strong> dBFT(NEO/Antshare)/dPOS(BTS/Steem/EOS/Lisk)</a></li><li><a href="./Algorand.html"><strong>8.10.</strong> Algorand</a></li></ul></li><li><a href="./Scalability.html"><strong>9.</strong> Scalability</a></li><li><ul class="section"><li><a href="./Ouroboros_Praos.html"><strong>9.1.</strong> Ouroboros Praos</a></li><li><a href="./EOS.html"><strong>9.2.</strong> EOS</a></li><li><a href="./eth_parallelizability.html"><strong>9.3.</strong> Ethereum Parallelizability</a></li></ul></li><li><a href="./Validation.html"><strong>10.</strong> Validation</a></li><li><ul class="section"><li><a href="./Segwit.html"><strong>10.1.</strong> Segwit</a></li><li><a href="./Multisignature.html"><strong>10.2.</strong> Multisignature</a></li><li><a href="./Tx_Malleability.html"><strong>10.3.</strong> Transaction Malleability</a></li><li><a href="./Double_Spend.html"><strong>10.4.</strong> Double Spend</a></li><li><a href="./Peplay_Protect.html"><strong>10.5.</strong> Replay Protection</a></li><li><a href="./TrueBit.html"><strong>10.6.</strong> Truebit</a></li></ul></li><li><a href="./Money_Denomiation_Token.html"><strong>11.</strong> Money & Token</a></li><li><ul class="section"><li><a href="./TxFee_BTC.html"><strong>11.1.</strong> Bitcoin TxFee</a></li><li><a href="./RBF.html"><strong>11.2.</strong> Bitcoin Replace by fee</a></li><li><a href="./TxFee_ETH.html"><strong>11.3.</strong> Ethereum TxFee</a></li><li><a href="./ERC20.html"><strong>11.4.</strong> ERC20/ERC223/ERC721</a></li></ul></li><li><a href="./Crypto.html"><strong>12.</strong> Crypto Algorithm</a></li><li><ul class="section"><li><a href="./secp256k1.html"><strong>12.1.</strong> secp256k1</a></li><li><a href="./ZK-SNARKs.html"><strong>12.2.</strong> ZKP/ZK-SNARKs</a></li><li><a href="./CoinJoin.html"><strong>12.3.</strong> CoinJoin</a></li><li><a href="./RingSig.html"><strong>12.4.</strong> RingSig</a></li><li><a href="./Crypto_SM.html"><strong>12.5.</strong> SMx</a></li><li><a href="./PQC.html"><strong>12.6.</strong> Post-Quantum Cryptography</a></li></ul></li><li><a href="./Messaging.html"><strong>13.</strong> Messaging</a></li><li><a href="./Node_Discovery.html"><strong>14.</strong> Node discovery</a></li><li><ul class="section"><li><a href="./Gossip_Protocol.html"><strong>14.1.</strong> Gossip Protocol</a></li><li><a href="./DHT_Protocol.html"><strong>14.2.</strong> DHT Protocol</a></li></ul></li><li><a href="./Sync.html"><strong>15.</strong> Synchronization</a></li><li><ul class="section"><li><a href="./btc_sync.html"><strong>15.1.</strong> Bitcoin Header frist</a></li></ul></li><li><a href="./Interconnecting.html"><strong>16.</strong> Interconnect & Cross-chain</a></li><li><ul class="section"><li><a href="./ILP.html"><strong>16.1.</strong> Interledger Protocol (ILP)</a></li><li><a href="./DID.html"><strong>16.2.</strong> Decentralized Identifiers (DIDs)</a></li><li><a href="./0xProtocol.html"><strong>16.3.</strong> 0x Protocol</a></li><li><a href="./Polkadot.html"><strong>16.4.</strong> Polkadot</a></li><li><a href="./Cosmos.html"><strong>16.5.</strong> Cosmos</a></li><li><a href="./OmiseGO.html"><strong>16.6.</strong> OmiseGO</a></li></ul></li><li><a href="./Oracle.html"><strong>17.</strong> Oracle</a></li><li><ul class="section"><li><a href="./Gnosis.html"><strong>17.1.</strong> Gnosis</a></li><li><a href="./Augur.html"><strong>17.2.</strong> Augur</a></li><li><a href="./Amoveo.html"><strong>17.3.</strong> Amoveo</a></li><li><a href="./ZenProtocol.html"><strong>17.4.</strong> Zen Protocal</a></li></ul></li><li><a href="./SmartContract.html"><strong>18.</strong> SmartContract</a></li><li><ul class="section"><li><a href="./Asset_Contract.html"><strong>18.1.</strong> Asset</a></li><li><a href="./Loan_Contract.html"><strong>18.2.</strong> Loan</a></li></ul></li><li><a href="./VM.html"><strong>19.</strong> VM</a></li></ul>
</div>
<div id="page-wrapper" class="page-wrapper">
<div class="page" tabindex="-1">
<div id="menu-bar" class="menu-bar">
<div class="left-buttons">
<i id="sidebar-toggle" class="fa fa-bars" title="Toggle sidebar"></i>
<i id="theme-toggle" class="fa fa-paint-brush" title="Change theme"></i>
</div>
<h1 class="menu-title"></h1>
<div class="right-buttons">
<a href="print.html">
<i id="print-button" class="fa fa-print" title="Print this book"></i>
</a>
</div>
</div>
<div id="content" class="content">
<a class="header" href="print.html#dag简介" id="dag简介"><h3>DAG简介</h3></a>
<p>基于DAG技术的分布式账本(distributed ledger)系统与比特币（bitcion），以太坊（ethereum）等主流数字货币系统和传统区块链（blockchain）系统不同。其特色是使用DAG（Directed Acyclic Graph，有向无环图）来组织交易（transaction）。</p>
<p>传统的区块链技术，以比特币为例，使用的基本方式是矿工通过POW（工作量证明）共识，(即网络认为最⻓的链为真实链，因为最⻓的链拥有最大的工作量证明)，将交易打包到区块（block）中，而每一个区块通过在区块头记录前一个区块的hash值来链接到前一个区块上。通过这种方式，后一个区块直接或者间接的确认了前面所有区块的交易，这样通过POW共识解决了双花问题。</p>
<p>与基于区块链的传统分布式账本技术（基于POW和单链式数据结构）不同，基于DAG技术的分布式账本技术，去掉了区块的限制，通过有向无环图的数据结构，允许后一交易同时连接到多个父亲交易，将交易通过有向图的方式直接连接在一起。
在DAG中，交易构成了图中所有的节点。而带有方向的图的边(edge)表达了交易之间的先后确认关系。箭头由子节点指向父节点，表示了子交易直接或间接地确认了父交易的这种关系，同时也说明了子交易和父交易确认的先后顺序，即子交易一定被确认在父交易之后。这种父子关系是DAG确认机制和抵抗双花的核心。当一个交易产生时，该新产生的交易需要选取某些当前待确实交易来作为该交易的父交易(一个子交易可以有多个父交易)。子交易总是希望连接到包含更多的先辈节点的父交易上。对于一个新交易，在可选有限个父交易的情况下，为了直接或者间接的确认更多的祖先节点，子交易总是试图连接无孩交易(即tips)做为他的父交易，这样使得DAG的方向性得以建立。</p>
<a class="header" href="print.html#dag技术的优势" id="dag技术的优势"><h3>DAG技术的优势</h3></a>
<ul>
<li>DAG技术对于高并发具有先天的优势。</li>
<li>DAG技术交易确认快，网络可实现即时确认的。不需要向比特币那样需要等待10分钟左右的出块时间，或者像以太坊那样等待15到16秒。</li>
<li>DAG技术不受区块大小的限制，不存在区块扩容问题。所以其可伸缩性只取决于网络带宽，CPU处理速度(例 如数字签名加密算法的处理速度)和存储容量的限制。</li>
</ul>
<a class="header" href="print.html#dag技术的难点" id="dag技术的难点"><h3>DAG技术的难点</h3></a>
<ul>
<li>由于DAG技术这种允许先连接，再判断的方式，对于双花处理则需要更加复杂的设计，从而解决基于DAG的双花问题，这就给如何实现基于DAG技术的区块链系统带来了很多复杂性，这也是目前基于DAG系统的区块链系统还极为少⻅的原因。</li>
<li>目前还没有完美的基于DAG技术的分布式共识算法。</li>
<li>技术还不够成熟，市场接受程度低。</li>
</ul>
<a class="header" href="print.html#dag技术的未来" id="dag技术的未来"><h3>DAG技术的未来</h3></a>
<ul>
<li>DAG技术将是未来区块链和分布式账本技术发展的一种核心趋势。（如Spectre协议和以太的Casper协议）</li>
<li>基于DAG技术的分布式账本技术有可能广泛的应用于金融交易系统和企业资产管理系统中。（如Ripple，Corda，hyperledger等系统的有力竞争者）</li>
<li>基于DAG技术的智能合约能有效解决智能合约的可扩展性（scalability），并且降低合约执行成本。</li>
</ul>
<a class="header" href="print.html#注释" id="注释"><h3>注释</h3></a>
<ul>
<li>目前比特币的区块容量是1M，实际情况约能容纳2000多个交易。而以太坊区块大约能容纳200多个交易。比特币社区因为扩容问题带来的争议而严重影响了客戶体验，使得比特币的发展陷入一个瓶颈。同时以太坊试图以分片(sharding)的方式解决扩容的问题，但分片的方式将增加跨区智能合约的事务复杂度，对如何实现分片和分片环境下智能合约的开发都带来很多新的挑战，是否可以解决问题还有待时间去验证。</li>
<li>目前世界上主要有两个有名项目使用DAG技术：IOTA 项目和字节雪球(byteball)项目。相信未来有更多的项目使用DAG技术。</li>
</ul>
<a class="header" href="print.html#dag技术发展历史" id="dag技术发展历史"><h1>DAG技术发展历史</h1></a>
<ul>
<li>DAG数据结构 (?)
<ul>
<li>https://en.wikipedia.org/wiki/Directed_acyclic_graph</li>
</ul>
</li>
<li>lamport lock and partital order (1978)
<ul>
<li>https://lamport.azurewebsites.net/pubs/pubs.html#time-clocks</li>
</ul>
</li>
<li>Git (2005, Linus Torvalds)</li>
<li>Ghost (2013) (Yonatan Sompolinsky and Aviv Zohar -> see Spectre&Daglab)
<ul>
<li>https://eprint.iacr.org/2013/881.pdf</li>
<li>Ethereum (2014)</li>
</ul>
</li>
<li>NXT (2014,mthcl,Come-from-Beyond)
<ul>
<li>https://nxtforum.org/proof-of-stake-algorithm/dag-a-generalized-blockchain/?all</li>
<li>mtchl -> Serguei Popov (founder of IOTA)</li>
<li>cfb -> Sergey Ivancheglo (founder of IOTA)</li>
</ul>
</li>
<li>IPFS (2014,Juan Bennet)
<ul>
<li>Git+Merkle -> Merkle DAG</li>
<li>https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf</li>
<li>https://github.com/ipfs/ipfs/issues/1</li>
</ul>
</li>
<li>dagcoin (2015, Sergio Demian Lerner, chief scientist of RSK)
<ul>
<li>https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf</li>
</ul>
</li>
<li>Triangle/JINN -> IOTA (2015)
<ul>
<li>https://nxtforum.org/news-and-announcements/iota-jinn/?all</li>
</ul>
</li>
<li>Bytball (2016, Anton Churyumov)
<ul>
<li>https://byteball.org/Byteball.pdf</li>
</ul>
</li>
<li>HashGraph (2016, Leemon Baird, co-founder and CTO of Swirlds)
<ul>
<li>The algorithm is protected by patents in the USA.)</li>
<li>http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf</li>
</ul>
</li>
<li>Spectre/daglab (2016~2017, Yonatan Sompolinsky, Yoad Lewenberg, and Aviv Zohar)
<ul>
<li>Yonatan Sompolinsky -> (PhD student at the Hebrew University, -> Computer Scientist at daglib)</li>
<li>Yoad Lewenberg -> PhD student at the Hebrew University -> Research Engineer at daglab</li>
<li>Aviv Zohar -> (Senior Lecturer (Assistant. Prof.) at The School of Engineering and Computer Science at The Hebrew University )</li>
<li>https://eprint.iacr.org/2016/1159.pdf</li>
<li>https://www.daglabs.com/</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#wallet" id="wallet"><h1>Wallet</h1></a>
<a class="header" href="print.html#intro" id="intro"><h3>Intro</h3></a>
<p>A deterministic wallet is a system of deriving keys from a single starting point known as a seed. The seed allows a user to easily back up and restore a wallet without needing any other information and can in some cases allow the creation of public addresses without the knowledge of the private key. Seeds are typically serialized into human-readable words in a Mnemonic phrase.</p>
<a class="header" href="print.html#how-mew-works-with-ledger" id="how-mew-works-with-ledger"><h3>How MEW works with Ledger</h3></a>
<ul>
<li>https://github.com/kvhnuke/etherwallet/blob/f8fdab1ea92d436015119e3c2ba865308289e88d/app/scripts/controllers/decryptWalletCtrl.js#L21</li>
<li>https://github.com/kvhnuke/etherwallet/blob/f8fdab1ea92d436015119e3c2ba865308289e88d/app/scripts/controllers/decryptWalletCtrl.js#L43</li>
<li>https://github.com/kvhnuke/etherwallet/blob/f54c093c1b1e230b60e238582f2765afd61b2a05/app/scripts/staticJS/ledger-eth.js#L76</li>
<li>https://github.com/kvhnuke/etherwallet/blob/f54c093c1b1e230b60e238582f2765afd61b2a05/app/scripts/staticJS/ledger-eth.js#L45</li>
<li>https://github.com/LedgerHQ/blue-app-eth/blob/cdc8c7436c76d7600d855f1411b5bc00e55980b7/src_genericwallet/main.c#L63
<code>0x02 -> INS_GET_PUBLIC_KEY</code></li>
<li>https://github.com/LedgerHQ/blue-app-eth/blob/cdc8c7436c76d7600d855f1411b5bc00e55980b7/src_genericwallet/main.c#L2153</li>
<li>https://github.com/LedgerHQ/blue-app-eth/blob/dca33eab262730e94353c9c6ea57027389bb03da/src_common/ethUtils.c#L177</li>
</ul>
<a class="header" href="print.html#how-mew-show-addresses" id="how-mew-show-addresses"><h4>How MEW show addresses</h4></a>
<p>以ledger为例，MEW了获取"m/44'/60'/0'"这个路径下的公钥，然后使用<code>hdkey</code>，得到5个derivedKey(m/0 ~m/4), 再使用<code>ethereumjs-util</code>生成了前五个地址。</p>
<ul>
<li>https://github.com/kvhnuke/etherwallet/blob/f8fdab1ea92d436015119e3c2ba865308289e88d/app/scripts/controllers/decryptWalletCtrl.js#L272
<code>result['publicKey'], result['chainCode']</code></li>
<li>https://github.com/kvhnuke/etherwallet/blob/f8fdab1ea92d436015119e3c2ba865308289e88d/app/scripts/controllers/decryptWalletCtrl.js#L267
注：hdk来自于<code>var HDKey = require('hdkey');</code>
<ul>
<li>https://github.com/cryptocoinjs/hdkey/blob/0.7.1/lib/hdkey.js#L13</li>
</ul>
</li>
<li>https://github.com/kvhnuke/etherwallet/blob/f8fdab1ea92d436015119e3c2ba865308289e88d/app/scripts/controllers/decryptWalletCtrl.js#L183</li>
<li>https://github.com/kvhnuke/etherwallet/blob/mercury/app/scripts/myetherwallet.js#L171
<ul>
<li>https://github.com/ethereumjs/ethereumjs-util/blob/v5.1.2/index.js#L287</li>
<li>https://github.com/ethereumjs/ethereumjs-util/blob/v5.1.2/index.js#L440</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#lets-see-electrum" id="lets-see-electrum"><h3>Let's see electrum</h3></a>
<ul>
<li>https://github.com/spesmilo/electrum/blob/3.0.1/lib/wallet.py#L1746</li>
<li>https://github.com/spesmilo/electrum/blob/3.0.1/lib/wallet.py#L93</li>
<li>https://github.com/spesmilo/electrum/blob/3.0.1/lib/wallet.py#L1645,L1655</li>
<li>https://github.com/spesmilo/electrum/blob/3.0.1/lib/wallet.py#L1638</li>
<li>https://github.com/spesmilo/electrum/blob/3.0.1/lib/keystore.py#L232</li>
<li>https://github.com/spesmilo/electrum/blob/3.0.1/lib/bitcoin.py#L1013</li>
<li>https://github.com/spesmilo/electrum/blob/3.0.1/lib/bitcoin.py#L878-L891</li>
<li>https://github.com/spesmilo/electrum/blob/3.0.1/lib/synchronizer.py</li>
</ul>
<a class="header" href="print.html#server-side" id="server-side"><h4>Server side</h4></a>
<ul>
<li>client side request address history
<ul>
<li>https://github.com/spesmilo/electrum/blob/3.0.1/lib/network.py#L640</li>
</ul>
</li>
<li>https://github.com/spesmilo/electrum-server/blob/master/src/blockchain_processor.py#L310</li>
<li>https://github.com/spesmilo/electrum-server/blob/master/src/storage.py#L309</li>
<li>https://github.com/spesmilo/electrum-server/blob/master/src/storage.py#L205</li>
</ul>
<p>注意electrum混合使用了自己的levelDB库和bitcoind，某些调用走bitcoind，而某些调用走自己的库，例如utxo，address等。electurm会在后台同步（catch_up）bitcoind的数据，从bitcoind中读取block，然后存放在自己的数据库里面。这是为了优化查询。</p>
<ul>
<li>https://github.com/spesmilo/electrum-server/blob/master/src/blockchain_processor.py#L608</li>
<li>https://github.com/spesmilo/electrum-server/blob/master/src/blockchain_processor.py#L407</li>
</ul>
<a class="header" href="print.html#account-discovery" id="account-discovery"><h4>Account discovery</h4></a>
<p>When the master seed is imported from an external source the software should
start to discover the accounts in the following manner:</p>
<ol>
<li>derive the first account's node (index = 0)</li>
<li>derive the external chain node of this account</li>
<li>scan addresses of the external chain; respect the gap limit described below</li>
<li>if no transactions are found on the external chain, stop discovery</li>
<li>if there are some transactions, increase the account index and go to step 1</li>
</ol>
<a class="header" href="print.html#references" id="references"><h3>References</h3></a>
<ul>
<li>BIPs
<ul>
<li>BIP39 : Mnemonic code for generating deterministic keys
<ul>
<li>https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki</li>
</ul>
</li>
<li>BIP32 : Hierarchical Deterministic Wallets
<ul>
<li>https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki</li>
</ul>
</li>
<li>BIP43/BIP44 : Multi-Account Hierarchy for Deterministic Wallets
<ul>
<li>https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki</li>
<li>https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki</li>
<li>https://github.com/satoshilabs/slips/blob/master/slip-0044.md</li>
</ul>
</li>
</ul>
</li>
<li>https://en.bitcoin.it/wiki/Deterministic_wallet</li>
<li>https://en.bitcoin.it/wiki/Deterministic_wallet_tools</li>
</ul>
<a class="header" href="print.html#bip39" id="bip39"><h3>BIP39</h3></a>
<ul>
<li>https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki</li>
<li>https://github.com/trezor/python-mnemonic/blob/master/mnemonic/wordlist/english.txt (2048)</li>
</ul>
<a class="header" href="print.html#pgp-worldlist" id="pgp-worldlist"><h3>PGP Worldlist</h3></a>
<ul>
<li>https://en.wikipedia.org/wiki/PGP_word_list</li>
<li>The Decred wallet seed is initialised with a 33 word selection from a 512 word dictionary, the PGP Word List.
BIP39 in comparison for 256 bits of entropy with 8 bits of checksum uses 24 words from a standardised 2048 word dictionary.</li>
<li>http://docs.electrum.org/en/latest/seedphrase.html</li>
<li>https://github.com/decred/dcrwallet/issues/956</li>
<li>https://github.com/decred/dcrwallet/blob/master/walletseed/seed.go</li>
<li>https://github.com/decred/dcrwallet/blob/master/pgpwordlist/pgpwordlist.go</li>
</ul>
<a class="header" href="print.html#testnet--faucet" id="testnet--faucet"><h1>Testnet & faucet</h1></a>
<a class="header" href="print.html#testnet5" id="testnet5"><h3>Testnet5</h3></a>
<ul>
<li>Testnet5 block explorer
<ul>
<li>https://testnet5.blockchain.info/</li>
</ul>
</li>
<li>Testnet5 faucet
<ul>
<li>http://li1164-223.members.linode.com/request</li>
<li>https://faucet.haskoin.com/</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#ropsten" id="ropsten"><h3>Ropsten</h3></a>
<ul>
<li>https://ropsten.etherscan.io</li>
<li>http://faucet.ropsten.be:3001</li>
<li>https://faucet.metamask.io/</li>
<li>https://www.rinkeby.io/#faucet</li>
</ul>
<a class="header" href="print.html#kovan" id="kovan"><h3>Kovan</h3></a>
<ul>
<li>https://github.com/kovan-testnet/proposal</li>
<li>http://kovan-stats.parity.io/</li>
<li>https://kovan.etherscan.io/</li>
<li>https://github.com/kovan-testnet/faucet
<ul>
<li>https://gitter.im/kovan-testnet/faucet</li>
<li>https://kovan.etherscan.io/tx/0x935f7e405c5f8f747c0f7cea71bb2f5102bb57c419377e6b2f80e85974307190</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#oraclesorg" id="oraclesorg"><h3>Oracles.org</h3></a>
<ul>
<li>http://testnet.oracles.org:4000/</li>
<li>http://oraclesfaucet.herokuapp.com/
<ul>
<li>http://testnet.oracles.org:4000/tx/0x52126c5841c86d055a2c24d0455653dfa786b531307ed9fc03f2ebe432787d96</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#byteball-testnet" id="byteball-testnet"><h1>Byteball Testnet</h1></a>
<a class="header" href="print.html#address" id="address"><h1>Address</h1></a>
<a class="header" href="print.html#base58-encoding" id="base58-encoding"><h3>Base58 encoding</h3></a>
<a class="header" href="print.html#reference" id="reference"><h3>Reference</h3></a>
<ul>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki">BIP13 : Address Format for pay-to-script-hash</a>
<ul>
<li><a href="https://en.bitcoin.it/wiki/Base58Check_encoding">Base58Check encoding</a></li>
</ul>
</li>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki">BIP142: Address Format for Segregated Witness</a></li>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki">BIP173: Base32 address format for native v0-16 witness outputs</a>
<ul>
<li><a href="https://rusty.ozlabs.org/?p=578">Bitcoin Generic Address Format Proposal</a></li>
<li><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-February/004402.html">Base-32 error correction coding</a></li>
</ul>
</li>
</ul>
<a class="header" href="print.html#dag数据结构与算法" id="dag数据结构与算法"><h3>DAG数据结构与算法</h3></a>
<a class="header" href="print.html#深度优先广度优先-breadth-first-vs-depth-first-search" id="深度优先广度优先-breadth-first-vs-depth-first-search"><h4>深度优先&广度优先 （Breadth-First Vs. Depth-first Search）</h4></a>
<p><img src="https://user-images.githubusercontent.com/1134993/32087906-dfda6218-baa4-11e7-8411-b31baef1808e.png" alt="screen shot 2017-10-27 at 12 24 10 pm" /></p>
<a class="header" href="print.html#dags-and-topological-ordering" id="dags-and-topological-ordering"><h4>DAGs and Topological Ordering</h4></a>
<p><img src="https://user-images.githubusercontent.com/1134993/32088033-e2b5d46c-baa5-11e7-9cc4-36b017161e5e.png" alt="screen shot 2017-10-27 at 12 30 38 pm" /></p>
<ul>
<li>
<p>The reachability relation in a DAG forms a partial order, and any finite partial order may be represented by a DAG using reachability.</p>
</li>
<li>
<p>The reachability relationship in any directed acyclic graph can be formalized as a partial order ≤ on the vertices of the DAG. In this partial order, two vertices u and v are ordered as u ≤ v exactly when there exists a directed path from u to v in the DAG; that is, when v is reachable from u.[5] However, different DAGs may give rise to the same reachability relation and the same partial order.[6] For example, the DAG with two edges a → b and b → c has the same reachability relation as the graph with three edges a → b, b → c, and a → c. Both of these DAGS produce the same partial order, in which the vertices are ordered as a ≤ b ≤ c.</p>
</li>
<li>
<p>Every directed acyclic graph has a topological ordering, an ordering of the vertices such that the starting endpoint of every edge occurs earlier in the ordering than the ending endpoint of the edge. The existence of such an ordering can be used to characterize DAGs: a directed graph is a DAG if and only if it has a topological ordering. In general, this ordering is not unique; a DAG has a unique topological ordering if and only if it has a directed path containing all the vertices, in which case the ordering is the same as the order in which the vertices appear in the path.[9]</p>
</li>
<li>
<p>The family of topological orderings of a DAG is the same as the family of linear extensions of the reachability relation for the DAG,[10] so any two graphs representing the same partial order have the same set of topological orders.</p>
</li>
</ul>
<blockquote>
<p>Steven S Skiena. <em>The Algorithm Design Manual</em></p>
<p>Three important facts about topological sorting are</p>
<ol>
<li>Only DAGs can be topologically sorted, since any directed cycle provides an inherent contradiction to a linear order of tasks.</li>
<li>Every DAG can be topologically sorted, so there must always be at least one schedule for any reasonable precedence constraints among jobs.</li>
<li>DAGs can often be topologically sorted in many different ways, especially when there are few constraints. Consider n unconstrained jobs. Any of the n! permutations of the jobs constitutes a valid topological ordering.</li>
</ol>
</blockquote>
<a class="header" href="print.html#references-1" id="references-1"><h3>References</h3></a>
<ul>
<li>https://en.wikipedia.org/wiki/Directed_acyclic_graph</li>
<li>http://www3.cs.stonybrook.edu/~algorith/files/topological-sorting.shtml</li>
<li>https://github.com/jgrapht/jgrapht/blob/master/jgrapht-core/src/main/java/org/jgrapht/traverse/TopologicalOrderIterator.java
<ul>
<li>https://github.com/jgrapht/jgrapht/wiki/DependencyDemo</li>
</ul>
</li>
<li><a href="https://www.cs.auckland.ac.nz/courses/compsci220s1c/lectures/2016S1C/CS220-Lectures21-23.pdf">Graphs and Digraphs BFS Priority search DAG Connectivity</a></li>
<li>https://homes.cs.washington.edu/~jrl/421slides/lec5.pdf</li>
</ul>
<a class="header" href="print.html#intro-1" id="intro-1"><h3>Intro</h3></a>
<ul>
<li>Ripple</li>
<li>Corda</li>
<li>Cosmos</li>
<li>Hyperledger</li>
</ul>
<a class="header" href="print.html#references-2" id="references-2"><h3>References</h3></a>
<ul>
<li>https://ripple.com/build/transactions/</li>
<li>https://cosmos.network/whitepaper#transaction-types</li>
<li>https://docs.corda.net/tutorial-building-transactions.html</li>
</ul>
<a class="header" href="print.html#reference-1" id="reference-1"><h3>Reference</h3></a>
<ul>
<li>http://learnmeabitcoin.com/glossary/transaction-data</li>
<li>http://royalforkblog.github.io/2014/11/20/txn-demo/</li>
<li>https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc</li>
</ul>
<a class="header" href="print.html#index-stored-in-leveldb" id="index-stored-in-leveldb"><h3>Index stored in LevelDB</h3></a>
<a class="header" href="print.html#block-index" id="block-index"><h4>Block Index</h4></a>
<pre><code>'b' + 32-byte block hash -> block index record. :
The block header.
The height.
The number of transactions.
To what extent this block is validated.
In which file, and where in that file, the block data is stored.
In which file, and where in that file, the undo data is stored.
'f' + 4-byte file number -> file information record.
The number of blocks stored in the block file with that number.
The size of the block file with that number ($DATADIR/blocks/blkNNNNN.dat).
The size of the undo file with that number ($DATADIR/blocks/revNNNNN.dat).
The lowest and highest height of blocks stored in the block file with that number.
The lowest and highest timestamp of blocks stored in the block file with that number.
'l' -> 4-byte file number: the last block file number used.
'R' -> 1-byte boolean ('1' if true): whether we're in the process of reindexing.
'F' + 1-byte flag name length + flag name string -> 1 byte boolean ('1' if true, '0' if false): various flags that can be on or off. Currently defined flags include:
'txindex': Whether the transaction index is enabled.
't' + 32-byte transaction hash -> transaction index record. These are optional and only exist if 'txindex' is enabled (see above). :
Which block file number the transaction is stored in.
Which offset into that file the block the transaction is part of is stored at.
The offset from the start of that block to the position where that transaction itself is stored.
</code></pre>
<a class="header" href="print.html#chain-state" id="chain-state"><h4>chain state</h4></a>
<p>https://github.com/bitcoin/bitcoin/blob/d4a42334d447cad48fb3996cad0fd5c945b75571/src/coins.h#L21L69</p>
<pre><code>'c' + 32-byte transaction hash -> unspent transaction output record for that transaction.
These records are only present for transactions that have at least one unspent output left.:
The version of the transaction.
Whether the transaction was a coinbase or not.
Which height block contains the transaction.
Which outputs of that transaction are unspent.
The scriptPubKey and amount for those unspent outputs.
'B' -> 32-byte block hash: the block hash up to which the database represents the unspent transaction outputs.
</code></pre>
<a class="header" href="print.html#rfc" id="rfc"><h3>RFC</h3></a>
<ul>
<li>rfc6962
<ul>
<li>https://tools.ietf.org/html/rfc6962#page-4</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#mtree-in-bitcion" id="mtree-in-bitcion"><h3>MTree in Bitcion</h3></a>
<a class="header" href="print.html#mtree-in-ethereum" id="mtree-in-ethereum"><h3>MTree in Ethereum</h3></a>
<a class="header" href="print.html#mtree-in-corda" id="mtree-in-corda"><h3>MTree in Corda</h3></a>
<ul>
<li>https://github.com/corda/corda/blob/master/core/src/main/kotlin/net/corda/core/crypto/PartialMerkleTree.kt
<ul>
<li>https://github.com/corda/corda/blob/master/core/src/main/kotlin/net/corda/core/crypto/MerkleTree.kt</li>
</ul>
</li>
<li>https://github.com/corda/corda/blob/master/core/src/test/kotlin/net/corda/core/crypto/PartialMerkleTreeTest.kt
<ul>
<li>https://docs.corda.net/releases/release-M10.1/merkle-trees.html</li>
<li>https://docs.corda.net/releases/release-M10.1/oracles.html</li>
</ul>
</li>
<li>https://github.com/corda/corda/blob/master/core/src/main/kotlin/net/corda/core/transactions/MerkleTransaction.kt
<ul>
<li>https://github.com/corda/corda/blob/master/core/src/main/kotlin/net/corda/core/transactions/WireTransaction.kt</li>
</ul>
</li>
<li>https://github.com/corda/corda/blob/master/core/src/test/kotlin/net/corda/core/transactions/CompatibleTransactionTests.kt
<ul>
<li>https://docs.corda.net/head/tutorial-tear-offs.html</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#reference-2" id="reference-2"><h3>Reference</h3></a>
<a class="header" href="print.html#intro-2" id="intro-2"><h3>Intro</h3></a>
<blockquote>
<p>by G.W at <a href="https://www.youtube.com/watch?v=o6D8Up411dI&t=1016s">The future of Ethereum: "DΞV and Beyond", London ethereum meetup</a></p>
</blockquote>
<ul>
<li>Ethereum state is just the state of a number of accounts</li>
<li>Tx is the way to alter the state</li>
</ul>
<a class="header" href="print.html#references-3" id="references-3"><h3>References</h3></a>
<ul>
<li>https://github.com/ethereum/wiki/wiki/Patricia-Tree</li>
<li>https://crypto.stanford.edu/cs251/hw/hw3.pdf</li>
<li>https://github.com/ethereum/wiki/wiki/RLP</li>
<li>https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/</li>
<li>http://hidskes.com/blog/2014/04/02/ethereum-building-blocks-part-1-rlp/</li>
</ul>
<p><img src="https://user-images.githubusercontent.com/1134993/32094154-7002a21e-bac4-11e7-9f33-e605b6ab6112.png" alt="screen shot 2017-10-27 at 4 10 24 pm" /></p>
<a class="header" href="print.html#intro-3" id="intro-3"><h3>Intro</h3></a>
<p>The purpose of the IAVL+ data structure is to provide persistent storage for key-value pairs in the application state such that a deterministic Merkle root hash can be computed efficiently. The tree is balanced using a variant of the AVL algorithm, and all operations are O(log(n)).</p>
<p>In an AVL tree, the heights of the two child subtrees of any node differ by at most one. Whenever this condition is violated upon an update, the tree is rebalanced by creating O(log(n)) new nodes that point to unmodified nodes of the old tree. In the original AVL algorithm, inner nodes can also hold key-value pairs. The AVL+ algorithm (note the plus) modifies the AVL algorithm to keep all values on leaf nodes, while only using branch-nodes to store keys. This simplifies the algorithm while keeping the merkle hash trail short.</p>
<p>The AVL+ Tree is analogous to Ethereum’s Patricia tries. There are tradeoffs. Keys do not need to be hashed prior to insertion in IAVL+ trees, so this provides faster ordered iteration in the key space which may benefit some applications. The logic is simpler to implement, requiring only two types of nodes – inner nodes and leaf nodes. The Merkle proof is on average shorter, being a balanced binary tree. On the other hand, the Merkle root of an IAVL+ tree depends on the order of updates.</p>
<a class="header" href="print.html#references-4" id="references-4"><h3>References</h3></a>
<ul>
<li>https://github.com/tendermint/merkleeyes</li>
<li>https://cosmos.network/whitepaper#iavl-tree</li>
</ul>
<a class="header" href="print.html#ipfs的数据结构" id="ipfs的数据结构"><h2>IPFS的数据结构</h2></a>
<ul>
<li>merkleDAG
<ul>
<li>https://github.com/ipfs/go-ipfs/tree/master/merkledag</li>
<li>https://github.com/ipfs/go-ipfs/blob/master/core/commands/dag/dag.go</li>
<li>https://github.com/ipfs/go-ipfs/blob/master/core/coredag/dagtransl.go</li>
</ul>
</li>
<li>merkleDAG Doc
<ul>
<li>https://github.com/ipfs/specs/tree/master/merkledag</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#ipfs白皮书" id="ipfs白皮书"><h3>IPFS白皮书</h3></a>
<ul>
<li>http://decentralized.blog/understanding-the-ipfs-white-paper-part-1.html</li>
<li>http://decentralized.blog/understanding-the-ipfs-white-paper-part-2.html</li>
</ul>
<a class="header" href="print.html#data-storage" id="data-storage"><h1>Data Storage</h1></a>
<a class="header" href="print.html#intro-4" id="intro-4"><h3>Intro</h3></a>
<p>There are basically four pieces of data that are maintained:</p>
<ul>
<li><strong>blocks/blk*.dat:</strong> the actual Bitcoin blocks, in network format, dumped in raw on disk. They are only needed for rescanning missing transactions in a wallet, reorganizing to a different part of the chain, and serving the block data to other nodes that are synchronizing.</li>
<li><em><em>blocks/index/</em>:</em>* this is a LevelDB database that contains metadata about all known blocks, and where to find them on disk. Without this, finding a block would be very slow.</li>
<li><strong>chainstate/*:</strong> this is a LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the -reindex command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (140 GB as of july 2017) for every output being spent.</li>
<li><strong>blocks/rev*.dat:</strong> these contain "undo" data. You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganisations.
So yes, everything but the block data itself is indeed redundant, as it can be rebuilt from it. But validation and other operations would become intolerably slow without them.</li>
</ul>
<p><em>NOTE: <em><em>database/</em>:</em>* BDB database environment; only used for wallet since 0.8.0</em></p>
<a class="header" href="print.html#references-5" id="references-5"><h3>References</h3></a>
<ul>
<li>https://bitcoin.stackexchange.com/a/11108</li>
<li>https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage</li>
<li>https://github.com/bitcoin/bitcoin/blob/v0.15.0.1/doc/files.md</li>
</ul>
<pre><code>2017-11-04 05:15:09 Cache configuration:
2017-11-04 05:15:09 * Using 2.0MiB for block index database
2017-11-04 05:15:09 * Using 8.0MiB for chain state database
2017-11-04 05:15:09 * Using 440.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space)
2017-11-04 05:15:09 init message: Loading block index...
2017-11-04 05:15:09 Opening LevelDB in /work/_DATA/Bitcoin_test/1/blocks/index
2017-11-04 05:15:09 Opened LevelDB successfully
2017-11-04 05:15:09 Using obfuscation key for /work/_DATA/Bitcoin_test/1/blocks/index: 0000000000000000
2017-11-04 05:15:10 LoadBlockIndexDB: last block file = 0
2017-11-04 05:15:10 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=119836, size=133991641, heights=0...119835, time=2009-01-03...2011-04-23)
2017-11-04 05:15:10 Checking all blk files are present...
2017-11-04 05:15:10 LoadBlockIndexDB: transaction index disabled
2017-11-04 05:15:10 Opening LevelDB in /work/_DATA/Bitcoin_test/1/chainstate
2017-11-04 05:15:10 Opened LevelDB successfully
2017-11-04 05:15:10 Wrote new obfuscate key for /work/_DATA/Bitcoin_test/1/chainstate: cb7b45d88624f992
2017-11-04 05:15:10 Using obfuscation key for /work/_DATA/Bitcoin_test/1/chainstate: cb7b45d88624f992
</code></pre>
<p><code>heights=0...119835, time=2009-01-03...2011-04-23</code></p>
<a class="header" href="print.html#共识" id="共识"><h2>共识</h2></a>
<p>https://en.wikipedia.org/wiki/Consensus_(computer_science)</p>
<ul>
<li>对多件事件进行排序，并且得到大家认可。</li>
</ul>
<a class="header" href="print.html#lamport-clock-1978" id="lamport-clock-1978"><h3>Lamport Clock (1978)</h3></a>
<ul>
<li>问题
<ul>
<li>一致性不是简单的让两个节点最终对一个值的结果一致, 很多时候还需要对这个值的变化历史在不同节点上的观点也要一致</li>
<li>不能简单的以接受到消息的时间作为事件的顺序判断的依据。</li>
<li>物理时间的不可依赖，导致事件的先后关系在分布式系统中退化为事件先后顺序的偏序关系(partital order), 问题的核心演变成如何找出因果关系来取消对物理时钟的依赖。（如果一致性继续弱化的情况下，最终一致（弱一致性）连因果关系都不需要）</li>
</ul>
</li>
<li>论文：Time, Clock and Ordering of Events in a Distributed System
<ul>
<li>https://lamport.azurewebsites.net/pubs/pubs.html#time-clocks</li>
</ul>
</li>
<li>Lamport Clock
<ul>
<li>是针对事件发生历史的逻辑时钟, 它让我们能够把所有的历史事件找到偏序关系, 而且不仅在各自节点的逻辑时间参考系内顺序一致, 全局上的顺序也是一致的。</li>
</ul>
</li>
</ul>
<p><img src="https://user-images.githubusercontent.com/1134993/31995139-d625ea56-b948-11e7-9b81-468651250f7f.png" alt="screen shot 2017-10-25 at 6 53 06 pm" /></p>
<p>P/Q/R是三个节点, 从下往上代表物理时间的流逝, p1, p2, q1, q2, r1, r2 …. 表示事件，波浪线表示事件的发送, 比如p1->q2表示 P把p1事件发送给了Q, Q接受此消息作为q2事件。</p>
<p><img src="https://user-images.githubusercontent.com/1134993/31995186-01abe57c-b949-11e7-91c5-f3e3d159e965.png" alt="screen shot 2017-10-25 at 6 54 20 pm" /></p>
<p><img src="https://user-images.githubusercontent.com/1134993/31995072-998fbe28-b948-11e7-8d43-510a3e766b9a.png" alt="screen shot 2017-10-25 at 6 51 11 pm" /></p>
<ul>
<li>两种一致性模型（Seq，linear）
<ul>
<li>Sequential Consistency (1979)
<ul>
<li>How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs</li>
<li>https://lamport.azurewebsites.net/pubs/pubs.html#new-approach</li>
<li>https://lamport.azurewebsites.net/pubs/pubs.html#multi</li>
</ul>
</li>
<li>linearizability Consistency (1990, M.P. Herlihy & J.M Wing)
<ul>
<li>线性一致性：Seq的前提下，加强进程间的操作排序</li>
</ul>
</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#2pc" id="2pc"><h3>2PC</h3></a>
<ul>
<li>1978</li>
<li>Jim Gary</li>
<li>Tuxedo （XA/Open规范）</li>
</ul>
<a class="header" href="print.html#3pc" id="3pc"><h3>3PC</h3></a>
<ul>
<li>1981</li>
<li>Dale Skeen - Nonblocking Commit Protocols</li>
<li></li>
</ul>
<a class="header" href="print.html#拜占庭将军问题" id="拜占庭将军问题"><h3>拜占庭将军问题</h3></a>
<ul>
<li>1982</li>
<li>Lamport - The Byzantine Generals Problem</li>
<li>https://en.wikipedia.org/wiki/Byzantine_Generals_problem</li>
</ul>
<a class="header" href="print.html#flp不可能原理" id="flp不可能原理"><h3>FLP不可能原理</h3></a>
<ul>
<li>
<p>1985</p>
</li>
<li>
<p>FLP是论文作者（Fischer, Lynch and Patterson）名的缩写。</p>
</li>
<li>
<p>No completely asynchronous consensus protocol can tolerate even a single unannounced process death. [ Impossibility of Distributed Consensus with One Faulty Process,Journal of the Association for Computing Machinery, Vol. 32, No. 2, April 1985] <strong>在异步网络环境中只要有一个故障节点, 不存在一个共识算法能解决一致性问题。</strong></p>
</li>
<li>
<p>在允许节点失效的情况下，纯粹异步系统无法确保一致性在有限的时间内完成。</p>
</li>
<li>
<p><strong>同步</strong>：网络中节点间的时钟误差存在上限，消息传递必须在一定时间内完成，否则为失败；同时节点完成处理消息的时间是一定的。</p>
<ul>
<li>对于同步系统，可以很容易判断消息是否丢失</li>
</ul>
</li>
<li>
<p><strong>异步</strong>：网络中节点时钟差异可以很大，消息传输时间可以任意长，节点处理消息的时间也可以任意长。</p>
<ul>
<li>那么消息无法响应无法知道是传输故障还是节点故障。</li>
</ul>
</li>
<li>
<p>工程上通过付出代价的方式来达到共识。</p>
</li>
<li>
<p>http://the-paper-trail.org/blog/a-brief-tour-of-flp-impossibility/ (A Brief Tour of FLP Impossibility)</p>
</li>
</ul>
<a class="header" href="print.html#cap原理" id="cap原理"><h3>CAP原理</h3></a>
<ul>
<li>2000</li>
<li>一致性consistency、可用性availability、分区容忍性partition <strong>无法同时保证</strong></li>
<li><strong>一致性</strong> ：这里之强一致性，任何操作都是原子的，发生在后面的事件能够看到前面事件发生所导致的结果。（换句话，即保证结果一致，也保证过程／顺序一致）
** 弱化一致性 ： Gossip，CouchDB，Cassandra</li>
<li><strong>可用性</strong> ：在有限时间内，任何非失败节点都能应答请求。
** 弱化可用性 ：MongoDB、Redis、MapReduce。Paxos、Raft。</li>
<li><strong>分区容忍</strong> ： 允许网络分区（脑裂），即节点直接通信无法保障。
** 弱化分区容忍 ：2PC，Zookeeper</li>
</ul>
<a class="header" href="print.html#paxos" id="paxos"><h3>Paxos</h3></a>
<ul>
<li>1990 ～ 2001</li>
<li>Paxos Made Simple (2001)</li>
</ul>
<a class="header" href="print.html#zookeeper" id="zookeeper"><h3>Zookeeper</h3></a>
<a class="header" href="print.html#raft" id="raft"><h3>Raft</h3></a>
<a class="header" href="print.html#pbft" id="pbft"><h3>PBFT</h3></a>
<a class="header" href="print.html#pow-bitcoin" id="pow-bitcoin"><h3>POW (bitcoin)</h3></a>
<ul>
<li>The Bitcoin Backbone Protocol: Analysis and Applications
<ul>
<li>https://eprint.iacr.org/2014/765.pdf</li>
<li>http://crypto.2014.rump.cr.yp.to/59182e301d011c3b5b6146b8cdf91815.pdf</li>
</ul>
</li>
<li>The Bitcoin Backbone Protocol with Chains of Variable Difficulty
<ul>
<li>https://eprint.iacr.org/2016/1048.pdf</li>
</ul>
</li>
<li>Bitcoin as a Transaction Ledger: A Composable Treatment
<ul>
<li>https://eprint.iacr.org/2017/149.pdf</li>
</ul>
</li>
<li>Analysis of the Blockchain Protocol in Asynchronous Networks
<ul>
<li>https://eprint.iacr.org/2016/454.pdf</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#table-of-contents" id="table-of-contents"><h1>Table of Contents</h1></a>
<ul>
<li><a href="print.html#iohkada">IOHK/ada</a>
<ul>
<li><a href="print.html#%E7%99%BD%E7%9A%AE%E4%B9%A6%E7%A0%94%E7%A9%B6">白皮书研究</a>
<ul>
<li><a href="print.html#%E8%A7%A3%E5%86%B3pos%E7%9A%84%E6%A0%B8%E5%BF%83%E9%97%AE%E9%A2%98--the-leader-election-process">解决PoS的核心问题 : the <strong>leader election</strong> process.</a></li>
<li><a href="print.html#%E6%8A%97%E6%94%BB%E5%87%BB%E6%80%A7%E7%9A%84%E8%80%83%E8%99%91">抗攻击性的考虑</a></li>
<li><a href="print.html#%E6%80%A7%E8%83%BD">性能</a></li>
</ul>
</li>
<li><a href="print.html#%E5%85%B6%E4%BB%96%E7%9A%84%E4%B8%80%E4%BA%9Bpos%E5%8D%8F%E8%AE%AE">其他的一些POS协议</a>
<ul>
<li><a href="print.html#sleepy-consensus">Sleepy consensus</a></li>
<li><a href="print.html#snow-white">Snow White</a></li>
<li><a href="print.html#algorand">Algorand</a></li>
<li><a href="print.html#fruitchain">Fruitchain</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="print.html#cardano-sl">Cardano SL</a></li>
<li><a href="print.html#ouroboros-pos%E7%AE%97%E6%B3%95">Ouroboros POS算法</a>
<ul>
<li><a href="print.html#slot-leader-%E9%80%89%E6%8B%A9%E7%AE%97%E6%B3%95">Slot-leader 选择算法</a></li>
<li><a href="print.html#%E4%BB%A3%E7%A0%81">代码</a>
<ul>
<li><a href="print.html#fts-follow-the-satoshi">FTS (Follow the Satoshi)</a></li>
<li><a href="print.html#blockchain">Blockchain</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="print.html#%E5%8F%82%E8%80%83%E6%96%87%E6%A1%A3">参考文档</a>
<ul>
<li><a href="print.html#video">Video</a></li>
<li><a href="print.html#%E9%97%AE%E9%A2%98">问题</a></li>
</ul>
</li>
</ul>
<a class="header" href="print.html#iohkada" id="iohkada"><h2>IOHK/ada</h2></a>
<ul>
<li>Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol
<ul>
<li>https://eprint.iacr.org/2016/889.pdf</li>
</ul>
</li>
<li>Ouroboros Praos: An adaptively-secure, semi-synchronous proof-of-stake blockchain
<ul>
<li>https://eprint.iacr.org/2017/573.pdf</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#白皮书研究" id="白皮书研究"><h3>白皮书研究</h3></a>
<a class="header" href="print.html#解决pos的核心问题--the-leader-election-process" id="解决pos的核心问题--the-leader-election-process"><h4>解决PoS的核心问题 : the <strong>leader election</strong> process.</h4></a>
<ul>
<li>问题：entropy -> randomized election among stakeholders <- an adversary controlling a set of stakeholders, “grinding” vulnerability, use computational resources to bias the leader election.</li>
<li>方法：
<ul>
<li>第一：模型
<ul>
<li>persistence 和 liveness</li>
<li>P是机制保证Tx变成stable，就会全网finality （常见的思路是more than k blocks deep）</li>
<li>L是机制保证合法Tx在某个时间段后一定能stable（也就是说合法交易一定能活下去）</li>
</ul>
</li>
<li>第二：选主协议
<ul>
<li>a coin-flipping protocol ->randomness -> leader election</li>
<li>a snapshot of the current set of stakeholders is taken in regular intervals called <strong>epochs</strong></li>
<li>a secure multiparty computation takes place utilizing the blockchain itself as the <strong>broadcast</strong> channel</li>
<li>in each epoch a set of randomly selected stakeholders form <strong>a committee</strong> which is then responsible for executing the coin-flipping protocol</li>
<li>The outcome of the protocol determines the set of next stakeholders to execute the protocol in the next epoch as well as the outcomes of all leader elections for the epoch.</li>
</ul>
</li>
<li>第三：一组规则
<ul>
<li>protect persistence and liveness.</li>
<li>(1) any honest stakeholder is able to communicate with any other stakeholder,</li>
<li>(2) a number of stakeholders drawn from the honest majority is available as needed to participate in each epoch,</li>
<li>(3) the stakeholders do not remain offline for long periods of time</li>
<li>(4) "forkable strings” (???)</li>
</ul>
</li>
<li>第四：经济激励
<ul>
<li>基于博弈论／纳什均衡设计对抗 block withholding 和 selfish-mining</li>
<li>positive payoff --> cannot be stifled by a coalition of parties --> an equilibrium when all players are rational. (问题是玩家理性吗？）</li>
</ul>
</li>
<li>第五：代理机制
<ul>
<li>stake delegation mechanism -> delegate “voting rights”</li>
<li>可以revoke delegation</li>
</ul>
</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#抗攻击性的考虑" id="抗攻击性的考虑"><h4>抗攻击性的考虑</h4></a>
<ul>
<li>double spending attacks</li>
<li>transaction denial attacks</li>
<li>51% attacks</li>
<li>nothing-at-stake</li>
<li>desynchronization attacks</li>
</ul>
<a class="header" href="print.html#性能" id="性能"><h4>性能</h4></a>
<ul>
<li>transaction confirmation time is from 10 to 16 times faster than that of bitcoin</li>
<li>analysis of double-spending attacks relies on our combinatorial analysis of <strong>forkable and covertly forkable strings</strong> and applies to a much broader class of adversarial behavior than Nakamoto’s more simplified analysis. (???)</li>
<li>prototype implementation and report on <strong>benchmark experiments run in the Amazon cloud</strong> that showcase the power of our proof of stake blockchain protocol in terms of performance.</li>
</ul>
<a class="header" href="print.html#其他的一些pos协议" id="其他的一些pos协议"><h3>其他的一些POS协议</h3></a>
<a class="header" href="print.html#sleepy-consensus" id="sleepy-consensus"><h4>Sleepy consensus</h4></a>
<ul>
<li>https://eprint.iacr.org/2016/918.pdf
<ul>
<li>considers a fixed stakeholder distribution (i.e., stake does not evolve over time) and targets a “mixed” corruption setting, where the adversary is allowed to be adaptive as well as perform fail-stop and recover corruptions in addition to Byzantine faults.</li>
<li>It is actually straightforward to extend our analysis in this mixed corruption setting, resulting security can be argued only in the “corruptions with delay” setting, and thus is not fully adaptive.</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#snow-white" id="snow-white"><h4>Snow White</h4></a>
<ul>
<li>https://eprint.iacr.org/2016/919.pdf
<ul>
<li>addresses an evolving stakeholder distribution and uses a corruption delay mechanism similar to ours for arguing security.</li>
<li>susceptible to a “grinding” type of attack that can bias high probability events in favor of the adversary. While this does not hurt security asymptotically, it prevents a concrete parameterisation that does not take into account adversarial computing power.</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#algorand" id="algorand"><h4>Algorand</h4></a>
<ul>
<li>https://arxiv.org/pdf/1607.01341.pdf
<ul>
<li>distributed ledger following a Byzantine agreement per block approach that can withstand adaptive corruptions.</li>
<li>Given that agreement needs to be reached for each block, such protocols will produce blocks at a rate substantially slower than a PoS blockchain (where the slow down matches the expected length of the execution of the Byzantine agreement protocol) but they are free of forks.</li>
<li>In this respect, despite the existence of forks, blockchain protocols exhibit the flexibility of permitting the clients to set the level of risk that they are willing to undertake, allowing low risk profile clients to enjoy faster processing times in the optimistic sense.</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#fruitchain" id="fruitchain"><h4>Fruitchain</h4></a>
<ul>
<li>https://eprint.iacr.org/2016/916.pdf
<ul>
<li>reward mechanism and an approximate Nash equilibrium proof for a PoW-based blockchain.</li>
<li>We use a similar reward mechanism at the blockchain level, nevertheless our underlying mechanics are different since we have to operate in a PoS setting.</li>
<li>The core of the idea is to provide a PoS analogue of “endorsing” inputs in a fair proportion using the same logic as the PoW-based byzantine agreement protocol for honest majority</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#cardano-sl" id="cardano-sl"><h2>Cardano SL</h2></a>
<ul>
<li>The core idea of proof of stake is that instead of wasting electricity on cracking computationally heavy problems, <strong>a node is selected to mint a new block, with a probability proportional to the amount of coins this node has</strong>. If a node has positive (> 0) stake, it is called a stakeholder. If a node eventually becomes chosen to mint a block, it is called a <strong><em>slot leader</em></strong>.</li>
<li>Cardano SL is called <strong>“Layer”</strong> for a reason. It is the first component of the Cardano Platform. Eventually, it will be expanded with a Control Layer, serving as a trusted computation framework to evaluate a special kind of proofs to ensure that a certain computation was carried out correctly. In <strong>gaming and gambling</strong>, such systems are used for <strong>verifying honesty of random number generation and game outcomes</strong>. Accompanied with side chains, it will make possible to accomplish such tasks as <strong>provably fair distribution of winnings in games</strong>. But the application of Control Layer lies well beyond gaming and gambling. Identity management, credit system and more will be a part of Cardano Platform. We are also aiming to evolve Daedalus, the Cardano SL wallet application, into a universal cryptocurrency wallet featuring automated cryptocurrency trading and cryptocurrency-to-fiat transactions.</li>
</ul>
<a class="header" href="print.html#ouroboros-pos算法" id="ouroboros-pos算法"><h2>Ouroboros POS算法</h2></a>
<ul>
<li><strong>proof</strong> : having evidence that blocks of transactions are legitimate.</li>
<li><strong>Stake</strong> : the relative value held by addresses on the node. “relative value” we mean “all value held by wallets on a particular node divided by total value in the system”.</li>
<li><strong>Slot</strong> : A small period of time that is significantly larger than the expected difference in clocks on different nodes.</li>
<li><strong>slot leaders</strong>: generate blocks for the blockchain. Anyone can become a slot leader if the coin selection algorithm would <strong>select a coin they own</strong>. Nothing except for the <strong>network state</strong> and network participants <strong>being online</strong> matters for the sake of proof of stake.</li>
<li><strong>Follow the Satoshi (FTS)</strong> is an <strong>algorithm</strong>, that verifiably picks a coin, providing <strong>randomness</strong>. When your coin gets selected, you become a slot leader and can listen to transactions announced by others, make a block of those transactions, sign it with your secret key and publish it to the network. （随机选择算法）</li>
<li><strong>Multi Party Computation approach</strong>: select nodes provide the so-called “commitments”, and then those get “revealed”, <strong>producing a random value</strong> generated independently by participants of the network. (提供算力）</li>
</ul>
<a class="header" href="print.html#slot-leader-选择算法" id="slot-leader-选择算法"><h3>Slot-leader 选择算法</h3></a>
<ul>
<li>Leaders for each slot of the current epoch are computed by FTS in the beginning of the current epoch.</li>
<li>So genesis block contains a list of selected slot leaders.</li>
<li>The number of selected slot-leaders corresponds to a number of slots in epoch, and this number depends on fundamental security parameter k defined in configuration file.</li>
<li>Theoretical aspects of the slot leader selection process is described in paper, page 11.</li>
<li>The node sorts all unspent outputs (utxo) in a deterministic way (lexicographically), so result is an ordered sequence of pairs (StakeholderId, Coin), where StakeholderId is an id of stakeholder (its public key hash) and Coin is an amount of coins this stakeholder has. It’s assumed that utxo isn’t empty.</li>
<li>Then the node chooses several random is between 1 and amount of Lovelaces in the system. To find owner of i-th coin node finds the lowest x such that sum of all coins in this list up to ‘i’-th is not less than ‘i’ (and then ‘x’-th address is the owner of i-th coin).</li>
<li>The result is a non-empty sequence of StakeholderId, ids of selected stakeholders. This sequense of SlotLeaders is storing in the node’s runtime context.</li>
<li>With P2SH addresses, node doesn’t know who is going to end up with funds sent to them. Therefore, P2SH addresses can contain destination address which specifies which addresses should count as “owning” funds for the purposes of FTS.</li>
</ul>
<a class="header" href="print.html#代码" id="代码"><h3>代码</h3></a>
<ul>
<li>https://github.com/input-output-hk/cardano-sl</li>
<li>版本历史</li>
</ul>
<p><img src="https://user-images.githubusercontent.com/1134993/31715016-d373d312-b3c7-11e7-80c6-f535e32f6010.png" alt="screen shot 2017-10-18 at 3 32 29 pm" /></p>
<a class="header" href="print.html#fts-follow-the-satoshi" id="fts-follow-the-satoshi"><h4>FTS (Follow the Satoshi)</h4></a>
<ul>
<li>https://github.com/input-output-hk/cardano-sl/blob/master/lrc/Pos/Lrc/Fts.hs</li>
</ul>
<a class="header" href="print.html#blockchain" id="blockchain"><h4>Blockchain</h4></a>
<ul>
<li>https://github.com/input-output-hk/cardano-sl/blob/master/lib/src/Pos/Block/Core/Genesis/Chain.hs</li>
<li>https://github.com/input-output-hk/cardano-sl/tree/master/lib/src/Pos/Block/Logic</li>
</ul>
<a class="header" href="print.html#参考文档" id="参考文档"><h2>参考文档</h2></a>
<ul>
<li>https://cardanodocs.com/introduction/#what-makes-cardano-sl-special</li>
<li>https://cardanodocs.com/cardano/proof-of-stake/</li>
<li>https://cardanodocs.com/technical/leader-selection/</li>
<li>https://cardanodocs.com/cardano/explorer/</li>
<li>https://cardanoexplorer.com/</li>
<li>https://cardanodocs.com/glossary/</li>
<li>https://cardanodocs.com/technical/blocks/</li>
</ul>
<a class="header" href="print.html#video" id="video"><h3>Video</h3></a>
<ul>
<li><a href="https://www.youtube.com/watch?v=JwxVySVF-U4">Ouroboros presentation | IACR Crypto-2017 </a></li>
<li><a href="https://www.youtube.com/watch?v=hMgxZOsTlQc">Bernardo David, IOHK Research, Proof-of-Stake Protocol</a></li>
<li><a href="https://www.youtube.com/playlist?list=PLnPTB0CuBOBw9H7dynFu9U25vqFWRw1UX">Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol</a></li>
</ul>
<a class="header" href="print.html#问题" id="问题"><h3>问题</h3></a>
<ul>
<li>Proof of stake with rigorous security guarantees. 严格安全保证在哪里？</li>
<li>Proof of Stake protocols and we prove that, given this mechanism, honest behavior
is an approximate Nash equilibrium 如果是基于博弈论和纳什均衡的话，那么以太的casper也是这样。区别是什么？</li>
</ul>
<a class="header" href="print.html#bw怼cardano事件" id="bw怼cardano事件"><h3>BW怼cardano事件</h3></a>
<ul>
<li>https://steemit.com/cardamon/@dan/peer-review-of-cardano-s-ouroboros</li>
<li>BW认为ada抄袭（copy）了他的工作，但是没有提他（ Ouroboros is a copy of Delegated Proof of Stake (DPoS) with a few counter-productive modifications. In fact their paper refers to the term “πDPoS” 17 times without mentioning or recognizing any of my prior work.）</li>
<li>结果上，BW认为ada的性能和效率完败
<ul>
<li>出块 EOS: 0.5 seconds vs. Ouroboros: 20 seconds</li>
<li>稳定 EOS: <= 2 seconds vs. Ouroboros: > 5 hours</li>
</ul>
</li>
<li>ada的安全在工程上不可行：400公斤的防弹衣没法穿。（为啥BW没说明）</li>
<li>对dPOS的分析
<ul>
<li>选人 （Selecting a set of block producers）</li>
<li>排队 （Scheduling the producers into time slots）</li>
</ul>
</li>
<li>选人
<ul>
<li>时间轮： BTS 1h vs Ouroboros：5 days</li>
<li>参与要求：Steem 没有下限 vs. Ouroboros at least 1% stake</li>
</ul>
</li>
<li>排队
<ul>
<li>随机性：
<ul>
<li>Steem 从确定一组里面随机抽（uses deterministic scheduling with pseudorandom shuffling）</li>
<li>Ouroboros 随机性由随机选定的权益人生成（sampling from a source of provable randomness created by a committee of randomly selected stakeholders）</li>
</ul>
</li>
<li>安全性：
<ul>
<li>Steem / BitShares / EOS 靠投票（人为）select a set of unlikely to collude entities by approval voting then schedule them in a pseudorandom order。 同时EOS要取消shuffle （ EOS will be removing the random shuffle all together.）</li>
<li>Ouroboros 随机选择导致时间和延时无法预期 Ouroboros the length of time until 2/3+ of the stake is “randomly selected” is not known. unpredictable latency like bitcoin</li>
</ul>
</li>
</ul>
</li>
<li>分布式安全（Distribution Security Issues）
<ul>
<li>Steem 14 people confirm a block each round.</li>
<li>只有投票才能对抗基于stake权重的中心化 stake-weighted voting creates a very high centralization that can only be countered with approval voting</li>
<li>Corruption takes place at the individual level, not the stake level. it is wrong to assume that large stake holders will behave like a group of smaller stakeholders of similar size</li>
</ul>
</li>
</ul>
<a class="header" href="print.html#bls" id="bls"><h3>BLS</h3></a>
<ul>
<li>https://en.wikipedia.org/wiki/Boneh%E2%80%93Lynn%E2%80%93Shacham</li>
<li>https://crypto.stanford.edu/pbc/</li>
<li>https://github.com/dfinity/bn/blob/master/bls/src/bls_c.cpp</li>
<li>https://github.com/dfinity/go-dfinity-crypto/blob/master/bls/bls.go</li>
</ul>
<a class="header" href="print.html#threshold-relay" id="threshold-relay"><h3><strong>Threshold Relay</strong></h3></a>
<p>which applies cryptography to create randomness on demand of sufficient network participants</p>
<ul>
<li>
<p>https://dfinity.org/faq.html</p>
</li>
<li>
<p>The composition of each group is entirely random such that they can intersect and clients can be presented in multiple groups. In DFINITY, each group is comprised of 400 members. When a group is defined, the members attempt to set up a BLS threshold signature system using a distributed key generation protocol. If they are successful within some fixed number of blocks, they then register the public key ("identity") created for their group on the global blockchain using a special transaction, such that it will become part of the set of active groups in a following mining "epoch". The network begins at "genesis" with some number of predefined groups, one of which is nominated to create a signature on some default value. Such signatures are random values - if they were not then the group's signatures on messages would be predictable and the threshold signature system insecure - and each random value produced thus is used to select a random successor group. This next group then signs the previous random value to produce a new random value and select another group, relaying between groups ad infinitum and producing a sequence of random values.</p>
</li>
<li>
<p><a href="https://dfinity.org/pdf-viewer/pdfs/viewer.html?file=../library/threshold-relay-blockchain-stanford.pdf">How to Achieve Near-Instant Finality in Public Blockchains using a VRF</a></p>
</li>
<li>
<p><a href="https://dfinity.org/pdf-viewer/pdfs/viewer.html?file=../library/intro-dfinity-crypto.pdf">DFINITY Crypto Techniques</a></p>
</li>
</ul>
<a class="header" href="print.html#quorum--quorum-slices" id="quorum--quorum-slices"><h3>Quorum & Quorum slices</h3></a>
<p><img src="https://user-images.githubusercontent.com/1134993/32044473-452bc6cc-ba03-11e7-928c-ae4b83645332.png" alt="screen shot 2017-10-26 at 5 03 21 pm" /> <strong>=></strong> <img src="https://user-images.githubusercontent.com/1134993/32044475-455c0a44-ba03-11e7-99db-2c3a68f23b2e.png" alt="screen shot 2017-10-26 at 5 03 40 pm" /></p>
<ul>
<li>Quoram 决定全局共识</li>
<li>Quoram slices 决定区域共识</li>
<li>这就是所谓FBFT的Federated的来由，所谓结盟的含义。</li>
<li>Quoram slices就是从我自己视角里面我信任的成员，所谓我的帮派，我的同盟。</li>
</ul>
<p><img src="https://user-images.githubusercontent.com/1134993/32045077-f4e8af48-ba04-11e7-996f-4cffa5416886.png" alt="screen shot 2017-10-26 at 5 19 41 pm" /></p>
<a class="header" href="print.html#reference-3" id="reference-3"><h3>Reference</h3></a>