├── .gitignore ├── Blogs ├── An Introduction to the BlockDAG Paradigm.md ├── Blockchain terminology; the 35 most commonly used blockchain terms explained.md ├── Confirmation Times in SPECTRE.md ├── Incentives and Trade-offs in Transaction Selection in DAG-based Protocols.md ├── Transaction Selection Games in BlockDAGs.md ├── a-zero-math-introduction-to-markov-chain-monte-carlo-methods.md ├── blockchains-dont-scale-not-today-at-least-but-there-s-hope.md ├── performance-vs-scalability.md └── smart-contract-languages-comparison.md ├── Papers ├── Algorand │ ├── 1-INTRODUCTION.md │ ├── 10-EVALUATION.md │ ├── 11-FUTURE WORK.md │ ├── 12-CONCLUSION.md │ ├── 2-RELATED WORK.md │ ├── 3-GOALS AND ASSUMPTIONS.md │ ├── 4-OVERVIEW.md │ ├── 5-CRYPTOGRAPHIC SORTITION.md │ ├── 6-BLOCK PROPOSAL.md │ ├── 7-BA⋆.md │ ├── 8-ALGORAND.md │ ├── 9-IMPLEMENTATION.md │ └── ABSTRACT.md ├── Avalanche │ ├── 1 Introduction.md │ ├── 2 Approach.md │ └── Abstract.md ├── DagCoin │ ├── 0-Abstract.md │ ├── 1-Introduction.md │ ├── 2-Safely accepting Double-spends in the DAG-chain.md │ ├── 3-Preventing too many transactions merging too many transactions.md │ ├── 4-Preventing Unbounded Cascade Updates to Confirmation Scores.md │ ├── 5-Periodic re-computing to reduce computation load.md │ ├── 6-Targeting a fixed transactions rate vs no maximum rate.md │ └── 7-Conclusion.md ├── Inclusive │ ├── 1-Introduction.md │ ├── 2-From Trees to Directed Acyclic Graphs (DAGs).md │ ├── 3-Security.md │ ├── Abstract.md │ └── DefinitionsBeforeLemma3_Tony.jpeg ├── PHANTOM │ ├── 1-INTRODUCTION.md │ ├── 2-THE PHANTOM PROTOCOL.md │ ├── 3-FORMAL MODEL AND STATEMENT.md │ ├── 4-SCALABILITY AND NETWORK DELAYS.md │ ├── 5-PROOF.md │ ├── 6-VARIANTS.md │ ├── 7-CONFIRMATION TIMES.md │ ├── ABSTRACT.md │ └── PHANTOM___an_efficient_implementation__chinese.pdf ├── RepuCoin │ ├── 1-Introduction.md │ ├── 2-RelatedWork.md │ ├── 3-SystemAndThreatModel.md │ ├── 4-RepuCoin.md │ └── 4.1-BlockMiningAndRewardSystem.md ├── SPECTRE │ ├── 1-INTRODUCTION.md │ ├── 2-FORMAL STATEMENT OF THE PROBLEM.md │ ├── 3.SPECTRE VS BITCOIN – OVERVIEW.md │ ├── 4. THE SPECTRE PROTOCOL.md │ ├── 5. HIGH - LEVEL OVERVIEW OF THE PROOF.md │ ├── 6. RELATED WORK.md │ ├── 7. CONCLUSION.md │ ├── ABSTRACT.md │ ├── APPENDIX A.md │ └── APPENDIX B SIMULATION RESULTS.md └── Utreexo │ ├── 0-Abstract.md │ ├── 1-Introduction.md │ ├── 2-Related Work.md │ ├── 3-Application to Bitcoin.md │ ├── 4-Dynamic Accumulator.md │ ├── 5-Performance and Optimizations.md │ ├── 6-Conclusion.md │ ├── 7-Appendix.md │ └── Figures │ ├── 1.jpg │ ├── 10.jpg │ ├── 11.jpg │ ├── 12.jpg │ ├── 13.jpg │ ├── 14.jpg │ ├── 15.jpg │ ├── 2.png │ ├── 3.png │ ├── 4.png │ ├── 5.jpg │ ├── 6.jpg │ ├── 7.jpg │ ├── 8.jpg │ └── 9.jpg ├── Projects └── Byteball │ ├── 1.INTRODUCTION.md │ ├── 2. Database structure.md │ ├── 3. Native currency - bytes.md │ ├── 4. Double-spends.md │ ├── 5. The Main Chain.md │ ├── 6. Witnesses.md │ ├── 7. Finality.md │ ├── 8. Storage of nonserial units.md │ └── ABSTRACT.md └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | **/.DS_Store 2 | -------------------------------------------------------------------------------- /Blogs/performance-vs-scalability.md: -------------------------------------------------------------------------------- 1 | [Source](https://blog.professorbeekums.com/performance-vs-scalability/ "Permalink to Performance Vs Scalability") 2 | 3 | # Performance Vs Scalability 4 | 5 | One thing that tripped me up early on in my career was the difference between performance and scalability. At first I thought they were exactly the same. I was quite surprised when my first project to scale a system actually made my code run slower… in my dev environment at least. 6 | 7 | Let's get definitions out of the way. Scalability is being able to handle large amounts of users/data/traffic. Performance is about speed. While the speed of light may be constant, software system speed is far from. 8 | 9 | A useful analogy is checking out at the supermarket. Let's say a cashier can checkout one shopper every minute. Assuming no more than one shopper goes to the cashier every minute, then a shopper can checkout in one minute. 10 | 11 | ![][1] 12 | 13 | What happens when 2 shoppers attempt to go to the cashier every minute? One shopper will be checked out in 1 minute, but the second shopper will take 2 minutes. 14 | 15 | ![][2] 16 | 17 | A third and fourth shopper will come while the second shopper starts checking out. The third shopper will have to wait 1 minute for the second shopper to finish and then spend 1 minute checking out so the third shopper will also take 2 minutes. But the fourth shopper needs to wait 3 minutes. 18 | 19 | ![][3] 20 | 21 | The fifth and sixth shopper are also arriving just as the third shopper starts. Fifth shopper waits 3 minutes, sixth shopper waits 4 minutes. The longer this keeps up, the longer shoppers will have to wait. 22 | 23 | The performance we care about is not how fast the cashier can checkout a single person. It is how long the average shopper is waiting. Performance for a single cashier works for us well enough when there aren't very many people. The performance drops quickly when we add shoppers at a faster rate than a single cashier can handle. 24 | 25 | ![][4] 26 | 27 | Scalability is making sure that the performance is constant no matter now many people are coming in. This may mean creating things that lower performance when there aren't very many people (low scale). Ideally our business is successful and we're more concerned about performance with a greater number of people (high scale). 28 | 29 | ![][5] 30 | 31 | One tactic used is to add caching. In some cases you may need to process a lot of data for a user. But if that data needs to be processed exactly the same many times, then it may be worth just saving the final result. 32 | 33 | Using our supermarket example: let's say there are a number of regulars who order the same thing every day (they're hungry people). Instead of having them scanning the same items day after day, we could give them a special receipt. Scanning this one receipt will automatically scan their entire shopping cart. Instead of taking a minute to check them out, our cashier may only need 10 seconds to check the receipt. That increases the number of people a single cashier can handle to 6 a minute instead of 1 a minute. 34 | 35 | However, the receipt may fail for a number of reasons: 36 | 37 | * The shopper is not consistent with what they buy (data that changes often) 38 | * The supermarket gets a lot of first time shoppers (large variety of data) 39 | * The receipt data is lost (cache data loss) 40 | 41 | In these situations we have "cache misses" where our receipt doesn't work. That means we have to spend time checking the receipt and then scanning our shopper's shopping cart anyway. Instead of 10 seconds or a minute, our cashier now spends 1 minute and 10 seconds to check out a shopper. 42 | 43 | The next thing we could do is add more cashiers. If 1 cashier can handle 1 person a minute, then 6 cashiers can handle 6 people a minute. The performance for a single shopper may still go down because they need to decide which cashier to go to. They may spend 5 seconds making that decision so their checkout is 1 minute and 5 seconds instead of 1 minute. 44 | 45 | ![][6] 46 | 47 | However, we don't care too much about reducing the performance slightly when there are only a small number of shoppers. We care about making sure we don't greatly reduce performance when there are a large number of shoppers so we will add more cashiers. 48 | 49 | We may still encounter issues with lots of cashiers though. There's always the chance we will always have more shoppers than we expect and they will overload our cashiers. People will start lining up behind each cashier. 50 | 51 | What if there is one shopper who is taking a really long time? The shoppers behind that person will be frustrated watching other lines move faster. What if there isn't enough space for the lines behind each cashier? Do the lines start merging? Do we have shoppers get frustrated when it appears that someone cuts in front of them? Do fights start breaking out at our supermarket? 52 | 53 | What happens if one of our cashiers falls ill and there is no replacement? Does every shopper in line now have to get on the back of another line? Or will they just leave without buying anything? 54 | 55 | We can solve this by creating a single line or queue for every shopper. Now every shopper will start checking out in the order they enter the queue. They will also not have to worry about being stuck behind a slow shopper or a cashier falling ill. With a single queue, shoppers just go to the next available cashier. 56 | 57 | ![][7] 58 | 59 | It may take longer. Our shopper has to find their way to the end of the queue. They may have to walk farther from the queue's exit to the next available cashier. But this is a small price to pay for an orderly and speedy checkout process. 60 | 61 | The software analogy would be message queues. A message represents our shopper and the things they have to buy. Messages are added to a message queue just like shoppers go to the back of the line. Software processes called workers take messages from this queue and process them much like cashiers checkout shoppers. 62 | 63 | ![][8] 64 | 65 | There are many other techniques to improve scalability. I hope this has illustrated what some of those techniques look like. Also the result will be more complicated code that runs slower on a developer machine so it may seem like a pointless effort at first. The effort will pay off though when you have a successful high scale business. 66 | 67 | [1]: https://blog.professorbeekums.com/img/2017/8/one_cash_register.png 68 | [2]: https://blog.professorbeekums.com/img/2017/8/short_queue.png 69 | [3]: https://blog.professorbeekums.com/img/2017/8/short_queue2.png 70 | [4]: https://blog.professorbeekums.com/img/2017/8/performance.png 71 | [5]: https://blog.professorbeekums.com/img/2017/8/scalability.png 72 | [6]: https://blog.professorbeekums.com/img/2017/8/indecisiveshopper.png 73 | [7]: https://blog.professorbeekums.com/img/2017/8/shopperqueue.png 74 | [8]: https://blog.professorbeekums.com/img/2017/8/messagequeue.png 75 | -------------------------------------------------------------------------------- /Papers/Algorand/1-INTRODUCTION.md: -------------------------------------------------------------------------------- 1 | * Source: https://people.csail.mit.edu/nickolai/papers/gilad-algorand-eprint.pdf 2 | * TranStudy: https://github.com/DAGfans/TranStudy/edit/master/Papers/Algorand/1-INTRODUCTION.md 3 | 4 | ## 1 INTRODUCTION 5 | 6 | ## 1 介绍 7 | 8 | Cryptographic currencies such as Bitcoin can enable new applications, such as smart contracts [ 24 , 49 ] and fair protocols [ 2 ], can simplify currency conversions [ 12 ], and can avoid trusted centralized authorities that regulate transactions. 9 | However, current proposals suffer from a trade-off between latency and confidence in a transaction. 10 | For example, achieving a high confidence that a transaction has been confirmed in Bitcoin requires about an hour long wait [ 7 ]. 11 | On the other hand, applications that require low latency cannot be certain that their transaction will be confirmed, and must trust the payer to not double-spend [45]. 12 | 13 | 像比特币这样的加密货币可以产生新的应用，如智能合约[24,49]和公平协议[2]，能够简化货币转换[12]，并且可以不需要可信中央机构来管理交易。 14 | 然而，目前的方案都需要在延迟和信任之间的权衡。 15 | 例如，在比特币中以较高可信度确认交易需要大约一个小时的等待时间[7]。 16 | 另一方面，低延迟的应用无法确定他们的交易是否得到确认，并且必须相信支付方不会双花[45]。 17 | 18 | Double-spending is the core problem faced by any cryptocurrency, where an adversary holding $1 gives his $1 to two different users. 19 | Cryptocurrencies prevent double-spending by reaching consensus on an ordered log (“blockchain”) of transactions. 20 | Reaching consensus is difficult because of the open setting: since anyone can participate, an adversary can create an arbitrary number of pseudonyms (“Sybils”) [ 21 ], making it infeasible to rely on traditional consensus protocols [15] that require a fraction of honest users. 21 | 22 | 双花是任何加密货币所面临的核心问题，即持有1美元的攻击者将1美元支付两个不同的用户。 23 | 加密货币通过在有序的交易日志（“区块链”）上达成共识来防止双花。 24 | 在公开的环境下达成共识是困难的：因为任何人都可以参与，攻击者可以创建任意数量的虚假账号（“Sybils”）[21]，导致依靠传统的需要有部分诚实用户的共识协议[15]是不可行的。 25 | 26 | Bitcoin [ 41 ] and other cryptocurrencies [ 23 , 53 ] address this problem using proof-of-work (PoW), where users must repeatedly compute hashes to grow the blockchain, and the longest chain is considered authoritative. 27 | PoW ensures that an adversary does not gain any advantage by creating pseudonyms. 28 | However, PoW allows the possibility of forks, where two different blockchains have the same length, and neither one supersedes the other. 29 | Mitigating forks requires two unfortunate sacrifices: the time to grow the chain by one block must be reasonably high (e.g., 10 minutes in Bitcoin), and applications must wait for several blocks in order to ensure their transaction remains on the authoritative chain (6 blocks are recommended in Bitcoin [ 7 ]). 30 | The result is that it takes about an hour to confirm a transaction in Bitcoin. 31 | 32 | 比特币[41]和其他加密货币[23,53]使用工作量证明（PoW）解决了这个问题，用户必须重复计算散列来延伸区块链，最长的链被认为是权威的。 33 | PoW确保攻击者不会通过创建虚假账号获得任何优势。 34 | 但是，PoW允许分叉，有可能其中两个不同的区块链具有相同的长度，并且两个区块链都不相互替代。 35 | 为了缓解分叉有两个沉重的代价：在链上延伸一个时间必须相当长（例如比特币为10分钟），并且应用程序必须等待几个区块才能确保其交易保存在权威的链上（在比特币[7]中推荐6个区块）。 36 | 导致确认比特币交易大约需要一个小时。 37 | 38 | This paper presents Algorand, a new cryptocurrency designed to confirm transactions on the order of one minute. 39 | The core of Algorand uses a Byzantine agreement protocol called BA⋆that scales to many users, which allows Algorand to reach consensus on a new block with low latency and without the possibility of forks. 40 | A key technique that makes BA⋆ suitable for Algorand is the use of verifiable random functions (VRFs) [ 38 ] to randomly select users in a private and non-interactive way. 41 | BA⋆was previously presented at a workshop at a high level [ 37 ], and a technical report by Chen and Micali [16] described an earlier version of Algorand. 42 | 43 | 本文介绍了Algorand，一种新的加密货币，旨在一分钟的规模内的确认交易。 44 | Algorand的核心在于使用了称为BA* 的拜占庭协定的协议，它可以扩展到许多用户，这使得Algorand能够以低延迟达成共识，而且不会产生分叉。 45 | 使BA* 适用Algorand的一种关键技术是用可验证的随机函数（VRF）[38]来以私有和非交互的方式随机选择用户. 46 | BA* 之前在高级别的研讨会上提出[37 ], 并且Chen和Micali [16]的技术报告描述了Algorand的早期版本。 47 | 48 | Algorand faces three challenges. 49 | First, Algorand must avoid Sybil attacks, where an adversary creates many pseudonyms to influence the Byzantine agreement protocol. 50 | Second,BA⋆must scale to millions of users, which is far higher than the scale at which state-of-the-art Byzantine agreement protocols operate. 51 | Finally, Algorand must be resilient to denial-of-service attacks, and continue to operate even if an adversary disconnects some of the users [29, 51]. 52 | 53 | Algorand面临三大挑战。 54 | 首先，Algorand必须避免女巫攻击，在这种攻击中，攻击者会创建许多假账号来影响拜占庭协议。 55 | 其次，BA* 必须扩展到数百万用户，这远远高于最先进的拜占庭协议的运行规模。 56 | 最后，Algorand必须能够抵御拒绝服务攻击，并且即使攻击者切断某些用户的连接也可以继续运行[29,51]。 57 | 58 | Algorand addresses these challenges using several techniques, as follows. 59 | 60 | Algorand使用以下几种技术应对这些挑战。 61 | 62 | **Weighted users** 63 | To prevent Sybil attacks, Algorand as signs a weight to each user. 64 | BA⋆is designed to guarantee consensus as long as a weighted fraction (a constant greater than 2/3) of the users are honest. 65 | In Algorand, we weigh users based on the money in their account. 66 | Thus, as long as more than some fraction (over 2/3) of the money is owned by honest users, Algorand can avoid forks and double-spending. 67 | 68 | **有权重的用户** 69 | 为了防止女巫，Algorand对每个用户都加以权衡. 70 | BA* 被设计为只要诚实用户的总权重达到一定比例（某大于2/3的常数），就能保证一致性。 71 | 在Algorand，我们根据用户账户中的资金来衡量用户的权重。 72 | 因此，只要有诚实用户拥有一部分（超过2/3）的钱，Algorand就可以避免分叉和双花。 73 | 74 | **Consensus by committee** 75 | BA⋆achieves scalability by choosing a committee—a small set of representatives randomly selected from the total set of users—to run each step of its protocol. 76 | All other users observe the protocol messages, which allows them to learn the agreed-upon block. 77 | BA⋆chooses committee members randomly among all users based on the users’ weights. 78 | This allows Algorand to ensure that a sufficient fraction of committee members are honest. 79 | However, relying on a committee creates the possibility of targeted attacks against the chosen committee members. 80 | 81 | **委员会的共识** 82 | BA* 通过选择一个委员会（一组从全体用户中随机选出的一些代表）来执行协议的每一步，来提高可扩展性。 83 | 所有其他用户观察协议消息，这使他们能够得知已商定的块。 84 | BA* 根据用户的权重在所有用户中随机选择委员会成员。 85 | 因此Algorand可以确保有足够比例的委员会成员是诚实的。 86 | 但是，依靠委员会可能会让选定的委员会成员遭受有针对性的攻击。 87 | 88 | **Cryptographic sortition** 89 | To prevent an adversary from targeting committee members,BA⋆selects committee members in a private and non-interactive way. 90 | This means that every user in the system can independently determine if they are chosen to be on the committee, by computing a function (a VRF [ 38 ]) of their private key and public information from the blockchain. 91 | If the function indicates that the user is chosen, it returns a short string that proves this user’s committee membership to other users, which the user can include in his network messages. 92 | Since membership selection is non-interactive, an adversary does not know which user to target until that user starts participating in BA⋆. 93 | 94 | **加密的抽签** 95 | 为了防止敌人把目标锁定在委员会成员身上，BA以私有和非互动的方式选择委员会成员。 96 | 这意味着系统中的每个用户都可以通过计算他们私钥的函数（VRF [38]）和区块链中的公共信息来独立确定他们是否被选中参加委员会。 97 | 如果该函数指示用户被选中，它将返回一个短字符串，该字符串向其他用户证明此用户的委员会成员资格，用户可以在其网络消息中包含该字符串。 98 | 由于会员选择是非交互式的，因此在用户开始参与BA*之前，攻击者不知道要定位哪个用户。 99 | 100 | **Participant replacement.** 101 | Finally, an adversary may target a committee member once that member sends a message in BA⋆. 102 | BA⋆mitigates this attack by requiring committee members to speak just once. 103 | Thus, once a committee member sends his message (exposing his identity to an adversary), the committee member becomes irrelevant to BA⋆. 104 | BA⋆ achieves this property by avoiding any private state (except for the user’s private key), which makes all users equally capable of participating, and by electing new committee members for each step of the Byzantine agreement protocol. 105 | 106 | **参与者的更换** 107 | 最后，一旦某委员会成员在BA* 发送信息，攻击者可能会定位该名成员。 108 | BA* 通过要求委员会成员只发一次消息来消除这种攻击。 109 | 因此，一旦委员会成员发送他的消息（将他的身份暴露给对手），它就不参与BA* 了。 110 | BA* 通过避免任何私有状态（用户的私钥除外），使所有用户都有能力参与，并通过为拜占庭协议的每一步选举新的委员会成员来实现此功能。 111 | 112 | We implement a prototype of Algorand and BA⋆, and use it to empirically evaluate Algorand’s performance. Experimental results running on 1,000 Amazon EC2 VMs demonstrate that Algorand can confirm a 1 MByte block of transactions in∼22 seconds with 50,000 users, that Algorand’s latency remains nearly constant when scaling to half a million users, that Algorand achieves 125×the transaction throughput of Bitcoin, and that Algorand achieves acceptable latency even in the presence of actively malicious users. 113 | 114 | 我们实现了Algorand和BA* 的原型，并用它来评估Algorand的真实表现。 115 | 在1,000台亚马逊EC2虚拟机上运行的实验结果表明，在Algorand下，50,000个用户可以在约22秒内确认一个1M字节的交易块，当扩展到50万用户时，Algorand的延迟几乎保持不变，Algorand实现了比特币125倍的交易吞吐量 ，Algorand甚至在存在主动恶意用户的情况下也能达到可接受的延迟。 116 | -------------------------------------------------------------------------------- /Papers/Algorand/10-EVALUATION.md: -------------------------------------------------------------------------------- 1 | 10 2 | 3 | EVALUATION 4 | 5 | Our evaluation quantitatively answers the following: 6 | 7 | • What is the latency that Algorand can achieve for con- firming transactions, and how does it scale as the number of users grows? (§10.1) 8 | 9 | • What throughput can Algorand achieve in terms of trans- actions per second? (§10.2) 10 | 11 | • What are Algorand’s CPU, bandwidth, and storage costs? 12 | 13 | (§10.3) 14 | 15 | • How does Algorand perform when users misbehave? 16 | 17 | (§10.4) 18 | 19 | • Does Algorand choose reasonable timeout parameters? 20 | 21 | (§10.5) 22 | 23 | To answer these questions, we deploy our prototype of Algorand on Amazon’s EC2 using 1,000 m4.2xlarge virtual machines (VMs), each of which has 8 cores and up to 1 Gbps network throughput. To measure the performance of Algo- rand with a large number of users, we run multiple Algorand users (each user is a process) on the same VM. By default, we run 50 users per VM, and users propose a 1 MByte block. To simulate commodity network links, we cap the bandwidth for each Algorand process to 20 Mbps. To model network la- tency we use inter-city latency and jitter measurements [52] and assign each machine to one of 20 major cities around the world; latency within the same city is modeled as negligible. We assign an equal share of money to each user; the equal distribution of money maximizes the number of messages that users need to process. Graphs in the rest of this section plot the time it takes for Algorand to complete an entire round, and include the minimum, median, maximum, 25th, and 75th percentile times across all users. 24 | 25 | 10.1 Latency 26 | 27 | Figure 5 shows results with the number of users varying from 5,000 to 50,000 (by varying the number of active VMs from 100 to 1,000). The results show that Algorand can confirm transactions in well under a minute, and the latency is near- constant as the number of users grows. (Sinceτ final = 10,000, the time it takes to complete the final step increases until there are 10,000 users in the system; before this point, users are selected more than once and send fewer votes with higher weights.) 28 | 29 | Figure 5: Latency for one round of Algorand, with 5,000 to 50,000 users. 30 | Figure 6: Latency for one round of Algorand in a configura- tion with 500 users per VM, using 100 to 1,000 VMs. 31 | 32 | To determine if Algorand continues to scale to even more users, we run an experiment with 500 Algorand user pro- cesses per VM. This configuration runs into two bottlenecks: CPU time and bandwidth. Most of the CPU time is spent verifying signatures and VRFs. To alleviate this bottleneck in our experimental setup, for this experiment we replace verifications with sleeps of the same duration. We are un- able to alleviate the bandwidth bottleneck, since each VM’s network interface is maxed out; instead, we increase λ step to 1 minute. 33 | 34 | Figure 6 shows the results of this experiment, scaling the number of users from 50,000 to 500,000 (by varying the num- ber of VMs from 100 to 1,000). The latency in this experiment is about 4× higher than in Figure 5, even for the same num- ber of users, owing to the bandwidth bottleneck. However, the scaling performance remains roughly flat all the way to 500,000 users, suggesting that Algorand scales well. 35 | 36 | 10.2 Throughput 37 | 38 | In the following set of experiments we deploy 50,000 users on our 1,000 VMs (50 users per machine). Figure 7 shows the results with a varying block size. The figure breaks the Algorand round into three parts. Block proposal (§6), at the bottom of the graph, is the time it takes a user to obtain the proposed block. The block proposal time for small block sizes is dominated by the λ priority +λ stepvar wait time. For large block sizes, the time to gossip the large block contents dominates. BA⋆ except for the final step, in the middle of the graph, is the time it takes for BA⋆ to reach the final step. Finally, BA⋆’s final step, at the top of the graph, is the time it takes BA⋆ to complete the final step. We break out the final step separately because, for the purposes of through- put, it could be pipelined with the next round (although our prototype does not do so). 39 | Figure 7: Latency for one round of Algorand as a function of the block size. 40 | The results show that Algorand’s agreement time (i.e., BA⋆) is independent of the block size, and stays about the same (12 seconds) even for large blocks. The throughput can be further increased by pipelining the final step, which takes about 6 seconds, with the next round of Algorand. The fixed time for running BA⋆ and the linear growth in block propagation time (with the size of the block) suggest that increasing the block size allows one to amortize the time it takes to run BA⋆ to commit more data, and therefore reach a throughput that maximizes the network capability. 41 | 42 | At its lowest latency, Algorand commits a 2 MByte block in about 22 seconds, which means it can commit 327 MBytes of transactions per hour. For comparison, Bitcoin commits a 1 MByte block every 10 minutes, which means it can com- mit 6 MBytes of transactions per hour [9]. As Algorand’s block size grows, Algorand achieves higher throughput at the cost of some increase to latency. For example, with a 10 MByte block size, Algorand commits about 750 MBytes of transactions per hour, which is 125× Bitcoin’s throughput. 43 | 44 | 10.3 Costs of running Algorand 45 | 46 | Users running Algorand incur CPU, network, and storage costs. The CPU cost of running Algorand is modest; when running 50 users per VM, CPU usage on the 8-core VM was about 40% (most of it for verifying signatures and VRFs), meaning each Algorand process uses about 6.5% of a core. In terms of bandwidth, each user in our experiment with 1 MByte blocks and 50,000 users uses about 10 Mbit/sec (em- pirically computed as the total amount of data sent, divided by the duration of the experiment). We note that the com- munication cost per user is independent of the number of users running Algorand, since users have an expected fixed number of neighbors they gossip messages to, and the num- ber of messages in the consensus protocol depends on the committee size (rather than the total number of users). 47 | Figure 8: Latency for one round of Algorand with a varying fraction of malicious users, out of a total of 50,000 users. 48 | In terms of storage cost, Algorand stores block certificates in order to prove to new users that a block was committed. This storage cost is in addition to the blocks themselves. Each block certificate is 300 KBytes, independent of the block size; for 1 MByte blocks, this would be a ∼30% storage overhead. Sharding block storage across users (§8.3) reduces storage costs proportionally. For example, sharding modulo 10 would require each user to store, on average, 130 KB for every 1MB block that is appended to the ledger. 49 | 50 | 10.4 Misbehaving users 51 | 52 | Algorand’s safety is guaranteed by BA⋆ (§7), but proving this experimentally would require testing all possible attacker strategies, which is infeasible. However, to experimentally show that our Algorand prototype handles malicious users, we choose one particular attack strategy. We force the block proposer with the highest priority to equivocate about the proposed block: namely, the proposer sends one version of the block to half of its peers, and another version to others (note that as an optimization, if a user receives to conflicting versions of a block from the highest priority block proposer before the block proposal step is complete, he discards both proposals and starts BA⋆ with the empty block). Malicious users that are chosen to be part of the BA⋆ committee vote for both blocks. Figure 8 shows how Algorand’s performance is affected by the weighted fraction of malicious users. The results show that, at least empirically for this particular at- tack, Algorand is not significantly affected. 53 | 54 | 10.5 Timeout parameters 55 | 56 | The above results confirm that BA⋆ steps finish in well un- der λ step (20 seconds), that the difference between 25th and 75th percentiles of BA⋆ completion times is under λ stepvar (5 seconds), and that blocks are gossiped within λ block (1 minute). We separately measure the time taken to propa- gate a block proposer’s priority and proof; it is consistently around 1 second, well under λ priority (5 seconds), confirming the measurements by Decker and Wattenhofer [18]. 57 | -------------------------------------------------------------------------------- /Papers/Algorand/11-FUTURE WORK.md: -------------------------------------------------------------------------------- 1 | 11 2 | 3 | FUTURE WORK 4 | 5 | This paper focused on the consensus mechanism for commit- ting transactions, and addressing the associated scalability and security challenges. There remain a number of open problems in designing permissionless cryptocurrencies: 6 | 7 | Incentives. In order to encourage Algorand users to par- ticipate, i.e., be online when selected and pay the network cost of operating Algorand, the system may need to include incentives, possibly in form of a reward mechanism. Design- ing and analyzing an incentive mechanism includes many challenges, such as ensuring that users do not have perverse incentives (e.g., to withhold votes), and that malicious users cannot “game the system” to obtain more rewards than users who follow the protocol (e.g., by influencing seed selection). 8 | 9 | Cost of joining. To join Algorand, new users fetch all ex- isting blocks with their accompanying certificates, which can comprise a large amount of data. Other cryptocurrencies face a similar problem, but since the throughput of Algorand is relatively high, this may create a scalability challenge. 10 | 11 | Forward security. Attackers may attempt to corrupt users over time, since identities of committee members are re- vealed after they send a message. If an attacker manages to obtain enough user keys, he could construct a fake certificate to create a fork. One solution would be for users to forget the signing key before sending out a signed message (and commit to a series of signing keys ahead of time, perhaps using identity-based encryption [11, 20]). 12 | -------------------------------------------------------------------------------- /Papers/Algorand/12-CONCLUSION.md: -------------------------------------------------------------------------------- 1 | 12 2 | 3 | CONCLUSION 4 | 5 | Algorand is a new cryptocurrency that confirms transactions on the order of a minute with a negligible probability of fork- ing. Algorand’s design is based on a cryptographic sortition mechanism combined with the BA⋆ Byzantine agreement protocol. Algorand avoids targeted attacks at chosen partic- ipants using participant replacement at every step. Exper- imental results with a prototype of Algorand demonstrate that it achieves sub-minute latency and 125× the throughput of Bitcoin, and scales well to 500,000 users. 6 | 7 | ACKNOWLEDGMENTS 8 | 9 | Thanks to Iddo Bentov, Ethan Heilman, Jelle van den Hooff, and our shepherd, Robbert van Renesse, for their helpful com- ments and suggestions. Gilad, Hemo, and Zeldovich were supported by NSF awards CNS-1413920 and CNS-1414119. 10 | -------------------------------------------------------------------------------- /Papers/Algorand/3-GOALS AND ASSUMPTIONS.md: -------------------------------------------------------------------------------- 1 | * **Source:** https://people.csail.mit.edu/nickolai/papers/gilad-algorand-eprint.pdf 2 | * **TranStudy:** https://github.com/DAGfans/TranStudy/edit/master/Papers/Algorand/3-GOALS%20AND%20ASSUMPTIONS.md 3 | 4 | 5 | ## 3 GOALS AND ASSUMPTIONS 6 | ## 3 目标和假设 7 | 8 | Algorand allows users to agree on an ordered log of transactions, and achieves two goals with respect to the log: 9 | Algorand允许用户就交易的有序日志达成一致，并在日志方面实现两个目标： 10 | 11 | **Safety goal.** With overwhelming probability, all users agree on the same transactions. 12 | More precisely, if one honest user accepts transaction A (i.e., it appears in the log), then any future transactions accepted by other honest users will appear in a log that already contains A. 13 | This holds even for isolated users that are disconnected from the network—e.g., by Eclipse attacks [28]. 14 | 15 | **安全目标** 极大的概率下，所有用户会对同样的交易达成一致。 16 | 更具体地说，如果一个诚实的用户接受交易A（即它出现在日志中），那么其他诚实用户接受的任何未来交易都将出现在已经包含A的日志中。 17 | 即使对于被迫与网络断开连接的孤立用户，例如被Eclipse攻击[28]，也是如此。 18 | 19 | 20 | **Liveness goal.** In addition to safety, Algorand also makes progress (i.e., allows new transactions to be added to the log) under additional assumptions about network reachability that we describe below. 21 | Algorand aims to reach consensus on a new set of transactions within roughly one minute. 22 | **活性目标** 除了安全性外，Algorand还在下面描述的有关网络可达性的其他假设下取得进展（即允许将新事务添加到日志中）。 23 | Algorand的目标是在大约一分钟内就新的交易达成共识。 24 | 25 | 26 | **Assumptions.** Algorand makes standard cryptographic assumptions such as public-key signatures and hash functions. 27 | Algorand assumes that honest users run bug-free software. 28 | As mentioned earlier, Algorand assumes that the fraction of money held by honest users is above some threshold h (a constant greater than 2/3), but that an adversary can participate in Algorand and own some money. 29 | We believe that this assumption is reasonable, since it means that in order to successfully attack Algorand, the attacker must invest substantial financial resources in it. 30 | Algorand assumes that an adversary can corrupt targeted users, but that an adversary cannot corrupt a large number of users that hold a significant fraction of the money (i.e., the amount of money held by honest, non-compromised users must remain over the threshold). 31 | 32 | **假设** Algorand基于标准的密码学的假设，如公钥签名和散列函数。 33 | Algorand也假设诚实的用户运行着无错软件。 34 | 如前所述，Algorand假设诚实用户持有的资金占比高于某个阈值h（大于2/3的常数），但攻击者可以参与Algorand并拥有一些资金。 35 | 我们认为这种假设是合理的，因为这意味着为了成功攻击Algorand，攻击者必须投入大量财力。 36 | Algorand假设攻击者可以破坏目标用户，但是对手不能破坏持有相当大部分资金的大量用户（即，诚实的，未受到损害的用户持有的资金量必须超过阈值）。 37 | 38 | 39 | To achieve liveness, Algorand makes a “strong synchrony” assumption that most honest users (e.g., 95%) can send messages that will be received by most other honest users (e.g., 95%) within a known time bound. 40 | This assumption allows the adversary to control the network of a few honest users, but does not allow the adversary to manipulate the network at a large scale, and does not allow network partitions. 41 | 42 | 为了实现活性，Algorand提出了一个“强同步”假设，即大多数诚实用户（例如95％）可以在已知的时间范围内发送消息给大多数其他诚实用户（例如95％）。 43 | 这种假设允许攻击者控制一些诚实用户的网络，但不允许攻击者大规模操纵网络，并且不允许网络分区。 44 | 45 | 46 | Algorand achieves safety with a “weak synchrony” assumption: the network can be asynchronous (i.e., entirely controlled by the adversary) for a long but bounded period of time (e.g., at most 1 day or 1 week). 47 | After an asynchrony period, the network must be strongly synchronous for a reasonably long period again (e.g., a few hours or a day) for Algorand to ensure safety. 48 | More formally, the weak synchrony assumption is that in every period of length b (think of b as a day or a week), there must be a strongly synchronous period of length s < b (an s of a few hours suffices). 49 | 50 | Algorand 可以在“弱同步”假设下实现安全性：网络可以在很长但有限的时间段内（例如最多1天或1周）是异步的（即完全由对手控制）。 51 | 在异步时期之后，网络必须在足够长的一段时间内（例如几个小时或一天）保持强同步，以确保Algorand的安全。 52 | 53 | 54 | Finally, Algorand assumes loosely synchronized clocks across all users (e.g., using NTP) in order to recover liveness after weak synchrony. 55 | Specifically, the clocks must be close enough in order for most honest users to kick off the recovery protocol at approximately the same time. 56 | If the clocks are out of sync, the recovery protocol does not succeed. 57 | 58 | 最后，Algorand假定在所有用户之间的时钟是宽松同步的（例如，使用NTP）以便在弱同步之后恢复活性。 59 | 具体来说，时钟必须足够接近，以便大多数诚实用户几乎同时启动恢复协议。 60 | 如果时钟不同步，则恢复协议不会成功。 61 | -------------------------------------------------------------------------------- /Papers/Algorand/4-OVERVIEW.md: -------------------------------------------------------------------------------- 1 | ## 4 OVERVIEW 2 | 3 | Algorand requires each user to have a public key. Algorand maintains a log of transactions, called a blockchain. Each transaction is a payment signed by one user’s public key transferring money to another user’s public key. Algorand grows the blockchain in asynchronous rounds, similar to Bitcoin. In every round, a new block, containing a set of transactions and a pointer to the previous block, is appended to the blockchain. In the rest of this paper, we refer to Algorand software running on a user’s computer as that user. 4 | 5 | Algorand要求每个用户都拥有一个公钥。 Algorand所维护的交易记录，称为区块链。每项交易都是由一个经用户签名的公钥支付到另一个用户的公钥上。Algorand以异步轮增长区块链，与比特币类似。在每一轮中，一个新区块将包含一组交易包和指向前序区块的指针。在本文的其余部分，我们将在用户计算机上运行的Algorand软件称为该用户。 6 | 译注：这里的异步指通一个区块里面的交易不是严格按时间排序的 7 | 8 | 9 | Algorand users communicate through a gossip protocol. The gossip protocol is used by users to submit new transactions. Each user collects a block of pending transactions that they hear about, in case they are chosen to propose the next block, as shown in Figure 1. Algorand uses BA⋆ to reach consensus on one of these pending blocks. 10 | 11 | Algorand用户通过流言（gossip）协议进行通信。流言协议被用户用来提交新的交易。如图1所示，每个用户收集一个他们发现的待处理交易块，以供他们选择提议下一个块。Algorand使用BA⋆对这些待处理的区块之一达成共识。 12 | 13 | ![figure 1](https://user-images.githubusercontent.com/22833166/38860679-563e9230-4263-11e8-91cd-6bbf3251ff68.jpg) 14 | 15 | 16 | Figure 1: An overview of transaction flow in Algorand. Algorand中的交易流概览 17 | 18 | 19 | 20 | BA⋆ executes in steps, communicates over the same gossip protocol, and produces a new agreed-upon block. BA⋆ can produce two kinds of consensus: final consensus and tentative consensus. If one user reaches final consensus, this means that any other user that reaches final or tentative consensus in the same round must agree on the same block value (regardless of whether the strong synchrony assumption held). This ensures Algorand’s safety, since this means that all future transactions will be chained to this final block (and, transitively, to its predecessors). Thus, Algorand confirms a transaction when the transaction’s block (or any successor block) reaches final consensus. On the other hand, tentative consensus means that other users may have reached tentative consensus on a different block (as long as no user reached final consensus). A user will confirm a transaction from a tentative block only if and when a successor block reaches final consensus. 21 | 22 | BA⋆是逐步执行的，它通过同一个gossip协议层进行通信，并产生一个新的共识区块。BA⋆可以产生两种共识：最终共识和暂定共识。如果一个用户达成最终共识，这意味着在同一轮中达成最终或暂定共识的任何其他用户必须就相同的区块价值达成一致（不管强同步假设是否成立）。这确保了Algorand的安全性，因为这意味着所有未来的交易都将被链接到这个最后的区块（并且传递到其前置任务）。因此，当交易的区块（或任何后继区块）达到最终共识时，Algorand才确认交易。另一方面，暂定共识意味着其他用户可能在不同的区块达成暂定共识（只要没有用户达成最终共识）。 只有当后继区块达成最终共识时，用户才会确认来自暂定区块的交易。 23 | 译注：这里的强同步指的是诚实节点可以在有限的时间内能够沟通 24 | 25 | 26 | BA⋆ produces tentative consensus in two cases. First, if the network is strongly synchronous, an adversary may, with small probability, be able to cause BA⋆ to reach tentative consensus on a block. In this case, BA⋆ will not reach consensus on two different blocks, but is simply unable to confirm that the network was strongly synchronous. Algorand will eventually (in a few rounds) reach final consensus on a successor block, with overwhelming probability, and thus confirm these earlier transactions. 27 | 28 | BA⋆在两种情况下中产生暂定共识。首先，如果网络强同步的，攻击者可能以较小的概率使BA⋆在一个区块上达成暂定共识。在这种情况下，BA⋆不会在两个不同的区块上达成共识，但也无法简单的确定网络是否是强同步的。 Algorand最终（在几轮中）将以最大的可能性在后续区块上达到最终的共识，进而来确认先前的交易。 29 | 30 | 31 | 32 | The second case is that the network was only weakly synchronous (i.e., it was entirely controlled by the adversary, with an upper bound on how long the adversary can keep control). In this case, BA⋆ can reach tentative consensus on two different blocks, forming multiple forks. This can in turn prevent BA⋆ from reaching consensus again, because the users are split into different groups that disagree about previous blocks. To recover liveness, Algorand periodically invokes BA⋆to reach consensus on which fork should be used going forward. Once the network regains strong synchrony, this will allow Algorand to choose one of the forks, and then reach final consensus on a subsequent block on that fork. 33 | 34 | 第二种情况是网络只是弱同步的（即它完全由攻击者控制，但攻击者只能够在有限的时间里保持对网络的控制）。在这种情况下，BA⋆可以在两个不同的区块上达成暂定共识，形成多个分叉。 这反而可以阻止BA⋆再次达成共识，因为用户按照对前序区块有分歧的形式被分成不同的组。为了恢复活性（Liveness），Algorand定期调用BA⋆来选择应该使用哪个分叉来向前达成共识。一旦网络恢复强同步性，将允许Algorand选择其中一个分叉，然后就在该分叉的后续区块上达成最终共识。 35 | 36 | 37 | 38 | We now describe how Algorand’s components fit together. 39 | 40 | 现在，我们介绍Algorand的组件如何组合在一起。 41 | 42 | 43 | 44 | **Gossip protocol.** Algorand implements a gossip network (similar to Bitcoin) where each user selects a small random set of peers to gossip messages to. To ensure messages cannot be forged, every message is signed by the private key of its original sender; other users check that the signature is valid before relaying it. To avoid forwarding loops, users do not relay the same message twice. Algorand implements gossip over TCP and weighs peer selection based on how much money they have, so as to mitigate pollution attacks. 45 | 46 | **流言协议.** Algorand实现了流言（Gossip）网络（类似于比特币），在这里，每个用户都随机选择很小一部分节点来将消息传播出去。为确保消息不被伪造，每个消息都由其原始发件人用私钥签名; 其他用户在转发之前要检查签名是否有效。为避免转发循环，用户不会转发相同的消息两次。 Algorand通过TCP实现了流言协议，并基于他们拥有的钱来权衡节点的选择，从而减轻污染攻击。 47 | **译注：** 这里的污染典型的就是女巫攻击 48 | 49 | **Block proposal (§6).** All Algorand users execute cryptographic sortition to determine if they are selected to propose a block in a given round. We describe sortition in §5, but at a high level, sortition ensures that a small fraction of users are selected at random, weighed by their account balance, and provides each selected user with a priority, which can be compared between users, and a proof of the chosen user’s priority. Since sortition is random, there may be multiple users selected to propose a block, and the priority determines which block everyone should adopt. Selected users distribute their block of pending transactions through the gossip protocol, together with their priority and proof. To ensure that users converge on one block with high probability, block proposals are prioritized based on the proposing user’s priority, and users wait for a certain amount of time to receive the block. 50 | 51 | **区块提议（§6）.** 所有Algorand用户执行密码学的抽签以确定他们是否被选择在给定的轮次中提议一个块。 我们在§5中会详细介绍抽签，但是在较高层次上可以理解为，根据用户帐户余额的权重，随机抽选出一小部分用户，并为每个选定的用户提供可以在用户与用户之间进行比较的优先级以及所选用户的优先权的证明。由于抽签是随机的，因此可能有多个用户被选择来提议一个区块，优先级将决定每个人应采用哪个区块。选定的用户通过流言协议分发他们待处理的交易区块以及他们的优先权和证明。为了确保用户以较高的概率收敛到一个区块，区块提议的优先级基于提议用户的优先级，用户等待一定的时间后来接收区块。 52 | 53 | 54 | 55 | **Agreement using BA⋆ (§7).** Block proposal does not guarantee that all users received the same block, and Algorand does not rely on the block proposal protocol for safety. To reach consensus on a single block, Algorand uses BA⋆. Each user initializes BA⋆ with the highest-priority block that they received. BA⋆ executes in repeated steps, illustrated in Figure 2. Each step begins with sortition (§5), where all users check whether they have been selected as committee members in that step. Committee members then broadcast a message which includes their proof of selection. These steps repeat until, in some step of BA⋆, enough users in the committee reach consensus. (Steps are not synchronized across users; each user checks for selection as soon as he observes the previous step had ended. ) As discussed earlier, an important feature of BA⋆ is that committee members do not keep private state except their private keys, and so can be replaced after every step, to mitigate targeted attacks on them. 56 | 57 | **使用BA⋆协议（§7）达成共识.** 区块提议并不保证所有用户都收到相同的区块，并且Algorand不依赖区块提议协议以确保安全。为了达成一个单独区块的共识，Algorand使用BA⋆。每个用户使用他们收到的优先级最高的区块来初始化BA⋆。BA⋆以重复的步骤执行，如图2所示。每个步骤都从抽签（§5）开始，所有用户都会检查他们是否在该步骤中被选为委员会成员。委员会成员随后广播了一条包含他们被选择的证明的信息。重复这些步骤直到在BA⋆的某个步骤中，委员会中有足够的用户达成共识。 （步骤在用户之间不同步；每当用户观察到前一步骤结束时，每个用户都会检查是否被选择。）如前所述，BA⋆的一个重要特征是委员会成员除私钥以外不保留私有状态，因此可以在每一步后更换，以减轻对它们的有针对性的攻击。 58 | 59 | 60 | ![figure 2](https://user-images.githubusercontent.com/22833166/38860743-7e6e6334-4263-11e8-922e-5fa6af6c09f4.jpg) 61 | 62 | Figure 2: An overview of one step of BA⋆. To simplify the figure, each user is shown twice: once at the top of the diagram and once at the bottom. Each arrow color indicates a message from a particular user. 63 | 64 | 图2：BA⋆一个步骤的概述。为了简化该图，每个用户都只显示两次：一次位于图顶部，一次位于底部。 每个箭头的颜色表示来自特定用户的消息。 65 | 66 | 67 | 68 | **Efficiency.** When the network is strongly synchronous, BA⋆ guarantees that if all honest users start with the same initial block (i.e., the highest priority block proposer was honest), then BA⋆ establishes final consensus over that block and terminates precisely in 4 interactive steps between users. Under the same network conditions, and in the worst case of a particularly lucky adversary, all honest users reach consensus on the next block within expected 13 steps, as analyzed in Appendix C. 69 | 70 | **效率.** 当网络是强同步时，BA⋆保证如果所有诚实用户都从相同的初始区块开始（也就是最高优先级区块提议者是诚实的），那么BA⋆会在该块上建立最终共识并且在会用户之间恰好交互四次后终结。在相同的网络条件下，并且在最坏的情况下，即便出现了特别幸运的攻击者，也能保证所有诚实的用户在预期的13个步骤内达成对下一个块的共识，具体参看附录C中的分析。 71 | -------------------------------------------------------------------------------- /Papers/Algorand/6-BLOCK PROPOSAL.md: -------------------------------------------------------------------------------- 1 | ## 6 BLOCK PROPOSAL 2 | 3 | ## 6 区块提议 4 | 5 | To ensure that some block is proposed in each round, Algorand sets the sortition threshold for the block-proposal role, τ proposer , to be greater than 1 (although Algorand will reach consensus on at most one of these proposed blocks). Appendix B proves that choosing τ proposer = 26 ensures that a reasonable number of proposers (at least one, and no more than 70, as a plausible upper bound) are chosen with very high probability (e.g., 1−10 −11 ). 6 | 7 | 为了确保每轮都有一些区块被提出，Algorand设置了作为区块提议者的抽签阈值τ\_PROPOSER，要大于1，(尽管Algorand会在最多一个被提议的区块中达到共识)。附录B证明了选择τ\_PROPOSER=26的时候(最少，最多是70上界)可以确保能够被高概率的选出(例如 1-10^-11) 8 | 9 | **Minimizing unnecessary block transmissions.** One risk of choosing several proposers is that each will gossip their own proposed block. For a large block (say, 1 MByte), this can incur a significant communication cost. To reduce this cost, the sortition hash is used to prioritize block proposals: For each selected sub-user 1,...,j of user i, the priority for the block proposal is obtained by hashing the (verifiably random) hash output of VRF concatenated with the sub-user index. The highest priority of all the block proposer’s selected sub-users is the priority of the block. 10 | 11 | **减少不必要的块传输。** 选择几个提议者的风险是每个人都会gossip他们自己的提议块。 对于大块（比如1兆字节），这可能会产生显着的通信成本。 为了降低这种成本，抽签hash被用来优化区块提议：对于每个用户i被选定的的子用户1...j，块提议的优先级是通过哈希VRF的output hash的输出再链接上子用户index。 所有块提议者的被选择的子用户的最高优先级是这个块的优先级。 12 | 13 | Algorand users discard messages about blocks that do not have the highest priority seen by that user so far. Algorand also gossips two kinds of messages: one contains just the priorities and proofs of the chosen block proposers (from sortition), and the other contains the entire block, which also includes the proposer’s sortition hash, and proof. The first kind of message is small (about 200 Bytes), and propagates quickly through the gossip network. These messages enable most users to learn who is the highest priority proposer, and thus quickly discard other proposed blocks. 14 | 15 | Algorand用户抛弃有关该用户迄今为止看到的不是最高优先级的块的消息。 Algorand还gossip两种消息：一种仅包含所选块提议者的优先级和证明（来自抽签），另一块包含整个块，其中还包括提议者的分类哈希和证明。 第一种消息很小（约200字节），并通过gossip网络迅速传播。 这些消息使大多数用户能够了解谁是最高优先级的提议者，并因此迅速放弃其他提议的块。 16 | 17 | **Waiting for block proposals.** Each user must wait a cer- tain amount of time to receive block proposals via the gossip protocol. Choosing this time interval does not impact Algo- rand’s safety guarantees but is important for performance. Waiting a short amount of time will mean no received pro- posals. If the user receives no block proposals, he or she initializes BA⋆ with the empty block, and if many users do so, Algorand will reach consensus on an empty block. On the other hand, waiting too long will receive all block proposals but also unnecessarily increase the confirmation latency. 18 | 19 | **等待区块提议。**每个用户都必须等待一定的时间才能通过gossip协议接收块提议。 选择此时间间隔不会影响Algorand的安全保证，但对性能很重要。 等待很短的时间将意味着没有收到建议。 如果用户没有收到任何块提议，他或她会用空白块初始化BA⋆，如果有许多用户这样做，Algorand会在空块上达成一致。另一方面要是等太久又会造成没必要的延时。 20 | 21 | To determine the appropriate amount of time to wait for block proposals, we consider the plausible scenarios that a user might find themselves in. When a user starts waiting for block proposals for roundr, they may be one of the first users to reach consensus in round r −1. Since that user completed round r −1, sufficiently many users sent a message for the last step of BA⋆ in that round, and therefore, most of the network is at most one step behind this user. Thus, the user must somehow wait for others to finish the last step of BA⋆ from round r − 1. At this point, some proposer in round r that happens to have the highest priority will gossip their priority and proof message, and the user must somehow wait to receive that message. Then, the user can simply wait until they receive the block corresponding to the highest priority proof (with a timeout λ block , on the order of a minute, after which the user will fall back to the empty block). 22 | 23 | 为了确定等待分组建议的适当时间，我们考虑一个可能的场景。当一个用户开始等待第r轮的区块提议时，他们可能是在第r-1中第一批达到共识的人之一。 由于该用户完成了第r -1轮，所以足够多的用户在该轮中发送了BA⋆的最后一步的消息，因此，大多数网络中的其他用户最多落后于该用户一步。 因此，该用户必须等待其他人从第r-1轮完成BA⋆的最后一步。 此时，一些r轮中的提议者恰好具有最高优先级将gossip他们的优先级和证明，并且用户必须以某种方式等待接收该消息。 然后，用户可以简单地等待，直到他们收到对应于最高优先级证明的块（具有一个超时λ\_BLOCK，大约一分钟，之后用户将回退到空块）。 24 | 25 | It is impossible for a user to wait exactly the correct amount for the first two steps of the above scenario. Thus, Algorand estimates these quantities (λ stepvar , the variance in how long it takes different users to finish the last step of BA⋆, and λ priority , the time taken to gossip the priority and proof message), and waits for λ stepvar +λ priority time to identify the highest priority. §10 experimentally shows that these parameters are, conservatively, 5 seconds each. As mentioned above, Algorand would remain safe even if these estimates were inaccurate. 26 | 27 | 在上面的场景的前两个步骤中，用户不可能完全等待正确的数量。 因此，Algorand估计了这些数量（λ\_stepvar，不同用户完成BA⋆最后一步需要多长时间的差异，以及λ\_priority，gossip的优先级和证明的时间），并等待λ\_stepvar+λ\_priority时间到确定最高优先级。 §10通过实验表明，这些参数是保守的，每个参数5秒。 如上所述，即使这些估计值不准确，Algorand也会保持安全。 28 | 29 | **Malicious proposers.** Even if some block proposers are malicious, the worst-case scenario is that they trick different Algorand users into initializing BA⋆ with different blocks. This could in turn cause Algorand to reach consensus on an empty block, and possibly take additional steps in doing so. However, it turns out that even this scenario is relatively unlikely. In particular, if the adversary is not the highest pri- ority proposer in a round, then the highest priority proposer will gossip a consistent version of their block to all users. If the adversary is the highest priority proposer in a round, they can propose the empty block, and thus prevent any real transactions from being confirmed. However, this happens with probability of at most 1−h, by Algorand’s assumption that at least h > 2/3 of the weighted user are honest. 30 | 31 | **恶意的提议者。**即使某些块提议者是恶意的，最坏的情况是他们欺骗不同的Algorand用户使用不同的块来初始化BA⋆。 这可能会导致Algorand在空块达成共识，并可能采取额外措施。 然而，事实证明，即使这种情况相对不太可能。 特别是，如果攻击者不是一轮中最高优先级的提案者，那么最高优先级提案者会向其所有用户传送一致的版本。 如果攻击者是一轮中最高优先级的提议者，他们可以提出空白块，从而防止任何实际交易被确认。 然而，这种情况发生在 概率最多为1-h下，通过Algorand的假设至少h> 2/3的权益用户是诚实的。 -------------------------------------------------------------------------------- /Papers/Algorand/9-IMPLEMENTATION.md: -------------------------------------------------------------------------------- 1 | 9 2 | 3 | IMPLEMENTATION 4 | 5 | We implemented a prototype of Algorand in C++, consist- ing of approximately 5,000 lines of code. We use the Boost ASIO library for networking. Signatures and VRFs are im- plemented over Curve 25519 [6], and we use SHA-256 for a hash function. We use the VRF outlined in Goldberg et al [27: §4]. 6 | 7 | In our implementation each user connects to 4 random peers, accepts incoming connections from other peers, and gossips messages to all of them. This gives us 8 peers on average. We currently provide each user with an “address book” file listing the IP address and port number for every user’s public key. In a real-world deployment we imagine users could gossip this information, signed by their keys, or distribute it via a public bulletin board. This naïve design of the gossip protocol in our prototype implementation is po- tentially susceptible to Sybil attacks, since it does not prevent an adversary from joining the gossip network with a large number of identities. We leave the problem of implementing a Sybil-resistant gossip network to future work. 8 | 9 | One difference between our implementation and the pseu- docode shown in §7 lies in the BinaryBA⋆() function. The pseudocode in Algorithm 8 votes in the next 3 steps after reaching consensus. For efficiency, our implementation in- stead looks back to the previous 3 steps before possibly re- turning consensus in a future step. This logic produces equiv- alent results but is more difficult to express in pseudocode. 10 | 11 | Figure 4 shows the parameters in our prototype of Algo- rand; we experimentally validate the timeout parameters in §10. h = 80% means that an adversary would need to control 20% of Algorand’s currency in order to create a fork. By analogy, in the US, the top 0.1% of people own about 20% of the wealth [40], so the richest 300,000 people would have to collude to create a fork. 12 | 13 | λ priority should be large enough to allow block proposers to gossip their priorities and proofs. Measurements of mes- sage propagation in Bitcoin’s network [18] suggest that gossiping 1 KB to 90% of the Bitcoin peer-to-peer network takes about 1 second. We conservatively set λ priority to 5 seconds. 14 | 15 | λ block ensures that Algorand can make progress even if the block proposer does not send the block. Our experiments (§10) show that about 10 seconds suffices to gossip a 1 MB block. We conservatively set λ block to be a minute. 16 | 17 | λ step should be high enough to allow users to receive messages from committee members, but low enough to allow Algorand to make progress (move to the next step) if it does not hear from sufficiently many committee members. We conservatively set λ step to 20 seconds. We set λ stepvar , the estimated variance in BA⋆ completion times, to 10 seconds. 18 | -------------------------------------------------------------------------------- /Papers/Algorand/ABSTRACT.md: -------------------------------------------------------------------------------- 1 | * **Source:** https://people.csail.mit.edu/nickolai/papers/gilad-algorand-eprint.pdf 2 | * **TranStudy:** https://github.com/DAGfans/TranStudy/edit/master/Papers/Algorand/ABSTRACT.md 3 | 4 | 5 | 6 | # Algorand: Scaling Byzantine Agreements for Cryptocurrencies 7 | 8 | # Algorand: 可扩展的加密货币的拜占庭协议 9 | 10 | Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, Nickolai Zeldovich 11 | 12 | MIT CSAIL 13 | 14 | ## ABSTRACT 15 | 16 | ## 摘要 17 | 18 | > Algorand is a new cryptocurrency that confirms transactions with latency on the order of a minute while scaling to many users. 19 | Algorand ensures that users never have divergent views of confirmed transactions, even if some of the users are malicious and the network is temporarily partitioned. 20 | In contrast, existing cryptocurrencies allow for temporary forks and therefore require a long time, on the order of an hour, to confirm transactions with high confidence. 21 | Algorand uses a new Byzantine Agreement (BA) protocol to reach consensus among users on the next set of transactions. 22 | To scale the consensus to many users, Algorand uses a novel mechanism based on Verifiable Random Functions that allows users to privately check whether they are selected to participate in the BA to agree on the next set of transactions, and to include a proof of their selection in their network messages. 23 | In Algorand’s BA protocol, users do not keep any private state except for their private keys, which allows Algorand to replace participants immediately after they send a message. 24 | This mitigates targeted attacks on chosen participants after their identity is revealed. 25 | We implement Algorand and evaluate its performance on 1,000 EC2 virtual machines, simulating up to 500,000 users. 26 | Experimental results show that Algorand confirms transactions in under a minute, achieves 125×Bitcoin’s throughput, and incurs almost no penalty for scaling to more users. 27 | 28 | > Algorand是一种新型的加密货币，在扩展到大量用户的情况下，确认交易的延迟时间仅有一分钟的规模。 29 | Algorand确保用户永远不会对已确认的交易产生分歧，即使某些用户是恶意的并且网络被临时分区。 30 | 相比之下，现有的加密货币允许产生临时分叉，因此需要很长时间（大约一小时）才可以较高的可信度确认交易。 31 | Algorand使用新的拜占庭协议（Byzantine Agreement， BA）在下一组交易中达成用户之间的共识。 32 | 为了将共识扩展到很多用户，Algorand使用基于可验证随机函数(Verifiable Random Functions)的新机制，允许用户私下检查他们是否被选择参与BA以确认下一组交易，并且在他们的网络消息中包含他们的选择的证明。 33 | 在Algorand的BA协议中，用户不保留除私钥以外的任何私有状态，因此允许Algorand在发送消息后立即替换参与者。 34 | 在选定的参与者身份曝光后，也可以缓解针对它们的攻击。 35 | 我们实现了Algorand并评估了其在1,000个EC2虚拟机上的性能，以模拟多达500,000用户。 36 | 实验结果显示，Algorand在不到一分钟的时间内就确认了交易，达到了125倍比特币的吞吐量，并且几乎不会因为扩展到更多用户而受影响。 37 | -------------------------------------------------------------------------------- /Papers/Avalanche/1 Introduction.md: -------------------------------------------------------------------------------- 1 | ## 1 Introduction 2 | ## 1 介绍 3 | 4 | Achieving agreement among a set of distributed hosts lies at the core of countless applications, ranging from Internet-scale services that serve billions of people [12, 30] to cryptocurrencies worth billions of dollars [1]. 5 | 在一组分布式主机之间达成协议是无数应用程序的核心，从为数十亿人[12,30]提供服务的互联网模式服务到价值数十亿美元的加密货币[1]。 6 | To date, there have been two main families of solutions to this problem. 7 | 到目前为止，已经有两种主要的解决方案来解决这个问题。 8 | Traditional consensus protocols rely on all-to-all communication to ensure that all correct nodes reach the same decisions with absolute certainty. 9 | 传统的共识协议依赖于所有节点间通信，以确保所有正确的节点可以绝对确定地实现相同的决策。 10 | Because they require quadratic communication overhead and accurate knowledge of membership, they have been difficult to scale to large numbers of participants. 11 | 因为它们需要二次通信开销和准确的成员资格认知，所以参与者很难大量扩展。 12 | 13 | On the other hand, Nakamoto consensus protocols [9, 24, 25, 34, 40–43, 49–51] have become popular with the rise of Bitcoin. 14 | 另一方面，Nakamoto共识协议[9,24,25,34,40-43,49-51]随着比特币的兴起而变得流行。 15 | These protocols provide a probabilistic safety guarantee: 16 | 这些协议提供了概率安全保证： 17 | Nakamoto consensus decisions may revert with some probability $\epsilon $. 18 | Nakamoto共识决策可能以某个概率$\epsilon $恢复。 19 | 20 | A protocol parameter allows this probability to be rendered arbitrarily small, enabling high-value financial systems to be constructed on this foundation. 21 | 协议参数允许这种可能性被表示为任意小，而在这个基础上构建高价值的金融系统。 22 | This family is a natural fit for open, permissionless settings where any node can join the system at any time. 23 | 该系列非常适合开放，无权限设置，任何节点都可以随时加入系统。 24 | Yet, these protocols are quite costly, wasteful, and limited in performance. 25 | 然而，这些协议非常昂贵，浪费并且性能有限。 26 | By construction, these protocols cannot quiesce: 27 | 通过构建，这些协议无法停止： 28 | their security relies on constant participation by miners, even when there are no decisions to be made. 29 | 即使没有做出决定，他们的安全也依赖于矿工的不断参与。 30 | Bitcoin currently consumes around 63.49 TWh/year [22], about twice as all of Denmark [15]. 31 | 比特币目前消耗约63.49TWh/年[22]，约为丹麦每年消耗的两倍[15]。 32 | Moreover, these protocols suffer from an inherent scalability bottleneck that is difficult to overcome through simple reparameterization [18]. 33 | 此外，这些协议存在固有的可扩展性瓶颈，难以通过简单的重设参数来克服[18]。 34 | 35 | This paper introduces a new family of consensus protocols. 36 | 本文介绍了一个新的共识协议系列。 37 | Inspired by gossip algorithms, this new family gains its safety through a deliberately metastable mechanism. 38 | 受到gossip算法的启发，这个新系列的协议通过使自己故意处于亚稳态机制而获得了安全性。 39 | Specifically, the system operates by repeatedly sampling the network at random, and steering the correct nodes towards the same outcome. 40 | 具体而言，系统通过在网络上重复采样来进行随机操作，并指导正确的节点朝向相同的结果。 41 | Analysis shows that metastability is a powerful, albeit non-universal, technique: 42 | 分析表明，尽管没有普及，亚稳态机制仍是一种强大的技术。 43 | it can move a large network to an irreversible state quickly, though it is not always guaranteed to do so. 44 | 它可以将大型网络快速移动到不可逆转的状态，但并不能一直保证可以这样做。 45 | 46 | Similar to Nakamoto consensus, this new protocol family provides a probabilistic safety guarantee, using a tunable security parameter that can render the possibility of a consensus failure arbitrarily small. 47 | 与Nakamoto共识类似，这个新协议系列提供了一定概率的安全保证，使用可调整的安全参数，可以使共识失败的可能性变成任意小。 48 | Unlike Nakamoto consensus, the protocols are green, quiescent and efficient; 49 | 与Nakamoto共识不同，该协议是绿色，静止和高效的; 50 | they do not rely on proof-of-work [23] and do not consume energy when there are no decisions to be made. 51 | 他们不依赖于工作量证明[23]，并且在没有做出决定时不消耗能量。 52 | The efficiency of the protocols stems from two sources: 53 | 协议的效率源于两个来源： 54 | they require communication overheads ranging from $O(knlogn)$ to $O(kn)$ for some small security parameter $k$, and they establish only a partial order among dependent transactions. 55 | 它们需要通信开销的范围从$O(knlogn)$到$O(kn)$对于某个小的安全参数$k$来说，并且它们在独立的交易之间只建立一个偏序。 56 | 57 | This combination of the best features of traditional and Nakamoto consensus involves one significant tradeoff: 58 | liveness for conflicting transactions. 59 | 传统和Nakamoto共识最佳特征的这种组合涉及一个重要的权衡：冲突交易的活跃性。 60 | Specifically, the new family guarantees liveness only for virtuous transactions, i.e. those issued by correct clients and thus guaranteed not to conflict with other transactions. 61 | 具体而言，新协议系列仅保证良性交易的活性，即由正确的客户发布的交易，从而保证不与其他交易发生冲突。 62 | In a cryptocurrency setting, cryptographic signatures enforce that only a key owner is able to create a transaction that spends a particular coin. 63 | 在加密货币设置中，加密签名强制只有密钥所有者能够创建花费特定货币的交易。 64 | Since correct clients follow the protocol as prescribed, they are guaranteed both safety and liveness. 65 | 由于正确的用户遵循规定的协议，他们的安全和活性均被保证。 66 | In contrast, the protocols do not guarantee liveness for rogue transactions, submitted by Byzantine clients, which conflict with one another. 67 | 相比之下，协议并不保证拜占庭用户提交的流氓交易的活性，这些交易彼此冲突。 68 | Such decisions may stall in the network, but have no safety impact on virtuous transactions. 69 | 这样的决定可能使流氓交易在网络中停滞不前，但对良性交易没有安全影响。 70 | We show that this is a sensible tradeoff, and that resulting system is sufficient for building complex payment systems. 71 | 我们证明这是一个合理的权衡，并且由此产生的系统足以构建复杂的支付系统。 72 | 73 | Overall, this paper makes one significant contribu- tion: 74 | 总的来说，本文做出了重要贡献： 75 | a brand new family of consensus protocols suitable for cryptocurrencies, based on randomized sampling and metastable decision. 76 | 基于随机抽样和亚稳态决策的适用于加密货币的全新共识协议系列。 77 | The protocols provide a strong probabilistic safety guarantee, and a guarantee of liveness for correct clients. 78 | 这些协议提供了强大的概率安全保证，并保障了正确客户的活性。 79 | 80 | The next section provides intuition behind the new protocols, Section 3 provides proofs for safety and liveness, Section 4 describes a Bitcoin-like payment system, Section 5 evaluates the system, Section 6 presents related work, and finally, Section 7 summarizes our contributions. 81 | 下一节提供了新协议背后的思路，第3节提供了安全性和活性的证明，第4节描述了类比特币支付系统，第5节评估了系统，第6节介绍了相关工作，最后，第7节总结了我们的贡献。 82 | -------------------------------------------------------------------------------- /Papers/Avalanche/Abstract.md: -------------------------------------------------------------------------------- 1 | ## Abstract 2 | ## 摘要 3 | 4 | This paper introduces a new family of leaderless Byzantine fault tolerance protocols, built on a metastable mechanism. 5 | 这篇文章介绍了一个新的无领导拜占庭容错共识协议系列，基于亚稳态机制。 6 | These protocols provide a strong probabilistic safety guarantee in the presence of Byzantine adversaries, while their concurrent nature enables them to achieve 7 | high throughput and scalability. 8 | 这些协议在拜占庭敌人存在的情况下提供了安全保障,而他们的并发性使他们能够实现高吞吐量和可扩展性。 9 | Unlike blockchains that rely on proof-of-work, they are quiescent and green. 10 | 不像依赖工作量证明的区块链,它们是静止的和绿色的。 11 | Surprisingly, unlike traditional consensus protocolswhich require $O(n^2)$ communication, their communication complexity ranges from $O(knlogn)$ to $O(kn)$ for some security parameter $k\ll n$. 12 | 令人惊讶的是，与需要$O(n^2)$复杂度通信的传统共识协议不同，它们的通信复杂度范围从$O(knlogn)$到$O(kn)$，对于某些安全性参数$k\ll n$。 13 | 14 | The paper describes the protocol family, instantiates it in three separate protocols, analyzes their guarantees, and describes how they can be used to construct the core of an internet-scale electronic payment system. 15 | 文章描述了协议族，使它在三个独立的协议中实例化，分析他们的保章机制，并且描述如何使用它们来构建互联网规模的电子支付系统的核心。 16 | The system is evaluated in a large scale deployment. 17 | 系统在大规模调度中进行评估。 18 | Experiments demonstrate that the system can achieve high throughput (1300 tps), provide low confirmation latency (4 sec), and scale well compared to existing systems that deliver similar functionality. 19 | 实验表明与提供类似功能的现有系统相比，该系统能实现高吞吐量(1300 tps)，提供低证明延迟(4秒)和扩展良好。 20 | For our implementation and setup, the bottleneck of the system is in transaction verification. 21 | 对于我们的实施和设置，系统的瓶颈在于交易验证。 22 | -------------------------------------------------------------------------------- /Papers/DagCoin/0-Abstract.md: -------------------------------------------------------------------------------- 1 | 原文: https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf 2 | 作者: [Sergio Demian Lerner](https://twitter.com/sdlerner) 3 | 4 | # DagCoin Draft 5 | ## Abstract 6 | ## 摘要 7 | DagCoin is a cryptocurrency design that attempts to be highly decentralized by merging the concepts of transactions and blocks and making each user that transact a miner. 8 | Each transaction carries a proof-or-work and references one or more previous transactions. 9 | The resulting authenticated data structure is a Direct Acyclic Graph (DAG) of transactions where each transaction “confirms” one or more previous transactions. 10 | The confirmation security of a transaction is measured in accumulated amount of proof-of-work referencing the transaction. 11 | In this paper we present the DagCoin design, solve the double-spend problem and show several optimizations to aid for an efficient implementation. 12 | 13 | 14 | DagCoin 是一个高度去中心化的加密货币的设计，其整合了交易和区块的概念并能让每一个用户成为矿工. 15 | 每笔交易都携带一个工作量证明并引用一个或者多个之前的交易. 16 | 生成的已认证的数据结构是由交易组成有向无环图（DAG），其中每笔交易 “确认” 一笔或者多笔之前的交易. 17 | 交易的确认安全性是以引用该交易的累计工作量证明来衡量的. 18 | 在本论文中，我们将介绍 DagCoin 的设计，解决双花问题，并展示几个优化让实现更有效率. 19 | 20 | -------------------------------------------------------------------------------- /Papers/DagCoin/1-Introduction.md: -------------------------------------------------------------------------------- 1 | 原文: https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf 2 | 3 | DagCoin is a cryptocurrency design that merges the concepts of transactions and blocks and making each user a miner. 4 | Each transaction carries a proof-or-work and references one or more previous transactions. 5 | The resulting authenticated data structure is a Direct Acyclic Graph (DAG) of transactions where each transaction “confirms” one or more previous transactions. 6 | The confirmation security of a transaction is measured in accumulated amount of proof-of-work referencing the transaction. 7 | This structure is better suited for a cryptocurrency without subsidy (such as a side-chain), since the cost of reversal of a transaction can be easily measured, where in merged-mining the reversal cost depends on the good will of the non-merged hashing power. 8 | 9 | DagCoin 是一个高度去中心化的加密货币的设计，其整合了交易和区块的概念并能让每一个用户成为矿工. 10 | 每笔交易都携带一个工作量证明并引用一个或者多个之前的交易. 11 | 生成的已认证的数据结构是由交易组成有向无环图（DAG），其中每笔交易 “确认” 一笔或者多笔之前的交易. 12 | 交易的确认安全性是以引用该交易的累计工作量证明来衡量的. 13 | 这个结构更适合没有补贴的加密货币（例如侧链），因为逆转交易的成本能很简单地测量，即逆转恶意的已联合的挖矿取决于善意的未联合的算力. 14 | 15 | (*译注：这里的补贴其实指的是挖矿奖励或者手续费，参见 https://blockstream.com/sidechains.pdf subsidy 的有关章节*) 16 | 17 | One of the problems with the DAG approach is how to limit the maximum cut of the generated DAG 18 | or, in other words, how to prevent all new transactions from referencing the same set of parent transactions, and degenerating the DAG into a star graph. 19 | The DAG must not increase in “width”, and it must “look” more like a yarn under microscope. 20 | I will call this structure a DAG-chain. 21 | 22 | DAG 方案的其中一个问题怎样限制生成的 DAG 中最大分叉的规模或者换句话说怎样阻止所有新交易引用同样的一组父交易，导致把 DAG 降级为一张星图. 23 | DAG 一定不能增加 “宽度”，并且必须“看上去” 更像一个在显微镜下的纱线（yarn）. 24 | 我将称这个结构为 DAG - 链. 25 | 26 | 27 | ![dagcoin-1](https://user-images.githubusercontent.com/22833166/35629520-cb1f9c86-06d9-11e8-9914-f8918476265f.jpg) 28 | 29 | A DAG-chain can be informally defined as DAG that:   30 | 一个 DAG - 链可以被非正式地定义为 DAG 需要满足： 31 | 32 | - After taking all border (non-parent) nodes k times, it becomes a chain 33 | - 在被所有的边缘（非父）节点引用 k 次后，它成为一条链 34 | (译注: 这里的边缘节点就是叶子节点，可以理解为至少要有K个分支） 35 | - The resulting chain length is proportional to the original node count by a factor close to 2k. 36 | - 生成的链的长度会和原始节点的数量保持因子为大约2k的比例 37 | (译注: 最多有2k个分支） 38 | - If the DAG has more than 2k nodes, you can cut it in two separate DAGs, and the same properties hold for each half (each half having a factor k which is close to the original k factor). 39 | - 如果 DAG 有超过两千节点，你可以将其拆分成两个独立的 DAG，并且每一半保持同样的属性（每一半的因子 k 是和原始 k 因子接近的） 40 | 41 | To be able to create a DAG-chain the protocol must prevent users from choosing old transactions to extend the DAG. 42 | Merging branches should be incentivized, but not too much such that users merge the same branches over and over. 43 | The problem of spam is of less importance, as no transaction can get a “free ride” in a block. 44 | We show that the election of an adequate data structure allows the DAG-chain to be formed, but it requires us to change how we think about double-spends. 45 | 46 | 要能创建 DAG - 链，协议必须阻止用户选择旧的交易去拓展 DAG. 47 | 合并分支应该被激励，但不能太多以至于用户会反复地合并同一个分支. 48 | 垃圾交易的问题不是那么重要，因为没有交易能在区块中 “搭顺风车”（ _译注：交易手续费_ ）. 49 | 我们发现，选择一个合适的数据结构可以形成 DAG 链，但这需要我们改变我们对于双重花费的看法. 50 | 51 | 52 | 53 | The premises used to design the DagCoin cryptocurrency are the following: 54 | 设计 DagCoin 加密货币的前提有： 55 | 56 | PREMISE: _The cryptocurrency network benefits from creating a DAG-chain growing as “thin” (low k) as possible._ 57 | 前提： _加密货币网络受益于创建一个尽可能越来越 “瘦”（低 k）的 DAG - 链._ 58 | 59 | In other words, having the average maximal cut as low as possible. 60 | Referencing many previous 61 | transactions (high out degree) can make the DAG thinner only if the following transactions reference the transaction with high out degree, but are themselves of low out degree. 62 | The DAG requires high out degree some times, but low out degree another times. 63 | 64 | 换句话说，让平均最大分支尽可能的小. 65 | 某笔交易若引用了多笔交易 (高出度), 唯一能使DAG变瘦的方案是该交易被很多交易引用，但这些交易本身的出度很低. 66 | DAG 有时需要高出度, 有时又需要低出度. 67 | 68 | DagCoin tries to fulfill that premise, using an incentive structure such that: 69 | DagCoin 尝试使用如下激励来实现这个前提: 70 | 71 | - There is a benefit for users to reference as many previous transactions as possible 72 | - 尽可能多地引用之前的交易对用户来说是有利的 73 | - Referencing many previous transactions is incentivized only when there are many previous transactions unreferenced. 74 | - 只有存在许多未被引用的交易时, 引用许多之前的交易才是被激励的 75 | - There is no competition between users to reference a previous transaction. 76 | - 用户之间没有引用之前交易的竞争 77 | -------------------------------------------------------------------------------- /Papers/DagCoin/2-Safely accepting Double-spends in the DAG-chain.md: -------------------------------------------------------------------------------- 1 | 原文: https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf 2 | 3 | # Safely accepting Double-spends in the DAG-chain 4 | # 安全地接受 DAG 链中的双花 5 | 6 | In Bitcoin, a transaction in a valid block-chain can never be a double-spend, as double-spending violates a protocol rule. 7 | DagCoin allows two conflicting transactions to be included in the DAG-chain as long as the second does not references the first (over one or more hops). 8 | We assign each transaction a confirmation score. 9 | If two conflicting transactions appear, as more transactions are added to the DAG-chain, the number of confirmations of one of the two will increase, but the other will not. 10 | Each transaction adds one unit of confirmation. 11 | The score of a node without children is zero. 12 | The score of a referenced transaction is the sum of all transactions that recursively reference it (including double-spends). 13 | Whenever a transaction is added, it modifies the scores of all transactions recursively referenced by it. 14 | Whenever a transaction references a list of previous transactions, if there are two conflicting transactions, then the one with highest score prevails. 15 | If both have the same score, then the order of referencing establishes preferences over the conflicting transactions, such that the first transaction gets its score increased but any following double-spend will not. 16 | 17 | 在比特币中，有效区块链中是不可能存在双花交易的，因为双花违反协议规则. 18 | DagCoin 允许两个冲突交易包含在 DAG 链中，只要第二个交易不引用第一个（直接或者间接）. 19 | 我们为每笔交易分配一个确认分数. 20 | 如果出现两个相冲突的交易，随着更多的交易被添加到 DAG 链中，两个中的一个的确认数量将增加，而另一个不会. 21 | 每笔交易增加一个确认单位. 22 | 没有孩子的节点的分数是零. 23 | 引用交易的分数是递归引用的所有交易的总和（包括双花）. 24 | 无论何时添加交易，都会修改由其递归引用的所有交易的分数. 25 | 每当一笔交易引用一笔以前的交易时，如果有两笔冲突的交易，则以最高分为准. 26 | 如果两者都具有相同的分数，则用引用的顺序来建立冲突交易的优先级, 使得第一笔交易分数增加但是任何后续的双花则不会. 27 | 28 | ![Figure 1](https://user-images.githubusercontent.com/22833166/35629720-4ff83404-06da-11e8-91bb-7fe5f72164db.png) 29 | 30 | > Figure 1 shows the DAG before a join transaction arrives and afterward. 31 | Transactions 2 and 3 (in orange) are conflicting. 32 | The confirmation score is in brackets. 33 | We can see that even both transaction 2 and transaction 3 have a non-zero confirmation score, only one of them will increase over time.Honest nodes will never extend a transaction which is already referenced, so an attacker that wants to replace transaction 2 by transaction 10 must invest in proof-of-work at least the difference between the confirmation scores. 34 | This establishes a very precise bound on the double-spend security. 35 | 36 | > 图 1 显示了新加入的交易到达之前和之后的 DAG. 37 | 交易 2 和 3（橙色）有冲突. 38 | 确认分数在括号内. 39 | 我们可以看到，即使交易 2 和交易 3 都有一个非零的确认分数，但其中只有一个会随着时间的推移而增加. 40 | 诚实的节点永远不会扩展已经被引用的交易，所以攻击者想要用交易 10 替换交易 2, 则必须至少要投入确认分数差这么多工作证明. 41 | 这就确立了抵抗双花攻击的非常精确的安全边界. 42 | -------------------------------------------------------------------------------- /Papers/DagCoin/3-Preventing too many transactions merging too many transactions.md: -------------------------------------------------------------------------------- 1 | 原文: https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf 2 | 3 | # Preventing too many transactions merging too many transactions 4 | # 防止太多的交易合并太多的交易 5 | 6 | The core idea proposed is that each transaction commits to an authenticated forest of previous unreferenced transactions. 7 | To do so, it includes the value C(N), where C(i)=Commit(C(i-1) || T(i)), where T(i) is the hash of a transaction parent and C(0) is the empty string. 8 | These are simple recursive commitments so that C(N) allows the payer to reveal any number of parent hashes between 1 to N. 9 | The important decision is how many parents the commitment should reveal. 10 | Using the transaction as a header, the payer tries to find a proof of work with certain base difficulty (more on this base difficulty later). 11 | If the obtained a proof-of-work whose difficulty is 2^k times harder than the base difficulty, it will reveal and reference the first (k+1) nodes of the list. 12 | Half of the times a transaction will have a single parent, so only the first node T(N) will be revealed, by providing the complementary hash chain head (C(N-1)). 13 | One fourth of the times, two transactions will be referenced, by providing the hashes T(N), T(N-1) and C(N-2). 14 | 15 | 该提案的核心思想是，每个交易都提交一个以前未被引用的已认证的交易集。 16 | 为此，它包括值 C(N)，其中 C(i)=Commit(C(i-1) || T(i))，其中 T(i)是父交易的散列，C(0)是空字符串。 17 | 这些都是简单的递归提交，因此 C(N)允许支付方在 1 到 N 之间公开任意数量的父散列。 18 | 但重要的是要决定提交应公开多少父散列。 19 | 要使用这个交易作为头部，支付方需要试图找到满足某些基本难度的工作证明（以后这个基本难度会更大）。 20 | 如果获得了难度是基本难度 2^k 倍的工作证明，它将公开和引用列表的第 (k+1) 个节点。 21 | 通过提供剩余的散列链头 (C(N-1))，交易在一半的机会下的将拥有单个父节点，所以只公开第一个节点 T(N)。 22 | 四分之一的机会里，通过提供哈希值 T(N)，T(N-1) 和 C(N-2), 两个交易会被引用。 23 | 24 | 25 | This system provides a logarithm distribution in the amount of parents, with an average of 2. 26 | Also this method cannot be gamed, since referring more parents has a PoW cost. 27 | 28 | 这个系统提供了呈一个对数分布的父交易的数量，平均为 2. 29 | 这种方法不能被操纵，因为引用更多的父交易需要 PoW 成本。 30 | 31 | 32 | There should be an incentive to include as many references as possible in the authenticated branch. 33 | This can be achieved by several methods: 34 | 需要有一个激励, 让已认证的分支中包含尽可能多的引用。 35 | 这可以通过几种方法来实现： 36 | 37 | 1. Invalidating a transaction that has less references than what the PoW requires. 38 | 2. Incrementing the score of a transaction that has more revealed references. 39 | For instance, a transaction having K revealed references could add a fractional score of (K-1)/K to the transaction score. 40 | 41 | > 42 | 1. 如果少于 PoW 要求的引用, 则交易是无效的。 43 | 2. 增加有更多已公开引用的交易的分数。 44 | 例如，有 K 个已公开引用的交易可以增加 (K-1)/K 倍分数到交易分数上。 45 | -------------------------------------------------------------------------------- /Papers/DagCoin/4-Preventing Unbounded Cascade Updates to Confirmation Scores.md: -------------------------------------------------------------------------------- 1 | 原文: https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf 2 | 3 | # Preventing Unbounded Cascade Updates to Confirmation Scores 4 | # 防止无限级联更新确认分数 5 | 6 | Suppose that for each transaction we save an integer score that we update for each new transaction that references it directly or recursively. 7 | It is evident that the proposed data structure requires updating almost all previous confirmation scores each time a transaction is added. 8 | To reduce the workload, we use pointers and checkpoints. 9 | At a certain frequency the software chooses a transaction that references a high number of parent nodes. 10 | 11 | 假设对于每个交易，我们保存一个整数分数，每当有新的交易直接或递归地引用它时, 我们需要更新它。 12 | 显然, 每当一笔交易加入的时候, 提交的数据结构需要更新几乎所有之前的确认分数。 13 | 为了减少工作量，我们使用指针和检查点。 14 | 假设在某个频率上，软件选择一笔引用大量父节点的交易。 15 | 16 | 17 | ![Figure 2](https://user-images.githubusercontent.com/22833166/35630410-4e1f29ec-06dc-11e8-91a3-98c4354204f3.png) 18 | 19 | > Figure 2 show how a checkpoint is found. 20 | 21 | > 图 2 显示了如何找到检查点。 22 | 23 | Of course, not every past transaction could be reachable, as users may decide to never reference certain published transaction. 24 | However, the parent selection, with average out-degree 2, and low network latency, can guarantee that there will be frequent checkpoints referencing almost all previous transactions. 25 | 26 | 当然，并不是每一个过去的交易都是可以到达的，因为用户可能决定从不引用某个已发布的交易。 27 | 然而，在平均出度为 2 和低网络延迟的情况下, 父交易的选择可以保证将会有频繁的检查点引用几乎所有以前的交易。 28 | 29 | 30 | After a checkpoint is found, the software updates all nodes reachable from the checkpoint with a forward pointer to this checkpoint. 31 | A checkpoint has its own score counter, initially set to zero. 32 | When the update algorithm reaches a checkpoint node, it increments the counter and stops propagating backward. 33 | The score of a transaction is computed as the last stored score in the transaction plus the score of the pointed checkpoint. 34 | Checkpoints are considered as nodes on the DAG, so the same check- 35 | point finding algorithm can make checkpoints that refer to other forward checkpoints. 36 | After several continuous checkpoints, a checkpoints of a higher level is created referencing previous checkpoints, forming a skip-list. 37 | Using the skip-list it is possible to compute the score of a transaction in O(logN) 38 | where N is the number of transactions after it. 39 | Also, after a certain score has been reached, the wallet may decide not to update it anymore and consider it immutable, as in Bitcoin checkpoints. 40 | 41 | 找到检查点之后，软件会从指向的这个检查点的检查点开始更新所有可到达的节点。 42 | 每一个检查点有它自己的分数计数器，这个计数器初始化的时候被设置为 0。 43 | 当我们的更新算法到达一个检查点节点时，它会增加这个计数器并停止向后传播。 44 | 一笔交易的得分是由交易中最后存储的分数和被指向检查点的分数相加得到的。 45 | 这些检查点在 DAG 中被当作节点，所以同样的检查点查找算法也可以找到和之前的检查点有联系的检查点。 46 | 在一些连续的检查点之后，一个引用了之前所有检查点的更高等级的检查点就会被创建出来，这样就形成一个忽略列表。 47 | 使用这个忽略列表可以在 O(logN) 的复杂度下计算出一笔交易的分数，这里的 N 是这个检查点之后交易的数量。 48 | 同时，在达到一个确切的分数之后，钱包会决定不再更新它并把它当做不可变的，就像比特币中的检查点一样。 49 | 50 | -------------------------------------------------------------------------------- /Papers/DagCoin/5-Periodic re-computing to reduce computation load.md: -------------------------------------------------------------------------------- 1 | 原文: https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf 2 | 3 | # Periodic re-computing to reduce computation load 4 | # 定期重新计算以减小计算负载 5 | 6 | Even using checkpoints, computation load can be high. 7 | When a wallet detects a transaction whose destination address is owned, it will start tracking it to find out how deep it is confirmed. 8 | But computing the confirmation score using every new transaction that arrives is expensive. 9 | To reduce the load, the wallet can re-compute the score after a certain amount of accumulated proof-of-work has been received, creating arbitrary “blocks” of transactions. 10 | Each block is then processed separately to find all the parent transactions “inputs” of the block, and a score is added to each input. 11 | It’s important not to confuse the block inputs with Bitcoin’s UTXOs, DagCoin block inputs are not related with spending and represent block parent hashes (instead of a single patent hash). 12 | The number of inputs will depend on the network latency, but will be generally low and independent of the block size. 13 | For example, for a network with 10 tps, and 1 second of propagation latency, the block input set cardinality should be around 10. 14 | Then the set of inputs is processed. 15 | Figure 3 show a block and how the input set is constructed (not necessarily in the same way) by each wallet software. 16 | Every input has an accumulated score which is propagated to previous nodes. 17 | 18 | 虽然我们使用了检查点，但是计算成本依然很高。 19 | 当一个钱包检测到一笔交易的目标地址已经是自己拥有的地址时，它会开始追踪并找出这笔交易的确认深度。 20 | 但是计算每一笔新的交易的确认分数的成本是很高的。 21 | 为了减小这个计算开销，钱包可以等确认i数达到一个确切的累计工作量证明数量之后再进行计算分数，这样就创造了交易的任意『区块』。 22 | 每一个区块都会被分开处理并找到区块『输入』的所有父交易，并且每一个输入都会被添加一个分数。 23 | 将区块输入和比特币的 UTXO 的概念区分开来是很重要的，因为 DagCoin 的区块输入与花费和表示父区块的散列（而不是一个单个的父散列）并没有什么关系。 24 | 输入的数量取决于网络延迟，但是通常来说都会很低并且独立于区块的大小。 25 | 举个例子，对于一个 每秒交易量 为 10 以及传播延迟为 1 秒的网络来说，区块的输入集基数应该是 10 左右。 26 | 然后输入集就会被处理。 27 | 图表 3 展示了一个区块以及输入集是如何被每一个钱包软件构造出来的（没必要使用同样的方式）。 28 | 每一个输入都有一个累计分数，这个累计分数会被传播到之前的节点上。 29 | 30 | 31 | ![Figure 3](https://user-images.githubusercontent.com/22833166/35630516-97a52aee-06dc-11e8-8362-d109d7c0f32e.png) 32 | 33 | For instance, and to provide a comparison to Bitcoin, the wallet may consider 10K units of transaction PoW as equivalent 1 “block confirmation” and so pack 10K transactions into a block and re-compute the score every 10K transactions received. 34 | A better approach is to construct a block every N seconds, independent on the number of transactions in it. 35 | Note that if there are no transactions being performed after the monitored one, then the confirmation score does not change. 36 | This is a direct consequence of the nonexistence of a subsidy and Bitcoin will face the same problem if the price does increase constantly. 37 | 38 | 例如，对于比特币来说，钱包或许会认为 10000 个单位的交易工作量证明等于一个『区块确认』，所以它会将 10000 个交易打包进一个区块并对接收到的每 10000 笔交易再次计算分数。 39 | 一个更好的方法则是每 N 秒构造一个区块，这个 N 独立于区块中交易的数量。 40 | 要注意的一点是，如果被监控的交易之后没有发生任何新的交易那么确认分数就不会改变。 41 | 这就是没有经济激励最直接的结果，如果价格持续不断的增长的话，那么比特币也会面临同样的问题。 42 | 43 | 44 | -------------------------------------------------------------------------------- /Papers/DagCoin/6-Targeting a fixed transactions rate vs no maximum rate.md: -------------------------------------------------------------------------------- 1 | 原文: https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf 2 | 3 | # Targeting a fixed transactions/rate vs no maximum rate 4 | # 固定交易速率 VS 无最大交易速率 5 | 6 | As there are no free-rides for transactions, the transaction/rate is limited by existent deployed computing power and electricity cost. 7 | By time-stamping every transaction, one could dynamically adapt the difficulty of the proof-of-work to achieve more fixed rate. 8 | But if the difficulty of a transactions depends on the difficulty of the parent transactions, then there may be incentives to choose old parent transactions instead of new ones to reduce the PoW required, if the current rate is over the fixed rate. 9 | Just to be sure Moore's law does permit spamming in the future, one could embed a re-targeting rule such that every 18 months the difficulty is doubled. 10 | It seems preferable that the last M transactions (such as M=10K) of a certain transaction vote on an increase or decrease of the difficulty of the following transactions (with small step changes). 11 | Then users could vote more freely on how the network should work without having any immediate benefit to bias voting. 12 | This is a similar problem as the current Bitcoin block-chain increase problem: only miners can vote, because user votes are prone to Sybil attacks. 13 | In DagCoin, every user can vote, as long as it transact. 14 | 15 | 交易是有成本的，交易速率已经被现存计算资源和电力消耗牢牢的限制住了。 16 | 通过每一笔交易的时间戳，区块会动态地调整工作量证明的难度来实现更加稳定的速率。 17 | 但是如果一个交易的难度取决于它父交易难度的话，当当前的速率高于一个固定的速率时，那么系统就会激励这个交易选择老的父交易，而不是新的，因为这样就不需要工作量证明了。 18 | 可以肯定的是，摩尔定律在未来是会允许垃圾交易的，这个定律可以嵌入一个目标规则，比如每 18 个月难度会翻倍。 19 | 但是我们更愿意用一个确定的交易最近 M 笔交易（比如M=10K）来决定接下来的交易（只有很小的改变）的难度是增加还是减少。 20 | 因为这样用户不会从任何带有偏见的投票中获得直接的收益，那么用户就可以更自由的投票以决定整个网络应该如何运行。 21 | 当前比特币的区块链结构也面临同样的问题：只有矿工可以投票，因为用户投票容易被女巫攻击。 22 | 在 DagCoin 中，每一个交易过的用户都可以投票。 23 | 24 | -------------------------------------------------------------------------------- /Papers/DagCoin/7-Conclusion.md: -------------------------------------------------------------------------------- 1 | 原文: https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf 2 | 3 | # Conclusion 4 | # 结论 5 | 6 | We’ve presented a new cryptocurrency design based on a DAG structure where there are no fixed blocks and where each transaction carries its own proof of work. 7 | Also we’ve presented two optimizations that allow storing and dynamically updating the DAG-chain consuming low CPU resources. 8 | It must be noted however that the proposed DAG-coin cannot verify new transactions using only a subset of the block-chain, such as Bitcoin’s UTXO set. 9 | However, by storing the most recent transactions in a fast cache, and by using checkpoints where such that older transactions cannot be referenced, the system can be made as fast as Bitcoin, or faster. 10 | 11 | 我们提出了一个基于 DAG 结构的新的加密货币的设计，这个币没有固定的区块，并且它上面的每一笔交易都会为它自己做工作量证明。 12 | 同时我们还提出了两个优化方案，这两个优化方案可以允许存储并且仅仅消耗很少的 CPU 资源就可以更新 DAG-链。 13 | 但是我们要注意的是，当仅仅使用区块链的一个子集时，例如比特币的 UTXO, 这个币是无法验证新的交易， 14 | 然而通过将大部分最近的交易存储在一个快速缓存中，并使用那些更老的不能被引用的交易的检查点，这样就可以让这个系统和比特币一样快了，甚至更快。 15 | 16 | 17 | 18 | -------------------------------------------------------------------------------- /Papers/Inclusive/Abstract.md: -------------------------------------------------------------------------------- 1 | > Source: https://www.cs.huji.ac.il/~yoni_sompo/pubs/15/inclusive_full.pdf 2 | 3 | # Inclusive Block Chain Protocols 4 | # Inclusive 区块链协议 5 | 6 | Yoad Lewenberg1 , Yonatan Sompolinsky1, and Aviv Zohar1,2 7 | 8 | 1 The School of Engineering and Computer Science, 9 | 10 | The Hebrew University of Jerusalem, Israel 11 | 12 | 2 Microsoft Research, Herzliya, Israel 13 | 14 | {yoadlew,yoni sompo,avivz}@cs.huji.ac.il 15 | 16 | ## Abstract. 17 | Distributed cryptographic protocols such as Bitcoin and Ethereum use a data structure known as the block chain to synchronize a global log of events between nodes in their network. 18 | Blocks, which are batches of updates to the log, reference the parent they are extending, and thus form the structure of a chain. 19 | Previous research has shown that the mechanics of the block chain and block propagation are constrained: if blocks are created at a high rate compared to their propagation time in the network, many conflicting blocks are created and performance suffers greatly. 20 | As a result of the low block creation rate required to keep the system within safe parameters, transactions take long to securely confirm, and their throughput is greatly limited. 21 | 22 | ## 摘要 23 | 诸如比特币和以太坊之类的分布式密码协议使用称为区块链的数据结构来同步其网络中节点之间事件的全局日志。 24 | 区块是对日志的批量更新，区块通过引用父节点将链不断延伸，因此形成了链式结构。 25 | 先前的研究表明，区块链和区块传播的机制受到限制：如果与网络中的传播时间相比，以较高的速率创建区块，则会创建许多冲突的区块，并且性能会大大降低。 26 | 由于将系统保持在安全参数范围内所需的块创建率较低，因此交易需要很长时间才能安全确认，并且其吞吐量受到极大限制。 27 | 28 | We propose an alternative structure to the chain that allows for operation at much higher rates. 29 | Our structure consists of a directed acyclic graph of blocks (the block DAG). 30 | The DAG structure is created by allowing blocks to reference multiple predecessors, and allows for more “forgiving” transaction acceptance rules that incorporate transactions even from seemingly conflicting blocks. 31 | Thus, larger blocks that take longer to propagate can be tolerated by the system, and transaction volumes can be increased. 32 | 33 | 我们提出了一种链的替代结构，该结构允许以更高的交易速度运行。 34 | 我们的结构由区块的有向无环图（Block DAG）组成。 35 | 通过允许区块引用多个前置区块来创建DAG结构，并允许更“宽容”的交易接受规则，这些规则甚至能从看似冲突的区块中将交易融合进来。 36 | 因此，该系统可以接受需要较长时间传播的较大块，并且可以增加交易吞吐量。 37 | 38 | Another deficiency of block chain protocols is that they favor more connected nodes that spread their blocks faster—fewer of their blocks conflict. 39 | We show that with our system the advantage of such highly connected miners is greatly reduced. 40 | On the negative side, attackers that attempt to maliciously reverse transactions can try to use the forgiving nature of the DAG structure to lower the costs of their attacks. 41 | We provide a security analysis of the protocol and show that such attempts can be easily countered. 42 | 43 | 区块链协议的另一个不足之处是，网络状况较好的节点有更大的优势，这些节点可以更快地传播其区块，从而减少块冲突。 44 | 我们证明，使用我们的系统，这种网络状况较好的矿工的优势大大降低。 45 | 不利的一面是，试图恶意逆转交易的攻击者可以尝试利用DAG结构的宽容性质来降低攻击成本。 46 | 我们提供了对该协议的安全性分析，并表明可以很容易地阻止此类尝试。 -------------------------------------------------------------------------------- /Papers/Inclusive/DefinitionsBeforeLemma3_Tony.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Inclusive/DefinitionsBeforeLemma3_Tony.jpeg -------------------------------------------------------------------------------- /Papers/PHANTOM/4-SCALABILITY AND NETWORK DELAYS.md: -------------------------------------------------------------------------------- 1 | 2 | >* **Source：** [https://eprint.iacr.org/2018/104.pdf](https://eprint.iacr.org/2018/104.pdf) 3 | >* **TranStudy：** [https://github.com/DAGfans/TranStudy/edit/master/Papers/PHANTOM/4-SCALABILITY%20AND%20NETWORK%20DELAYS.md](https://github.com/DAGfans/TranStudy/edit/master/Papers/PHANTOM/4-SCALABILITY%20AND%20NETWORK%20DELAYS.md) 4 | 5 | 6 | # 4. SCALABILITY AND NETWORK DELAYS 7 | 8 | # 4. 可扩容性和网络延迟 9 | 10 | ## A. The propagation delay parameter $D_{max}$ 11 | 12 | ## A. 传播时延参数$D_{max}$ 13 | 14 | The scalability of a distributed algorithm is closely tied to the assumptions it makes on the 15 | underlying network, and specifically on its propagation delay D. The real value of D is both 16 | unknown and sensitive to shifting network conditions. For this reason, Bitcoin operates under 17 | the assumption that D is much smaller than 10 minutes, and sets the average block interval 18 | time to 10 minutes. While this seems like an overestimation of the network’s propagation delay 19 | under normal conditions (at least in 2018’s Internet terms), some safety margin must be taken, 20 | to account for peculiar network conditions as well. Similarly, in PHANTOM we assume that 21 | the unknown D is upper bounded by some $D_{max}$ which is known to the protocol. The protocol 22 | does not explicitly encode $D_{max}$, rather, it is parameterized with k which depends on it, as will 23 | be described in the next subsection. 24 | 25 | 一个分布式算法的可扩容性与其对底层网络所作的假设——尤其是传播时延D密切相关。D的真实数值是未知的，并且会随着网络条件的时刻变化而改变。因此，比特币假设D远小于10分钟，并将区块的平均生成间隔定为10分钟。虽然这看起来高估了正常条件下的网络传播时延（至少以2018年的因特网来说），但我们必须设置一些安全界限，以应对特殊罕见的网络条件。类似地，在PHANTOM中，虽然D的值未知，但我们假设其上限是$D_{max}$，而这个值对协议来说是已知的。协议并不会显式地对$D_{max}$进行编码，而是用参数k来表示它。也就是说，k的值取决于$D_{max}$。下一小节将会对此进行论述。 26 | 27 | The use of an *a priori* known bound $D_{max}$ distinguishes PHANTOM’s security model from 28 | that of SPECTRE [8]. While the security of both protocols depends on the assumption that the 29 | network’s propagation delay D is upper bounded by some constant, in SPECTRE the value of 30 | such a constant need not be known or assumed by the protocol, whereas PHANTOM makes 31 | explicit use of this parameter (via k) when ordering the DAG’s blocks. The fact that the order 32 | between any two blocks becomes robust in PHANTOM, but not in SPECTRE, should be ascribed 33 | to this added assumption; see further discussion in Section 7. 34 | 35 | PHANTOM的安全模型与SPECTRE的不同就在于使用了先验已知的上限$D_{max}$。虽然两者协议的安全性都建立在网络传播时延D的上限是某个常数这个假设上，但在SPECTRE中协议不需要知道或假设该常数的数值，而PHANTOM在对DAG里的区块排序时（通过k）显式地使用了这个参数。PHANTOM中任意两个区块之间的顺序都是鲁棒的，而SPECTRE则不是，正是因为PHANTOM比SPECTRE多做了这一步假设；见第7节进一步的讨论。 36 | 37 | ## B. The anticone size parameter k 38 | 39 | ## B. 反锥体大小参数k 40 | 41 | The parameter k is decided from the outset and hard-coded in the protocol. It is defined as 42 | follows: 43 | 44 | 协议在开头就定义并硬编码了参数k。定义如下所示： 45 | $$ 46 | k(D_{max},δ) := min \left \{\hat{k} \in N : (1-e^{-2\cdot D_{max}\cdot λ})^{-1}\cdot \left ( \sum_{j=\hat{k} + 1}^{∞}{e^{-2\cdot D_{max}\cdot λ}\cdot \frac{(2\cdot D_{max}\cdot λ)^j}{j!}}\right )<δ\right \} 47 | $$ 48 | 49 | 50 | The motivation here is to devise a bound over the number of blocks created in parallel. Since 51 | the block creation rate follows a Poisson process, for an arbitrary block B created at time t, 52 | at most $k(D_{max},δ)$ additional blocks were created in the time interval$[t - D_{max}, t + D_{max}]$, with 53 | probability of at least $1 - δ$. (In more detail: The second multiplicand in the definition of k 54 | bounds the probability that more than k blocks were created in parallel to B in the time interval 55 | $[t - D_{max}, t + D_{max}]$. This term is divided by $1 - e^{-2 \cdot D_{max}}$, which is the probability that 56 | at least one block was created during this time, namely, B. Thus, conditioned on the 57 | appearance of B, at most k blocks were created during this time interval, with probability of 58 | $1 - δ$ at least.) 59 | 60 | 这里的目的是为同时创建的区块数量设计一个上限。由于区块的创建频率服从泊松分布，因此对任意一个在时刻t创建的区块B，在时间间隔$[t - D_{max}, t + D_{max}]$,中创建出的其它区块数量最多为$k(D_{max},δ)$，且其概率至少为 $1 - δ$。（更具体地说：在k的定义中的第二个乘数限定了在时间间隔$[t - D_{max}, t + D_{max}]$中在B以外同时创建的区块数量大于k的概率。这一项被$1 - e^{-2 \cdot D_{max}}$，也就是在此期间至少有一个区块即B被创建的概率所除。因此，以B的出现为条件，在此期间最多有k个区块被创建的概率至少为$1 - δ$。） 61 | 62 | Observe that blocks created in the intervals $[0, t - D_{max})$ and $(t + D_{max}, ∞)$, by honest nodes, 63 | belong to B’s past and future sets, respectively. Consequently, in principle, $|anticone(B)| ≤ k$ 64 | with probability of $1 - δ$ at least. However, an attacker can artificially increase B’s anticone by 65 | creating blocks that do not reference it and by withholding his blocks so that B cannot reference 66 | them. 67 | 68 | 我们可以观察到在$[0, t - D_{max})$和$(t + D_{max}, ∞)$期间内由诚实节点创建的区块分别属于B的过去和将来集。因此，原则上$\|anticone(B)\| ≤ k$的概率至少为$1 - δ$。尽管如此，攻击者可以通过创建不引用B的区块，并且将区块隐藏起来不让B指向它们，从而人为增大B的反锥体。 69 | 70 | 71 | ## C. Trade-offs 72 | 73 | ## C. 取舍 74 | 75 | Theorem 5, and the parameterization of PHANTOM in (1), tie between $k$, $D_{max}$, $λ$, and $δ$. 76 | Striving for a better performance by modifying one parameter (e.g., increasing $λ$ to obtain larger 77 | throughput and more frequent blocks) must be understood and considered against the effect on 78 | all other parameters. 79 | 80 | 定理5，以及PHANTOM的公式（1）将$k$、$D_{max}$、$λ$和$δ$这几个参数相互联系了起来。如果想修改某个参数从而获取更好的性能（比如，增大$λ$从而获得更大的吞吐量和更频繁的区块创建次数），就必须理解并考虑对其它参数的影响。 81 | 82 | **Increased block creation rate.** Although the security threshold does not deteriorate as $λ$ is 83 | increased, $λ$ cannot be increased indefinitely, or otherwise the network becomes congested. The 84 | value of $λ$ should be set such that nodes that are expected to participate in the system can 85 | support such a throughput. For instance, if nodes are required to maintain a bandwidth of at 86 | least 1MB per second, and blocks are of size $b$ = 1MB, then the block creation rate should 87 | be set to $λ$ = 1 blocks per second (this is merely a back-of-the-envelope calculation, and in 88 | practice other messages consume the bandwidth as well). 89 | 90 | **更高的区块创建频率。** 虽然安全阈值并不会随着$λ$增大而变差，但是$λ$并不能无穷增大，不然网络就会变得拥堵不堪。$λ$的值所对应的吞吐量必须能够被期望加入系统的节点所支撑。比如，如果我们要求节点保持至少每秒1MB的带宽，并且区块的大小是$b$ = 1MB，那么区块创建频率就必须设为$λ$ = 每秒1个区块（这只是粗略的计算，实际中还会有其它消息消耗带宽）。 91 | 92 | **Higher security threshold.** Theorem 5 states the security threshold in terms of $δ$. Following (1) 93 | we notice that tightening the security threshold - by choosing a lower $δ$ - requires increasing 94 | $k$. A large $k$ leads to slow confirmation times, as will be discussed shortly. 95 | (The advanced reader should notice that although increasing $λ$ has a similar negative effect on $k$, it has at the 96 | same time a positive effect on confirmation times, and so a certain $λ$ will be optimal as far as confirmation times are concerned.) 97 | 98 | **更高的安全阈值。** 定理5通过$δ$描述了安全阈值。从（1）我们可以注意到，（通过选择一个较小的$δ$值从而）收紧安全阈值就需要增大$k$。$k$值增大就意味着确认时间变慢，下文很快就会讨论到。（高阶读者应该能够意识到$λ$对$k$也有类似的负面影响，同时对确认时间有正面影响，因此只要能考虑到确认时间，$λ$的值必然就是最佳的。） 99 | 100 | **Larger safety margin.** Similarly, if $D_{max}$ is to be increased, one needs to increase $k$ as well 101 | in order to maintain the same security level (represented by $δ$). 102 | 103 | **更大的安全边界。** 类似地，如果要增大$D_{max}$，为了维持安全等级（由$δ$表示）不变，就需要增大$k$。 104 | 105 | As discussed in Subsection 4.1, it is better to overestimate $D$ and choose a large $D_{max}$ in order 106 | remain on the safe side. (Several blockchain based projects do not do so, and consequently compromise the security threshold of their system.) 107 | Recall that the security of Bitcoin’s chain depends on the assumption 108 | that $D \cdot λ \ll 1$ , namely, that w.h.p. at least $D$ seconds pass between consecutive blocks, so that 109 | forks are rare. Thus, Bitcoin’s large safety margin over $D$ suppresses its throughput severely as 110 | it requires selecting a very low block rate $λ = 1 / 600$ (one block per 10 minutes). This is not 111 | the case with PHANTOM’s DAG, as the security of the DAG ordering does not rely on the 112 | assumption $D \cdot λ \ll 1$. Therefore, even if we overestimate $D$, we can still allow for very high 113 | block creation rates while maintaining the same level of security. Consequently, PHANTOM 114 | supports a very large throughput, and does not suffer from a security-scalability tradeoff. 115 | 116 | 我们在4.1节讨论过，一般最好是高估$D$并选择一个较大的$D_{max}$从而确保安全性。（有的基于区块链的项目并不这么做，因此它们的系统在安全阈值方面做了妥协。）回顾一下，比特币的安全性依赖于$D \cdot λ \ll 1$这个假设，也就是说，一个区块被创建之后，极有可能要至少过$D$秒才会有下一个区块被创建，因此分叉极少。因此，比特币的大于$D$的安全边界严重抑制了它的吞吐量，因为它要选择一个很低的区块创建频率$λ = 1 / 600$（每10分钟一个区块）。而PHANTOM的DAG并不是这样，因为DAG排序的安全性并不依赖$D \cdot λ \ll 1$这个假设。因此，即使我们高估了$D$，也依然可以在维持安全等级不变的情况下允许十分高的区块创建频率。所以PHANTOM支持非常大的吞吐量，并且不需要对安全性和可扩容性做出取舍。 117 | 118 | That said, in PHANTOM there is still a tradeoff between a large safety margin and fast 119 | convergence of the protocol. A gross overestimation of $D_{max}$ - resulting an increase in $k$ - 120 | would significantly slow down the waiting time for transaction settlement. Thus, $D_{max}$ should 121 | be set to a reasonable level. In Section 7 we discuss how this tradeoff can be restricted to visible 122 | conflicts only, and how applications such as *Payments* can enjoy very fast confirmation times 123 | nonetheless. 124 | 125 | 即便如此，在PHANTOM中依然需要在大的安全边界和协议的快速收敛之间进行取舍。对$D_{max}$过高的估计——从而导致$k$的增大——会使交易结算的等待时间显著变慢。因此，$D_{max}$的值需要设置为一个合理的水平。在第7节我们会讨论如何能够将这个取舍限制在可见的冲突内，以及在这种情况下*支付*之类的应用如何维持很快的确认时间。 126 | -------------------------------------------------------------------------------- /Papers/PHANTOM/6-VARIANTS.md: -------------------------------------------------------------------------------- 1 | >* **Source：** [https://eprint.iacr.org/2018/104.pdf](https://eprint.iacr.org/2018/104.pdf) 2 | >* **TranStudy：** [https://github.com/DAGfans/TranStudy/edit/master/Papers/PHANTOM/6-VARIANTS.md](https://github.com/DAGfans/TranStudy/edit/master/Papers/PHANTOM/6-VARIANTS.md) 3 | 4 | # 6. VARIANT 5 | 6 | # 6. 变体 7 | 8 | In Section 2 we described the PHANTOM’s greedy algorithm to mark blocks as blue or red (Algorithm 1). In fact, similar algorithms can provide similar guarantees. We describe several such variants below and explain the intuition behind them. All these variants can be thought of as greedy approximations to the Maximum $k$-cluster SubDAG problem described in Section 1. 9 | 10 | 在第二部分中，我们描述了PHANTOM的贪婪算法，将块标记为蓝色或红色（算法1）。事实上，类似的算法能提供类似的保证。我们在下面描述几个这样的变体并解释它们背后的本质。所有这些变体都可以认为是第1节中描述的Maximum $k$-cluster SubDAG问题的贪婪近似。 11 | 12 | *A. Choosing the maximizing tip* 13 | In our original version of the colouring procedure, we chose the tip which has the highest score (Algorithm 1, line 6). Instead, Algorithm 3 below chooses the tip for which the score of the (virtual block of the) current DAG would be highest: 14 | 15 | *A.选择最大化末端* 16 | 在我们的着色程序的原始版本中，我们选择了得分最高的末端（算法 1，行 6）。相反，下面的算法3选择当前DAG（的虚拟块）的得分最高的末端： 17 | 18 | > **Algorithm 3** Selection of a blue set 19 | 20 | **Input:** G – a block DAG, k – the propagation parameter 21 | 22 | **Output:** $BLUE_k(G)$ – the dense-set of G 23 | 24 | 1. **function** CALC-BLUE(G, k ) 25 | 26 | 2. > **if** $G == {genesis}$ **then** 27 | 28 | 3. >> **return** {$genesis$} 29 | 30 | 4. > **for** $B \in tips(G)$ **do** 31 | 32 | 5. >> $BLUE_k(B) \leftarrow CALC-BLUE(past (B) , k)$ 33 | 34 | 6. >> $S_B \leftarrow BLUE_k(B) \cup {B}$ 35 | 36 | 7. >> **for** $C \in anticone(B)$ in some arbitrary order **do** 37 | 38 | 8. >>> **if** $|anticone(C) \cap S_B| \leq k$ **then** 39 | 40 | 9. >>>> add C to $S_B$ 41 | 42 | 10. >>**return** arg $max{|S_B|:B \in tips(G)}$ (and break ties arbitrarily) 43 | 44 | *B. Adding blocks to the greedily chosen blue set* 45 | Another variant over the previous algorithms is the procedure to mark more blocks as blue, after the best tip and its blue set were selected. Previously, we required that the candidate block admit an anticone of size at most k in the current set. Instead, we can require that its anticone be counted only inside the originally chosen blue set. Thus, yet another variant is to replace lines 8-9 with 46 | 47 | *B.将块添加到贪婪选择出的蓝色集合* 48 | 在选择最优末端和蓝色集合之后，先前算法的另一个变体是将更多块标记为蓝色的过程。在此之前，我们要求候选块在当前集合中承认一个至多为k的反锥体。相反，我们可以要求只在最初选择的蓝色集合内计算反锥体。因此，另一个变式将代替上面的8-9行 49 | 50 | 8. >>> **if** $|anticone(C) \cap (BLUE_k(B) \cup {B})| \leq k$ **then** 51 | 52 | 9. >>>> add C to $S_B$ 53 | 54 | Observe that the resulting blue set may contain blocks which have an anticone larger than k within the set. 55 | 56 | 发现所得到的蓝色集合可以包含在该集合内具有大于k的反锥体的块。 57 | 58 | Finally, another viable alternative is to further relax the condition (in lines 8-9) by counting the anticone of the candidate B only against the resulting chain of blue blocks, $Chn(past(B))\cup {B}$, where $B$ is the selected tip: 59 | 60 | 最终，另一个可行的选择是进一步放宽条件（在8-9行中），只计算与产生的蓝色块的链相反的候选人B的反锥体，$Chn(past(B))\cup {B}$，$B$就是被选择的末端： 61 | 62 | 8. >>> **if** $|anticone(C) \cap Chn(past(B))\cup {B}| \leq k$ **then** 63 | 64 | 9. >>>> add C to $S_B$ 65 | 66 | Compare this variant to Satoshi’s longest-chain rule, a rule that can be described as follows: each block in a chain $Chn$ increases its weight by 1, and we select the highest scoring chain. In contrast, in our last variant, each block whose gap from a chain $Chn$ is at most $k$ increases its weight by 1, and we select the highest scoring chain. 67 | 68 | 这个变体与中本聪的最长链比较，可以被描述为遵循以下规则：在$Chn$链中的每一个块以1增长自身的价值，我们选择得分最高的链。恰恰相反，在我们最后的一个变体中，每一个与$Chn$链差距至多为$k$的块以1增长自身的价值，我们选择得分最高的链。 69 | 70 | *C. Iterative elimination of blocks* 71 | We now introduce another variant based on an iterative method common in combinatorial optimization. The algorithm works as follows: Given a block DAG $G$, we iteratively eliminate from the blue set the block with largest blue anticone, and continue doing so until all blue blocks admit a blue anticone of size $k$ at most: 72 | 73 | *C.块的迭代消除* 74 | 我们现在介绍另一种变体，基于一种常用于组合优化的迭代方法。算法描述如下：已知一个块DAG $G$，我们从蓝色集合中迭代消除有最大蓝色反锥体的块，并且一直重复直到所有蓝色块承认一个最大为$k$的蓝色反锥体： 75 | 76 | > **Algorithm 4** Selection of a blue set 77 | 78 | **Input:** G=(V,E) – a block DAG, k – the propagation parameter 79 | 80 | **Output:** $BLUE_k(G)$ – the dense-set of G 81 | 82 | 1. **function** CALC-BLUE(G, k ) 83 | 84 | 2. > $BLUE_k(G) \leftarrow V$ 85 | 86 | 3. > **while** $\exists B \in BLUE_k(G)$ **with** $|anticone| \cap BLUE_k(G)|> k$ **do** 87 | 88 | 4. >> $C \leftarrow ard_B\ max{|anticone(B)\cap BLUE_k(G)|}$(with arbitrary tie-breaking) 89 | 90 | 5. >> remove $C$ from $BLUE_k(G)$ 91 | 92 | 6. > **return** $BLUE_k(G)$ 93 | 94 | We conjecture that Algorithm 1 can be replaced with each of the greedy algorithms described in this section. To this end, suffice it to repeat the proof of Theorem 5 with respect to these variants. We suspect that the same proof technique, namely, the use of Hourglass, would prove useful. 95 | 96 | 我们猜想算法1可以用本节中描述的每个贪婪算法来代替。为此，只要重复定理5对于这些变体的证明就足够了。我们怀疑利用同样的证明技巧，即使是沙漏的使用，也将证明是有用的。 97 | 98 | -------------------------------------------------------------------------------- /Papers/PHANTOM/7-CONFIRMATION TIMES.md: -------------------------------------------------------------------------------- 1 | >* **Source：** [https://eprint.iacr.org/2018/104.pdf](https://eprint.iacr.org/2018/104.pdf) 2 | >* **TranStudy：** [https://github.com/DAGfans/TranStudy/edit/master/Papers/PHANTOM/7-CONFIRMATION TIMES.md](https://github.com/DAGfans/TranStudy/edit/master/Papers/PHANTOM/7-CONFIRMATION TIMES.md) 3 | # 7. CONFIRMATION TIMES 4 | 5 | # 7. 确认时间 6 | 7 | As discussed in Section 5, the convergence rate of $Risk(B,t)$ is slow, at least theoretically and under certain circumstances. Recall that the function $Risk(B,t)$ measures the probability that a certain block that did not precede $B$ at time $t$ will later come to precede it. Recall further that throughput this work we used arbitrary topological orderings (over blue blocks). In light if this, it would be interesting to seek for an ordering rule (over blue blocks) that would converge faster. We suspect this is not a trivial task, and leave its full investigation to future work. 8 | 9 | 如第5节所述，$Risk(B,t)$的收敛速度很慢，至少在理论上和某些情况下。回想一下，函数$Risk(B,t)$计算在时间$t$时没有出现在$B$之前位置确定的块将在之后出现在它之前位置的可能性。进一步回忆一下，我们使用任意拓扑排序（在蓝色块之上）处理吞吐量。有鉴于此，寻求一种能够更快收敛的排序规则（通过蓝色块）会很有趣。我们认为这不是一项微不足道的任务，并且对未来的工作留下充分的调查。 10 | 11 | The primary factor to the fact that **PHANTOM** cannot guarantee fast confirmation times is that membership in the blue set takes time to finalize. The waiting time for such finalization can be further increased if an attacker manages to balance the decision between $B \in BLUE_k(G)$ and $B \notin BLUE_k(G)$. Observe however that if a certain transaction $tx \in B$ admits no conflicts in $anticone(B)$, then $tx$ can be accepted even before the decision regarding $B$ is finalized. 12 | 13 | **PHANTOM**无法保证快速确认时间这一事实的主要原因是，蓝色集合中的成员资格需要时间才能最终确定。如果攻击者在$B \in BLUE_k(G)$和$B \notin BLUE_k(G)$中设法平衡决定，那么等待时间会进一步增加。但是请注意，如果某个交易$tx \in B$承认在$anticone(B)$中没有冲突，甚至$tx$在关于$B$的决定已经完成之前就被接受。 14 | 15 | *A. Combining SPECTRE and PHANTOM* 16 | 17 | *A. 结合SPECTRE和PHANTOM* 18 | 19 | SPECTRE is a DAG based protocol that can support large transaction throughput (similarly to *PHANTOM*) and very fast confirmations. SPECTRE does not output a linear order over blocks. Rather, every block $B$ admits a vote regarding the pairwise ordering of any two blocks $C$ and $D$, and the output is the majority vote regarding each pair. In SPECTRE, cycles of the sort “$B$ precedes $C$, $C$ precedes $D$, $D$ precedes $B$” may form. 20 | 21 | SPECTER是一种基于DAG的协议，可以支持较大的交易吞吐量（与*PHANTOM*相似）并非常快速的确认。SPECTER不输出块的线性顺序。相反，每个块$B$承认关于任何两个块$C$和$D$的成对排序的投票,并且输出是关于每一对的最多数票。在SPECTRE中，“$B$在$C$之前，$C$在$D$之前，$D$在$B$之前”的环可能形成。 22 | 23 | Furthermore, if an active balancing attack is taking place, for some pairs of blocks $(B, C)$ the SPECTRE relation might not become robust (in which case $Risk(B, t) \rightarrow 0$ is not guaranteed). Instead, a published block $B$ is guaranteed to robustly precede any block $C$ that was published later than $B$, unless $C$ was published shortly after $B$. We call this property *Weak Liveness*. In the context of the Payments application, this fact can only harm a user that signed and published two conflicting payments at approximately the same time.^{19} 24 | 25 | 此外，如果发生主动平衡攻击，对于某些块$(B, C)$，SPECTER关系可能变得不稳固（在这种情况下$Risk(B, t) \rightarrow 0$不能被保证）。相反，已发布的块$B$被保证可以稳固地位于比$B$晚发布的任何块$C$之前的位置，除非$C$在$B$后不久发布。我们称这个属性为"虚弱的”活性"。在支付申请的环境下，这一事实只会对几乎同时签署和发布两笔冲突付款的用户造成伤害。^{19} 26 | 27 | Since *PHANTOM* does guarantee (strong) Liveness and a liner ordering, it is interesting to inquire whether we can enjoy the best of both worlds. We provide below a partial answer to this question. 28 | 29 | 因为*PHANTOM*能保证（强壮的）“活性”和线性排序，询问我们是否能享受两全其美的好处很有意思。我们在下面提供这个问题的部分答案。 30 | 31 | Consider the following procedure: Given a blockDAG $G$, 32 | 33 | > 1) mark blocks as blue or red according to PHANTOM’s colouring procedure 34 | 35 | > 2) run SPECTRE on the subDAG $BLUE_k(G)$; this determines the pairwise ordering between any two $blue$ blocks $B$ and $C$ 36 | 37 | > 3) for any blue block $B$ and red block $C$, if $C \in past(B)$ then determine that $C$ precedes $B$, otherwise determine that $B$ precedes $C$ 38 | 39 | > 4) decide the pairwise ordering of any two red blocks in some arbitrary way that respects the topology ($B \in past(C) \Rightarrow B$ precedes $C$) 40 | 41 | 考虑以下过程：已知DAG块$G$， 42 | 43 | > 1) 根据PHANTOM的着色程序将块标记为蓝色或红色 44 | 45 | > 2) 在subDAG $BLUE_k(G)$上运行SPECTRE； 46 | 这决定了任何两个$蓝色$块$B$和$C$之间成对排序 47 | 48 | > 3) 对于任何蓝色块$B$和红色块$C$，如果$C \in past(B)$则确定$C$在$B$之前，否则确定$B$在$C$之前 49 | 50 | > 4) 以某种符合拓扑的任意方式决定任意两个红色块的成对排序($B \in past(C) \Rightarrow B$在$C$之前) 51 | 52 | Intuitively, we run SPECTRE on the set of blue blocks (as determined by PHANTOM), and 53 | complemented the pairwise ordering in a way that both penalizes red blocks and respects the topology. We argue that this protocol enjoys SPECTRE’s fast confirmation times and at the same time inherits the (regular) Liveness property of PHANTOM. To see the latter, observe that a Hourglass block would have a similar effect in SPECTRE——all blocks in its future will vote according to its vote. In particular, the pairwise relation of all previous blocks becomes as robust as the Hourglass block. 54 | 55 | 直观地说，我们在蓝色块集合上运行SPECTER（由PHANTOM决定），并以一种既惩罚红色方块并符合拓扑结构的方法来补充成对排序。我们认为，该协议享有SPECTER的快速确认时间的性质，同时继承了PHANTOM的（常规）“活性”的属性。要观察后者，观察沙漏块在SPECTER中会有类似的效果——未来所有区块将根据其投票数进行投票。特别是，所有先前块的成对关系变得和沙漏块一样稳固。 56 | 57 | Note that this incremental improvement over vanilla SPECTRE is only possible because we allowed the protocol to assume something on the network’s topology, namely, that the communication delay diameter is upper bounded by $D_{max}$. 58 | 59 | 需要注意的是，对于常规SPECTER的这种增量式改进是可能的，因为我们允许协议在网络的拓扑结构上假设某些条件，即，通信延迟直径上限为$D_{max}$。 60 | 61 | 62 | *B. Summary* 63 | 64 | In summary, it is possible to achieve both fast confirmation times and Liveness by combining PHANTOM and SPECTRE. It is of yet unclear whether we can further achieve a linear ordering without compromising the fast confirmation times. Hopefully, we will provide answers to these questions in future work. 65 | 66 | *B. 总结* 67 | 总之，通过组合PHANTOM和SPECTER可以实现快速确认时间和活性。目前还不清楚我们是否可以在不影响快速确认时间的情况下进一步实现线性排序。希望我们能在未来的工作中为这些问题提供答案。 68 | 69 | ^{19}In contrast, usually any user can engage with a smart contract and introduce conflicts inputs. Thus, Weak Liveness might potentially harm the usability of SPECTRE to the Smart Contracts application. 70 | 71 | ^{19}相比之下，通常任何用户都可以参与智能合约并引入冲突输入。因此，弱活性可能会损害SPECTER对智能合同应用程序的可用性。 72 | 73 | ##REFERENCES 74 | ##参考文献 75 | 76 | >[1] Ittay Eyal, Adem Efe Gencer, Emin Gu ̈n Sirer, and Robbert Van Renesse. Bitcoin-ng: A scalable blockchain protocol. In 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI 16), pages 45–59, 2016. 77 | 78 | >[2] Michael R Garey and David S Johnson. Computers and intractability, volume 29. wh freeman New York, 2002. 79 | 80 | >[3] Aggelos Kiayias and Giorgos Panagiotakos. On trees, chains and fast transactions in the blockchain. Cryptology 81 | ePrint Archive, Report 2016/545, 2016. 82 | 83 | >[4] Eleftherios Kokoris Kogias, Philipp Jovanovic, Nicolas Gailly, Ismail Khoffi, Linus Gasser, and Bryan Ford. 84 | Enhancing bitcoin security and performance with strong consistency via collective signing. In 25th USENIX 85 | Security Symposium (USENIX Security 16), pages 279–296. USENIX Association, 2016. 86 | 87 | >[5] Yoad Lewenberg, Yonatan Sompolinsky, and Aviv Zohar. Inclusive block chain protocols. In International 88 | Conference on Financial Cryptography and Data Security, pages 528–547. Springer, 2015. 89 | 90 | >[6] Rafael Pass and Elaine Shi. Hybrid consensus: Efficient consensus in the permissionless model, 2016. 91 | 92 | >[7] Joseph Poon and Thaddeus Dryja. The bitcoin lightning network: Scalable off-chain instant payments. Technical 93 | Report (draft), 2015. 94 | 95 | >[8] Yonatan Sompolinsky, Yoad Lewenberg, and Aviv Zohar. Spectre: A fast and scalable cryptocurrency protocol. 96 | IACR Cryptology ePrint Archive, 2016:1159, 2016. 97 | 98 | >[9] Yonatan Sompolinsky and Aviv Zohar. Secure high-rate transaction processing in bitcoin. In International 99 | Conference on Financial Cryptography and Data Security, pages 507–527. Springer, 2015. 100 | 101 | >[10] David Williams. Probability with martingales. Cambridge university press, 1991. 102 | -------------------------------------------------------------------------------- /Papers/PHANTOM/ABSTRACT.md: -------------------------------------------------------------------------------- 1 | > **Source：** [https://eprint.iacr.org/2018/104.pdf](https://eprint.iacr.org/2018/104.pdf) 2 | > **TranStudy：** [https://github.com/DAGfans/TranStudy/edit/master/Papers/PHANTOM/Abstract.md](https://github.com/DAGfans/TranStudy/edit/master/Papers/PHANTOM/Abstract.md) 3 | 4 | # PHANTOM: A Scalable BlockDAG protocol 5 | 6 | # PHANTOM: 可扩展的 BlockDAG 协议 7 | 8 | ### Yonatan Sompolinsky and Aviv Zohar 9 | 10 | ### School of Engineering and Computer Science, 11 | 12 | ### 计算机科学与工程学院 13 | 14 | ### The Hebrew University of Jerusalem, Israel 15 | 16 | ### 耶路撒冷希伯来大学，以色列 17 | 18 | ### {yoni sompo,avivz}@cs.huji.ac.il 19 | 20 | ## Abstract 21 | 22 | > In 2008 Satoshi Nakamoto invented the basis for blockchain based distributed ledgers. The core concept of this system is an open and anonymous network of nodes, or miners, which together maintain a public ledger of transactions. The ledger takes the form of a chain of blocks, the blockchain, where each block is a batch of new transactions collected from users. One primary problem with Satoshi’s blockchain is its highly limited scalability. The security of Satoshi’s longest chain rule, more generally known as the Bitcoin protocol, requires that all honest nodes be aware of each other’s blocks very soon after the block’s creation. To this end, the throughput is artificially suppressed so that each block fully propagates before the next one is created, and that very few “orphan blocks” that fork the chain be created spontaneously. 23 | > In this paper we present PHANTOM, a protocol for transaction confirmation that is secure under any throughput that the network can support. PHANTOM thus does not suffer from the security-scalability tradeoff which Satoshi’s protocol suffers from. PHANTOM utilizes a Directed Acyclic Graph of blocks, a blockDAG, a generalization of Satoshi’s chain which better supports faster block generation and larger blocks that take longer to propagate. PHANTOM uses a greedy algorithm on the blockDAG to distinguish between blocks mined properly by honest nodes and those mined by non-cooperating nodes who chose to deviate from the mining protocol. Using this distinction, PHANTOM provides a robust full order on the blockDAG in a way that is eventually agreed upon by all honest nodes. 24 | 25 | ## 摘要 26 | 27 | > 2008年，中本聪发明了基于区块链的分布式账本的基础。 这个系统的核心概念是一个开放和匿名的节点或矿工网络， 它们共同维护着交易的公共账本。 账本采取区块的链式形式，即区块链，每个区块是从用户收集的一批新交易。 中本聪式区块链的一个主要问题是其可扩展性非常有限。 中本聪的最长链规则(通常称为比特币协议)的安全性，要求所有诚实的节点都会在块创建后很快了解到对方的块。 为此，吞吐量被人为地抑制，使得每个块在下一个块被创建之前可以完全传播，并且很少的分叉产生的“孤块”可以自发创建。 28 | > 在本文中，我们介绍PHANTOM，用于交易确认的协议，在网络可支持的任何吞吐量下都是安全的。 因此，PHANTOM没有中本聪协议所面临的要在安全和可扩展性之间权衡的问题。 PHANTOM利用有向无环图区块，又称blockDAG，一个更适合更快速的块增长和传播时间更长的更大区块的广义上的中本聪式区块链。 PHANTOM在blockDAG上使用贪婪算法来区分诚实节点正确挖出的区块和选择偏离DAG采矿协议的非协作节点挖出的区块。 利用这个区别，PHANTOM以最终由所有诚实节点同意的方式在blockDAG上提供全序。 29 | 所有诚实的节点都会在块创建后很快意识到对方的块。 为此，吞吐量被人为地抑制，使得每个块在下一个块被创建之前可以完全传播，并且没有任何分叉产生的“孤块”可以自发创建。 在本文中，我们介绍PHANTOM，用于交易确认的协议，在网络可支持的任何吞吐量下都是安全的。 因此，PHANTOM没有中本聪协议所面临的要在安全和可扩展性之间权衡的问题。 PHANTOM利用有向无环图区块，又称blockDAG，一个更适合快速或大区块配置下的广义上的中本聪式区块链。 PHANTOM在blockDAG上使用贪婪算法来区分诚实节点正确挖出的区块和偏离DAG采矿协议的非协作节点挖出的区块。 利用这个区别，PHANTOM以最终由所有诚实节点同意的方式在blockDAG上提供强大的全序。 30 | -------------------------------------------------------------------------------- /Papers/PHANTOM/PHANTOM___an_efficient_implementation__chinese.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/PHANTOM/PHANTOM___an_efficient_implementation__chinese.pdf -------------------------------------------------------------------------------- /Papers/RepuCoin/1-Introduction.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/RepuCoin/1-Introduction.md -------------------------------------------------------------------------------- /Papers/RepuCoin/2-RelatedWork.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/RepuCoin/2-RelatedWork.md -------------------------------------------------------------------------------- /Papers/RepuCoin/3-SystemAndThreatModel.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/RepuCoin/3-SystemAndThreatModel.md -------------------------------------------------------------------------------- /Papers/RepuCoin/4-RepuCoin.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/RepuCoin/4-RepuCoin.md -------------------------------------------------------------------------------- /Papers/RepuCoin/4.1-BlockMiningAndRewardSystem.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/RepuCoin/4.1-BlockMiningAndRewardSystem.md -------------------------------------------------------------------------------- /Papers/SPECTRE/1-INTRODUCTION.md: -------------------------------------------------------------------------------- 1 | > **Source：** [https://eprint.iacr.org/2016/1159.pdf](https://eprint.iacr.org/2016/1159.pdf) 2 | > **TranStudy：** [https://github.com/DAGfans/TranStudy/new/master/Papers/SPECTRE](https://github.com/DAGfans/TranStudy/new/master/Papers/SPECTRE) 3 | 4 | # 1.INTRODUCTION 5 | 6 | Bitcoin is a novel cryptocurrency system, and an accompanying protocol, invented and deployed by Satoshi Nakamoto [13]. 7 | Transactions made in the currency are organized in a public ledger, the blockchain. 8 | Each block in the chain is a batch of transactions that were published by users of the currency. 9 | The blockchain contains consistent transactions only, as new blocks that extend it are required to maintain consistency. 10 | 11 | 比特币是一种新型的加密货币系统同时也是一个协议，由中本聪 [13]发明和部署。 12 | 以货币形式进行的交易被组织在一个公共账本，即区块链。 13 | 链中的每个块都是由货币用户发布的一批交易。 14 | 区块链仅包含一致的交易，因为需要保持一致性才能扩展它的新块。 15 | 16 | Unfortunately, Nakamoto Consensus has severe scalability limitations [5], [18], [14]: adjusting the protocol to support a high transaction throughput – by creating larger or more frequent blocks – requires stronger assumptions on the underlying network, hence smaller safety margins. 17 | 18 | 不幸的是，中本聪共识有严重的可扩展性限制[5],[18],[14]：通过调整协议来支持高交易吞吐量 - 通过创建更大或更频繁的块 - 需要对底层网络进行更强的假设，因此会导致更小的安全系数。 19 | 20 | In this paper we propose a new protocol, SPECTRE, that achieves high scalability. 21 | Transactions in SPECTRE can be confirmed within seconds, and the throughput can be improved by orders-of-magnitude over Bitcoin; 22 | it is limited by the network infrastructure and capacity only. 23 | The protocol thus alleviates the security-scalablility trade-off imposed by Nakamoto Consensus. 24 | 25 | 在本文中，我们提出了一种新的协议，即SPECTRE，它具有很高的可扩展性。 26 | SPECTRE中的交易可以在几秒钟内得到确认，吞吐量可以相较于比特币有数量级的提高; 27 | 它仅受网络基础设施和容量的限制。 28 | 因此该协议减轻了中本聪共识强加的安全可扩展性之间的取舍。 29 | 30 | In SPECTRE, every block is counted and integrated into the ledger. 31 | Technically, SPECTRE generalizes Nakamoto’s blockchain into a direct acyclic graph – a block DAG. 32 | By maintaining a full DAG of blocks, SPECTRE can allow miners to create blocks concurrently and much more frequently. 33 | This design is intended to avoid the need for nodes to reconcile their different world views regarding the identity of a selected chain at the time of block creation. 34 | 35 | 在SPECTRE中，每个块都被包括并集成到账本中。 36 | 从技术上讲，SPECTRE将中本聪的区块链泛化为有向无环图 - 区块DAG。 37 | （**译注：** 泛化这里指链式结构可以看作Block DAG的特例） 38 | 通过保持块的完整DAG，SPECTRE可以允许矿工并发并且高频地创建区块。 39 | 这种设计旨在避免节点在块创建时协调其关于所选链的身份的不同世界观。 40 | （**译注**：这句话指，所谓链式还是图式其实是因为看问题的角度不同，站在DAG的角度来看，链式也算是一种DAG） 41 | 42 | Reasoning about the consensus properties of SPECTRE requires a new formal framework. 43 | Indeed, previous work that formalized the robustness of Nakamoto Consensus [7], [15] focused on robustness of blocks in the ledger. 44 | Extending this to the robustness of transactions in SPECTRE is not immediate, because all blocks are incorporated into the DAG, but individual transactions embedded in the DAG may still be rejected due to conflicts. 45 | 46 | 论证SPECTRE的共识特性需要一个新的形式化框架。 47 | 事实上，之前形式化中本聪共识健壮性的工作专注在账本中的区块的健壮性上[7]，[15]。 48 | 但这并不能立即扩展到SPECTRE中的交易的健壮性，因为所有的块都包含在DAG中，但嵌入在DAG中的单个交易可能因冲突而被拒绝。 49 | **译注：** 冲突一般指的就是双花 50 | 51 | Thus, this paper contains two contributions: 52 | (1) an inherently scalable protocol, SPECTRE; 53 | and (2) a formal framework for cryptocurrency payment protocols that do not necessarily use a chain of blocks to represent their ledger (in this respect we differ from previously proposed frameworks). 54 | We apply it on SPECTRE, and provide rigorous analysis of SPECTRE’s robustness properties. 55 | 56 | 因此，本文包含两个贡献： 57 | （1）一个可扩展的协议，SPECTRE; 58 | （2）一个加密货币支付协议的形式化框架，它不一定要使用区块链表示账本（在这方面，我们不同于以前提出的框架）。 59 | 我们将其应用于SPECTRE，并对SPECTER的健壮性进行严格分析。 60 | 61 | The main technique behind SPECTRE is a voting algorithm regarding the order between each pair of blocks in the DAG. 62 | The voters are blocks (not miners); 63 | the vote of each block is interpreted algorithmically (and not provided interactively) according to its location within the DAG. 64 | We show that the majority’s aggregate vote becomes irreversible very fast, and we use this majority vote to extract a consistent set of transactions. 65 | Essentially, Bitcoin’s longest chain rule can be seen as a voting mechanism as well – each block adding one vote to every chain that contains it – the highest-scoring chain being also the longest one. 66 | However, Bitcoin’s selection of a “single winner chain” makes it inherently unscalable, as we demonstrate below. 67 | 68 | SPECTRE背后的主要技术是关于DAG中对区块之间的顺序进行投票的算法。 69 | 投票者是区块（不是矿工）; 70 | 根据其在DAG内的位置通过算法表示每个块（并且不提供交互式）。 71 | 我们表明，大多数的总体投票不可逆转的速度会很快，我们使用这个多数票来提取一组一致的交易。 72 | 从本质上讲，比特币最长链规则也可以被看作是一种投票机制 - 每个区块给每一个包含它的链添加一票 - 最高得分的链也是最长的。 73 | 但是，比特币选择的“单一赢家链”使得它本质上不可扩展，正如我们下面所示。 74 | 75 | We note that there have been several recent works revolving around new protocols for public blockchain systems. 76 | These include Bitcoin-NG [6], Byzcoin [9], a work by Decker et. al. [4], Hybrid Consensus [16], Solidus [1], and recently Algorand [11]. 77 | We discuss these and other related works in Section 6. 78 | 79 | 我们注意到最近有几项工作围绕公有区块链系统的新协议。 80 | 这些包括Bitcoin-NG [6]，Byzcoin [9]，Decker等人的工作[4]，混合共识（Hybrid Consensus）[16]，Solidus [1]和最近Algorand [11]。 81 | 我们在第6节讨论这些和其他相关的工作。 82 | -------------------------------------------------------------------------------- /Papers/SPECTRE/3.SPECTRE VS BITCOIN – OVERVIEW.md: -------------------------------------------------------------------------------- 1 | > **Source：** [https://eprint.iacr.org/2016/1159.pdf](https://eprint.iacr.org/2016/1159.pdf) 2 | > **TranStudy：** [https://github.com/DAGfans/TranStudy/new/master/Papers/SPECTRE](https://github.com/DAGfans/TranStudy/new/master/Papers/SPECTRE) 3 | 4 | # 3. SPECTRE VS BITCOIN – OVERVIEW 5 | # 3. SPECTRE VS BITCOIN – 概述 6 | 7 | 8 | SPECTRE adopts many of Bitcoin’s solution features. 9 | In particular, miners create blocks, which are batches of transactions. 10 | A valid block must contain a solution to the PoW puzzle (Bitcoin for example, uses PoW that is based on partial SHA256 collisions). 11 | The block creation rate, denoted λ, is kept constant by the protocol by occasional readjustments of the PoW difficulty; 12 | we elaborate on this mechanism in SPECTRE in Appendix D. 13 | The size of a block is limited by some B KB. 14 | 15 | SPECTRE采用了比特币的许多解决方案的功能。 16 | 特别是，矿工创建区块，即成批的交易。 17 | 一个有效的区块必须包含PoW难题的解（以比特币为例，使用基于部分SHA256冲突的PoW）。 18 | (**译注：** 这里的部分冲突指的生成的散列值不要求每一位都一样，只要部分一样就可以了) 19 | 出块率，记为λ，通过协议定期重新调整PoW难度而保持不变; 20 | 我们在附录D中详细说明了SPECTRE的这种机制。 21 | 块的大小限制为某个值B KB。 22 | 23 | Bitcoin’s throughput can be increased by increasing either the block size limit (which in turn increases D) or\and the block creation rate λ. 24 | Alas, it is well established that the security threshold of Nakamoto Consensus deteriorates as D · λ increases: 25 | 26 | 比特币的吞吐量可以通过增加块大小限制（反过来会增加D）或\和出块率λ来增大。 27 | 但是，经过充分地论证，中本聪共识的安全阈值会随着D·λ的增加而恶化： 28 | (**译注：** 这里的D其实指的是区块传播到全网的时间，所以增加区块大小会增加D，不知道为什么论文没有提前说明就直接用了) 29 | 30 | ### Theorem 2. [Bitcoin is not scalable] The security threshold of the Bitcoin protocol goes to zero as D · λ increases. 31 | 32 | ### 定理 2. [比特币是不可扩展的] 比特币协议的安全阈值随着D·λ增加而变为零。 33 | 34 | The proof of this theorem appears in various forms in previous works, see [18], [15], [7]. 35 | To maintain a high security threshold, Bitcoin suppresses its throughput by keeping λ low – 1/600 blocks per second. 36 | This large safety margin is needed because λ (and B ) are decided once and for all at the inception of the protocol. Consequently, even when the network is healthy and D is low, Bitcoin suffers from a low throughput – 3 to 7 transactions per second, and slow confirmation times – tens of minutes. 37 | In contrast, SPECTRE’s throughput can be increased without deteriorating the security threshold: 38 | 39 | 这个定理的证明在之前的工作中以各种形式出现，参见[18]，[15]，[7]。 40 | 为了保持较高的安全阈值，比特币通过保持低λ - 每秒1/600块来抑制其吞吐量。 41 | 这个较大的安全系数是必要的，因为λ（和B）是在协议在开始时决定后就不能更改了。 42 | 因此，即使网络健康且D较低，比特币的吞吐量也很低 - 每秒3到7次交易，确认时间也很慢 - 几十分钟。 43 | 相反，SPECTRE的吞吐量可以在不降低安全阈值的情况下增加： 44 | 45 | ### Theorem 3. [SPECTRE is scalable] For any D · λ, SPECTRE’s security threshold is 50%. 46 | 47 | ### 定理 3. [SPECTRE 是可扩展的] 对于任何D·λ，SPECTRE的安全阈值为50％。 48 | 49 | Therefore, in the context of the Distributed Algorithms literature, SPECTRE falls into the partial synchronous setup, as it remains secure for any value of D. Theorem 3 is proven rigorously in Appendix E. 50 | 51 | 因此，根据分布式算法文献的分类，SPECTRE的设定属于部分同步，因为对任何D值都是安全的。定理3在附录E中得到了严格证明。 52 | (**译注：** 部分同步是指D值虽然存在网络延迟的上限，但是我们事先不知道。比如说网络实际上要1分钟才能传播到大部分节点，但因为我网络状况比较好，我就估算只要半分钟，这样会造成只有网络状况好的部分节点才能和我保持同步，其他的节点就同步不了了，所以成为部分同步。) 53 | 54 | Of course, λ cannot be increased indefinitely or otherwise the network will be flooded with messages (blocks) and become congested. 55 | Theorem 3 “lives” in the theoretical framework (specified in Section 2), which does not model the limits on nodes’ bandwidth and network capacity. 56 | Practically, these barriers allow for a throughput of thousands of transactions per second, by setting λ = 10 and b = 100, for instance. 57 | For further discussion refer to Appendices B and D. 58 | 59 | 当然，λ不能无限增加，否则网络将被消息（区块）淹没并变得拥塞。 60 | 定理3建立理论框架之上（在第2节中已具体说明），它没有模拟节点带宽和网络容量的限制。 61 | 实际上，在这些障碍下，协议还是可以允许每秒处理数千次交易，例如，通过设置λ= 10和b = 100。 62 | 有关进一步的讨论，请参阅附录B和D. 63 | 64 | Asymptotically, SPECTRE’s confirmation times are in $\mathcal{O}(\frac{ln(1/ϵ)}{λ(1-2α)}+\frac{D}{1-2α})$ . 65 | In practice, this allows for confirmation times of mere seconds, under normal network conditions. 66 | When running RobustTxO, each node in SPECTRE uses its own upper bound on the recent D in the network. 67 | This bound affects only its own operation—underestimating D will result in premature acceptance of transactions, and overestimating it by far will delay acceptance unnecessarily (by a time linear in the difference). 68 | Importantly, in case of network hiccups and long network delays, the node can switch in his local client to a more conservative bound on D without coordinating this with other nodes. 69 | 70 | 渐近地，SPECTRE的确认时间在$\mathcal{O}(\frac{ln(1/ϵ)}{λ(1-2α)}+\frac{D}{1-2α})$。 71 | (**译注：** $\mathcal{O}$ 代表趋近，上面的公式可以表示为确认时间趋近于$\frac{ln(1/ϵ)}{λ(1-2α)}+\frac{D}{1-2α}$，目前还不理解这个公式是怎么来的) 72 | 实际上，这允许在正常网络条件下仅仅几秒钟的确认时间。 73 | 运行RobustTxO时，SPECTRE中的每个节点都会在网络中最近的D上使用自己的上限。 74 | 这种限制只会影响其自身的操作 - 低估D会导致交易过早被接受，并且过高估计它将会导致不必要地延迟接受（以时间线性差异）。 75 | (**译注：** 这里的意思就是每个节点根据自身网络状况，预估参数D，因此每个节点的D可以不一样) 76 | 重要的是，在网络不稳定和网络延迟较长的情况下，节点可以将其本地客户端的D上限切换得更保守，而无需与其他节点进行协调。 77 | -------------------------------------------------------------------------------- /Papers/SPECTRE/5. HIGH - LEVEL OVERVIEW OF THE PROOF.md: -------------------------------------------------------------------------------- 1 | > **Source：** [https://eprint.iacr.org/2016/1159.pdf](https://eprint.iacr.org/2016/1159.pdf) 2 | > **TranStudy：** [https://github.com/DAGfans/TranStudy/new/master/Papers/SPECTRE](https://github.com/DAGfans/TranStudy/new/master/Papers/SPECTRE) 3 | 4 | # 5. HIGH - LEVEL OVERVIEW OF THE PROOF 5 | # 5. 证明的高层次概述 6 | 7 | 8 | We now provide some intuition as to why SPECTRE’s procedures indeed guarantee that transactions can be accepted safely, and that all transactions of honest users are quickly accepted. 9 | We aim at proving Property 4. 10 | As mentioned above, this property is easy to translate to the desired security properties of transactions (as we do formally in Appendix E). 11 | Concretely, we wish to prove the following statement (in the proposition, $G_r^{pub} := ∪_{u∈honest} G_r^u$ ): 12 | 13 | 我们现在提供一些思路，说明为什么SPECTRE的程序确实能够保证安全地接受交易，并且诚实用户的所有交易都很快被接受。 14 | 我们旨在证明属性4. 15 | 如上所述，这个属性很容易转化为期望的交易安全属性（正如我们在附录E中形式化论证的那样）。 16 | 具体而言，我们希望证明以下陈述（在命题中，$G_r^{pub} := ∪_{u∈honest} G_r^u$）： 17 | 18 | >### Proposition 19 | >Assume block x was published at time $t_{pub}(x ∈ G_{t_{pub}}^{pub} )$, and y not published before time $t_{acc}(y ∉ G_{t_{acc}}^{pub})$. [^4] 20 | >Let $T = t_{acc}-t_{pub}$ . 21 | >Then the probability that x will not always precede y ($Pr (∃u ∈ honest, ∃s ≥ t_{acc} : vote_{x,y}(virtual (G_s^u )) ≥ 0)$) decreases exponentially in T . 22 | 23 | >### 命题 24 | >假设在时间$t_{pub}(x ∈ G_{t_{pub}}^{pub} )$发布块x，并且y在时间$t_{acc}(y ∉ G_{t_{acc}}^{pub})$之前未发布。[^4] 25 | >设$T = t_{acc}-t_{pub}$。 26 | >那么x不会总是先于y的概率($Pr (∃u ∈ honest, ∃s ≥ t_{acc} : vote_{x,y}(virtual (G_s^u )) ≥ 0)$) 在T中呈指数下降。 27 | 28 | *Proof overview.* 29 | Assume that the event in which y comes to precede x in some future DAG occurs. 30 | Let s be the earliest moment in time that such an event occurred at some node. 31 | Notice that y cannot be in the past of x or in its future (otherwise their order is determined by the topology and cannot be reversed). 32 | We thus assume henceforth $y ∈ anticone (x)$. 33 | 34 | *证明概述.* 35 | 假设在未来的某个DAG中，发生了y出现在x之前的事件。 36 | 假设s是某个节点发生该事件的最早时刻。 37 | 请注意，y不能位于x的过去集或者将来集（否则它们的顺序由拓扑决定，不能颠倒）。 38 | （**译注：** 划重点） 39 | 因此我们假设$y ∈ anticone (x)$。 40 | 41 | **The block race after x is published.** We first consider the votes of blocks created after the publication of block x: 42 | 43 | * (Almost) all honest blocks created between $t_{pub}$ and $t_{acc}$ vote forever in favour of $x≺y$ , as they have x in their past but not y . Denote by $n_1$ the number of such blocks. 44 | 45 | * All honest blocks created between $t_{acc}$ and s vote in favour of $x≺y$ , as well, by the choice of s. Denote by $n_2$ the number of such blocks. 46 | 47 | * Denote by $m_1$ and $m_2$ the number of blocks created by the attacker in the time intervals corresponding to $n_1$ and $n_2$ . Honest nodes possess a fraction $1-α > α$ of the computational power. Consequently, for any positive constant C , the probability that the relation $m_1+m_2+C-(n_1 + n_2 ) ≥ 0$ will ever be satisfied decreases exponentially with $n_1$ . This is typically analyzed as the probability that a biased random walk on the integers, beginning at C , returns to the origin (see [13], [17], [18]). 48 | 49 | **x发布后的区块竞争.** 我们首先考虑在区块x发布后创建的区块投票： 50 | 51 | * （几乎）在$t_{pub}$ 和$t_{acc}$之间创建的所有诚实区块永远投票支持$x≺y$，因为他们在过去有x，但不是y。 用$n_1$表示这种块的数量。 52 | 53 | * 在$t_{acc}$和s之间的创建的所有诚实区块也都投票支持$x≺y$，直到时间点s。 用$n_2$表示这种块的数量。 54 | 55 | * 用$m_1$和$m_2$表示攻击者在对应于$n_1$和$n_2$的时间间隔中创建的块的数量。 诚实的节点具有计算能力的比例$1-α > α$。 因此，对于任何正常数C，满足关系$m_1+m_2+C-(n_1 + n_2 ) ≥ 0$的概率将会满足$n_1$指数级下降。 这通常被分析为从C开始的整数上的偏见随机游走返回原点的概率（参见[13]，[17]，[18]）。（**译注：** 随机游走就是指随机的分布，比如说设x, y在[-1，1]内随机抽取，形成一个坐标，点数足够多会近似一个圆，这里“偏见”体现在概率的分布是不一样的，比如说抽取到0的概率大于抽取到1的概率，这里也是这个意思，如果是以常数C为原点，则随机选择大于或等于C的点，但是越接近C被抽取的概率就越高，最终平均值趋近于C） 56 | 57 | The term $m_1+m_2+C-(n_1 + n_2 )$ represents the aggregate vote between x and y , considering only blocks created after x’s publication. 58 | We now show that blocks that the attacker prepared in advance before x’s publication, in a preparatory “pre-mining” stage, do not give him more than some constant advantage (which will be counted into C above). 59 | 60 | 术语$m_1+m_2+C-(n_1 + n_2 )$表示x和y之间的总体投票，仅考虑x发布后创建的块。 61 | 我们现在证明，即使攻击者在x发布之前的准备阶段“预挖矿”，也并不会给予它带来某些恒定的优势（这将被计算在上面的C中）。 62 | （**译注：** 这里的C代表的就是预挖矿的挖出的数量） 63 | 64 | [^4]: Intuitively, $t_{acc}$ represents the time at which some node accepted a transaction which appears in block x. 65 | 直观上可以将$t_{acc}$理解为某个节点在区块x发布前接受了了一笔存在于x的交易 66 | 67 | >### The pre-mining stage 68 | >Honest blocks that were created before x was published are typically in its past (apart from a small set of blocks) and hence have their vote decided by the majority of votes in their future (as per Alg. 1). 69 | >Their vote is thus possibly subject to change as the DAG grows, and as the attacker publishes blocks. 70 | 71 | > ### 预挖矿阶段 72 | >在x发布之前创建的诚实区块通常在它过去集中（除了一小部分区块），因此他们的投票将在未来的大多数投票中决定（根据算法1）。 73 | >因此，他们的投票可能随着DAG的增长而发生变化，并且攻击者也会发布区块。 74 | 75 | For every block z in the past of x we must therefore consider the number of blocks above it that vote in favour of x and those that vote against it. 76 | Denote by $X_z$ the gap between the number of attacker blocks and honest blocks in the future of z , up to time $t_{pub}$ . 77 | In Lemma 24 we show that the worst case gap $X_z$ (over all blocks $z ∈ past (x)$) can be modeled as a reflecting random walk over the nonnegative integers, with bias towards the origin. 78 | Consequently, the best gap that the attacker can secretly gain over a block in $past (x)$ has an exponentially decaying tail, and, in particular, is bounded by a constant w.h.p. 79 | 80 | 因此，对于x的过去集的每个块z，我们因此必须认为支持x的区块数量大于支持y的。 81 | 用$X_z$表示到时间$t_{pub}$时z的未来攻击者块和诚实块之间的差值。 82 | 在引理24中，我们证明最坏情况差值$X_z$（相对于过去集中所有的块z，即$z ∈ past (x)$）可以被建模为在一个非负整数上的上下随机浮动，且不断地往原点靠近。 83 | 因此，攻击者可以私自地获得在与$past (x)$中块的最大差值会指数级衰减，特别是会很大概率下限定在一个常量内。 84 | 85 | All in all, as $t_{acc}-t_{pub}$ grows, the number $n_1$ of votes, or “confirmations”, that x receives increases linearly, and the probability that the attacker will be able to reveal enough blocks so that some $z ∈ past (x)$ will have more $y≺x$ votes in its future than $x≺y$ votes, decreases exponentially in $n_1$ . 86 | Since this holds for all $z ∈ past (x)$ uniformly, it implies in particular that the genesis block has more $x≺y$ votes in its future than $y≺x$ votes (unless an exponentially unlikely event occurred). 87 | The vote of the virtual block is determined by that of the genesis block (this is easy to see, and is proven in Lemma 13), completing the argument. 88 | 89 | 总而言之，随着$t_{acc}-t_{pub}$的增长，x接收的投票数$n_1$或“确认”线性增加，因此攻击者能够展示足够多的区块从而对于$z ∈ past (x)$在其未来集中将会有$y≺x$的票数多于$x≺y$ 的概率，以$n_1$指数级别降低。 90 | 因为这对所有的$z ∈ past (x)$一致，特别意味着创世区块的未来集中投$x≺y$ 比投$y≺x$多（除非发生指数级别的低概率事件）。 91 | 虚拟块的投票是由创世块的投票决定（很容易看出来，并在引理13中得到证实）。 92 | (**译注:** 因为创世块是的未来集是其他所有块,然后创世块服从大多数的投票) 93 | 94 | The proposition above is the gist of Lemmas 14 and 15. 95 | In the above sketch, we abstracted out many additional subtleties and details. 96 | For instance, honest blocks that were created D seconds around $t_{pub}$ , $t_{acc}$ , or s may not have contributed votes in favour of x. 97 | In our formal analysis (Appendix E) we count these as attacker blocks, accounting for the worst case, and add them to the aforementioned constant C . 98 | We additionally show how the user can measure $n_1$ correctly, even if the attacker publishes his blocks in an attempt to delay acceptance. 99 | 100 | 上面的命题是引文14和15的要点。 101 | 在上面的概述中，我们忽略了许多额外的细节。 102 | 例如，在$t_{pub}$，$t_{acc}$或s前后D秒附近, 诚实的块可能没有投票支持x。 103 | 在我们的形式分析（附录E）中，我们将这些数据视为攻击者区块，考虑最坏的情况，并将其添加到上述常数C中。 104 | (**译注:** 诚实的块也是可以视作攻击) 105 | 我们还展示了用户如何正确测量$n_1$ ，即使攻击者发布他的区块以试图延迟接受。 106 | -------------------------------------------------------------------------------- /Papers/SPECTRE/6. RELATED WORK.md: -------------------------------------------------------------------------------- 1 | > **Source：** [https://eprint.iacr.org/2016/1159.pdf](https://eprint.iacr.org/2016/1159.pdf) 2 | > **TranStudy：** [https://github.com/DAGfans/TranStudy/new/master/Papers/SPECTRE](https://github.com/DAGfans/TranStudy/new/master/Papers/SPECTRE) 3 | 4 | 5 | # 6. RELATED WORK 6 | # 6. 相关工作 7 | 8 | 9 | Previous research has produced several suggestions for protocols that attempt to address the security-scalability challenge, but all protocols still provide a total order over blocks: 10 | 11 | 先前的研究已经为试图解决安全性-可扩展性矛盾的挑战的协议提出了一些建议，但所有协议仍然是基于区块全序： 12 | 13 | GHOST is an alternative chain selection rule that gradually chooses a tree of blocks until converging on a single chain [18]. 14 | It can be shown that the Liveness property of GHOST can be attacked, as was demonstrated by [8]. 15 | The use of block DAGs was proposed in the Inclusive work [10], in which throughput was increased by integrating off-chain blocks into the ledger. 16 | Due to the reliance on a chain, Inclusive mitigates but does not avoid the security-scalability trade-off. 17 | The Inclusive paper further includes a game theoretic analysis of the incentives of nodes to embed different transactions in their blocks (without the ability to coordinate). [^5] 18 | 19 | GHOST是一种可供选择的链选择规则，它逐渐选择一个区块树，直到收敛到一个单一链上[18]。 20 | 可以证明GHOST的活性可以被攻击，如[8]所证明的那样。 21 | 在Inclusive工作[10]中提出了块DAG的使用，其中通过将链下区块集成到账本中来提高吞吐量。 22 | 由于对链的依赖，Inclusive可以缓解但不能避免安全性-可扩展性矛盾。 23 | Inclusive论文进一步提供了对节点在其块中嵌入不同交易（不存在协调的情况下）的激励的博弈理论分析。[^5] 24 | (**译注:** 由于交易提交的异步性, 很难避免在不同区块中嵌入同一笔交易,造成账本的冗余以及一定的带宽开销, 但是Inclusive通过经济模型会让矿工不愿意将重复的交易打到区块中) 25 | 26 | Bitcoin-NG [6] provides a clever chain structure that is composed of two types of blocks: 27 | key blocks that require PoW but contain no transactions, and mini-blocks that do not require PoW but do contain transactions. 28 | Bitcoin-NG manages to obtain a significant scalability increase, but its key blocks are still generated slowly, hence, confirmation times remain high. 29 | Another line of work bootstraps PoW to instantiate a committee that is later used to run classical BFT protocols. 30 | Examples from this line of research include Byzcoin [9], a work by Decker et. al. [4], Hybrid Consensus [16], and recently Solidus [1]. 31 | Protocols built in this manner are highly scalable, building upon work in consensus protocols, but lack some of the properties achieved by Bitcoin. 32 | They typically require large committees and require committee members to remain online for long periods of time, making them susceptible to network isolation and DoS attacks. [9], [4], [1] 33 | additionally fail without recovering if the committee is ever composed of a high fraction of malicious entities (Bitcoin, on the other hand, is self-stabilizing). 34 | Moreover, they require forward secrecy. 35 | If the cryptographic keys of a sufficient fraction of the committee at any point in the past is compromised, the attacker can create an alternative equally acceptable version of events. 36 | 37 | Bitcoin-NG [6]提供了一种巧妙的链结构，它由两种类型的区块组成： 38 | 需要PoW但不包含交易的关键块，以及不需要PoW但包含交易的小块。 39 | Bitcoin-NG设法获得显着的可扩展性增长，但其关键块仍然生成缓慢，因此确认时间仍然很长。 40 | 还有一系列工作使用PoW创建委员会来运行传统BFT协议。 41 | 这一系列研究的例子包括Byzcoin [9]，Decker等人的工作 [4]，混合共识[16]，以及最近的Solidus [1]。 42 | 以这种方式构建的协议具有高度可扩展性，以共识协议中的工作为基础，但牺牲了某些比特币已实现的特性。 43 | 他们通常需要大型委员会，并要求委员会成员长时间保持在线状态，这使他们很容易受到网络隔离和DoS攻击[9]，[4]，[1]。 44 | 如果委员会由大量恶意实体组成（比特币则可以自我稳定），则还会导致失败而无法恢复。 45 | 而且，他们需要前向安全性。 46 | (**译注:** 如果系统具有前向安全性，就可以保证在主密钥泄露时历史记录的安全) 47 | 如果在过去的任何时候足够比例的委员会的加密密钥泄露了，攻击者可以创建另一个同样可接受的事件的版本。 48 | (**译注:** 这里的攻击用的是compromise, 指的是类似于诈骗或者钓鱼那样的被动攻击获得隐私信息, 和入侵hack有明显的区别, 这里的事件可以简单理解为交易) 49 | 50 | The Algorand protocol [11] is a proof-of-stake based algorithm that uses the ownership of currency itself to achieve a scalable consensus protocol. 51 | It utilizes additional techniques (based on VRFs) to hide the committee members that take place in the consensus protocol. 52 | In contrast, miners in SPECTRE are not directly involved in any explicit consensus protocol and moreover can operate with little regard of other nodes’ synchronization status. 53 | Honey Badger [12] is an atomic broadcast protocol that is oblivious to network parameters and does not require tuning under different network conditions (similarly to SPECTRE). 54 | It is set in the classical permissioned setting where identities of the participants are known. 55 | 56 | Algorand协议[11]是一种基于股权证明(proof-of-stake)的算法，它使用货币本身的所有权来实现可扩展的共识协议。 57 | (**译注:** 这里没有采用流行的“权益证明”的翻译, 是因为“股”对PoS来说具有高度的概括性) 58 | 它利用额外的技术（基于VRF）隐藏在共识协议中发生的委员会成员。 59 | (**译注:** VRF 是Verifiable Random Function, 可以理解为一个随机的抽签算法, 利用这个算法可以从大量的节点中抽取一部分节点成为委员会, 可以提高BFT的效率. ) 60 | 相比之下，SPECTRE中的矿工并不直接参与任何明确的共识协议，而且可以在很少考虑其他节点的同步状态的情况下运行。 61 | (**译注:** 这里不知道如何理解, 在我看来SPECRE就算是共识协议了) 62 | Honey Badger [12]是一种原子广播协议，它可以无视网络参数，不需要在不同的网络条件下进行调整（类似于SPECTRE）。 63 | 它工作在在经典的许可环境下，参与者的身份是已知的。 64 | 65 | [^5]: We build on this argument, and indeed assume that nodes will maximize their profits by avoiding transaction “collisions” and will try to embed unique content in their blocks. 66 | 我们建立在这个论点之上，并且假设节点将通过避免交易“碰撞”来最大化他们的利益，并且将尝试在其块中嵌入独特的内容。 67 | -------------------------------------------------------------------------------- /Papers/SPECTRE/7. CONCLUSION.md: -------------------------------------------------------------------------------- 1 | > **Source：** [https://eprint.iacr.org/2016/1159.pdf](https://eprint.iacr.org/2016/1159.pdf) 2 | > **TranStudy：** [https://github.com/DAGfans/TranStudy/new/master/Papers/SPECTRE](https://github.com/DAGfans/TranStudy/new/master/Papers/SPECTRE) 3 | 4 | 5 | # 7. CONCLUSION 6 | # 7. 结论 7 | 8 | 9 | In this work we presented SPECTRE, a new cryptocurrency protocol that is inherently scalable. 10 | Unlike Bitcoin and its many variants, SPECTRE is secure against attackers with less than 50% of the computational power, even when its throughput is increased and the propagation delay becomes non-negligible. 11 | Our results demonstrate that SPECTRE can achieve incredibly low confirmation times, especially compared to Nakamoto Consensus. 12 | Further work to improve and tighten the acceptance policy we derived can lower confirmation times further. 13 | Key to SPECTRE’s achievements is its willingness to delay the decision regarding visibly double-spent transactions. 14 | It thus solves a weaker problem than traditional consensus protocols. 15 | This fact also makes it less suitable for systems like Ethereum, where a total order over transactions is required 16 | 17 | 在本论文中，我们介绍了SPECTRE，一种新的加密货币协议，具有内在的可扩展性。 18 | 与比特币及其众多变体不同，即使其吞吐量增加并且传播延迟变得不可忽略，SPECTRE也可以安全抵御计算能力不足50％的攻击者。 19 | 我们的研究结果表明，SPECTRE可以实现令人难以置信的低确认时间，特别是与中本聪共识相比。 20 | 进一步改进和收紧我们生成的接受规则可进一步缩短确认时间。 21 | SPECTRE的成就关键在于它延迟了明显的双花交易的决定时间。 22 | 因此它解决了一个比传统共识协议更弱的问题。 23 | 这一事实也使得它不太适合像以太坊这样的系统，因为它们需要交易的全序 24 | 25 | The core algorithm of SPECTRE – the pairwise voting procedure (Alg. 1) – is nontrivial. 26 | We encourage the reader to refer to Appendix A for intuition and illustrations about its operation. 27 | SPECTRE的核心算法 - 成对投票程序（算法1） - 是不平凡的。 28 | 我们鼓励读者参考附录A中的思路和操作说明。 29 | 30 | REFERENCES 31 | 参考 32 | 33 | [1] Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Alexander Spiegelman. Solidus: An incentive-compatible cryptocurrency based on permissionless byzantine consensus. arXiv preprint arXiv:1612.02916, 2016. 34 | 35 | [2] Kenneth J Arrow, Amartya Sen, and Kotaro Suzumura. Handbook of Social Choice & Welfare, volume 2. 36 | 37 | Elsevier, 2010. 38 | 39 | [3] Miguel Correia, Nuno Ferreira Neves, and Paulo Ver´ıssimo. From consensus to atomic broadcast: Time-free byzantine-resistant protocols without signatures. The Computer Journal, 49(1):82–96, 2006. 40 | 41 | [4] Christian Decker, Jochen Seidel, and Roger Wattenhofer. Bitcoin meets strong consistency. In Proceedings of the 17th International Conference on Distributed Computing and Networking, page 13. ACM, 2016. 42 | 43 | [5] Christian Decker and Roger Wattenhofer. Information propagation in the bitcoin network. In 13th IEEE International Conference on Peer-to-Peer Computing (P2P), Trento, Italy, September 2013. 44 | 45 | [6] Ittay Eyal, Adem Efe Gencer, Emin G¨un Sirer, and Robbert Van Renesse. Bitcoin-ng: A scalable blockchain protocol. In 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI 16), pages 45–59, 2016. 46 | 47 | [7] Juan Garay, Aggelos Kiayias, and Nikos Leonardos. The bitcoin backbone protocol: Analysis and applications. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 281–310. Springer, 2015. 48 | 49 | [8] Aggelos Kiayias and Giorgos Panagiotakos. On trees, chains and fast transactions in the blockchain. Cryptology ePrint Archive, Report 2016/545, 2016. 50 | 51 | [9] Eleftherios Kokoris-Kogias, Philipp Jovanovic, Nicolas Gailly, Ismail Khoffi, Linus Gasser, and Bryan Ford. 52 | 53 | Enhancing bitcoin security and performance with strong consistency via collective signing. In 25th USENIX Security Symposium, USENIX Security 16, Austin, TX, USA, August 10-12, 2016., pages 279–296, 2016. 54 | 55 | [10] Yoad Lewenberg, Yonatan Sompolinsky, and Aviv Zohar. Inclusive block chain protocols. In International Conference on Financial Cryptography and Data Security, pages 528–547. Springer, 2015. 56 | 57 | [11] Silvio Micali. Algorand: the efficient and democratic ledger. arXiv preprint arXiv:1607.01341, 2016. 58 | 59 | [12] Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song. The honey badger of bft protocols. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pages 31–42. ACM, 2016. 60 | 61 | [13] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008. 62 | 63 | [14] Rafael Pass, Lior Seeman, and Abhi Shelat. Analysis of the blockchain protocol in asynchronous networks. 64 | 65 | IACR Cryptology ePrint Archive, 2016:454, 2016. 66 | 67 | [15] Rafael Pass, Lior Seeman, and Abhi Shelat. Analysis of the blockchain protocol in asynchronous networks. 68 | 69 | IACR Cryptology ePrint Archive, 2016:454, 2016. 70 | 71 | [16] Rafael Pass and Elaine Shi. Hybrid consensus: Efficient consensus in the permissionless model. Cryptology ePrint Archive, Report 2016/917, 2016. 72 | 73 | [17] Meni Rosenfeld. Analysis of hashrate-based double spending. arXiv preprint arXiv:1402.2009, 2014. 74 | 75 | [18] Yonatan Sompolinsky and Aviv Zohar. Secure high-rate transaction processing in bitcoin. In International Conference on Financial Cryptography and Data Security, pages 507–527. Springer, 2015. 76 | -------------------------------------------------------------------------------- /Papers/SPECTRE/ABSTRACT.md: -------------------------------------------------------------------------------- 1 | > **Source：** [https://eprint.iacr.org/2016/1159.pdf](https://eprint.iacr.org/2016/1159.pdf) 2 | > **TranStudy：** [https://github.com/DAGfans/TranStudy/new/master/Papers/SPECTRE](https://github.com/DAGfans/TranStudy/new/master/Papers/SPECTRE) 3 | 4 | # SPECTRE: 5 | 6 | ### Serialization of Proof-of-work Events: Confirming Transactions via Recursive Elections 7 | ### 工作量证明事件的排序: 通过递归投票来确认交易 8 | 9 | ### Yonatan Sompolinsky, Yoad Lewenberg, and Aviv Zohar 10 | 11 | ### School of Engineering and Computer Science, The Hebrew University of Jerusalem, Israel 12 | ### 以色列耶路撒冷希伯来大学工程与计算机科学学院 13 | 14 | ### {yoni sompo,yoadlew,avivz}@cs.huji.ac.il 15 | 16 | ## Abstract 17 | ## 摘要 18 | 19 | Bitcoin utilizes the Nakamoto Consensus to achieve agreement on a consistent set of transactions, in the permissionless setting, where anyone can participate in the protocol anonymously. 20 | Since its rise, many other permissionless consensus protocols have been proposed. 21 | We present SPECTRE, a new protocol for the consensus core of cryptocurrencies that remains secure even under high throughput and fast confirmation times. 22 | At any throughput, SPECTRE is resilient to attackers with up to 50% of the computational power (reaching the limit defined by network congestion and bandwidth constraints). 23 | SPECTRE can operate at arbitrarily high block creation rates, which implies that its transactions confirm in mere seconds (limited mostly by the round-trip-time in the network). 24 | 25 | 比特币利用中本聪共识在无需许可的环境下就一系列交易达成协议，任何人都可以匿名参与协议。 26 | 自从它的崛起以来，已经提出了许多其他无需许可的共识协议。 27 | 我们推出了SPECTRE，一个即使在高吞吐量和快速确认时间下仍保持安全的加密货币的共识核心的新协议。 28 | 在任何吞吐量情况下，SPECTRE具有对计算能力占比高达50%的攻击者的可恢复性（达到网络拥塞和带宽限制所定义的极限）。 29 | SPECTRE可以以任意高的区块创建速率运行，这意味着其交易仅在几秒钟内（主要受限于网络中的往返时间）确认。 30 | 31 | SPECTRE’s underlying model falls into the category of partial synchronous networks: its security depends on the existence of some bound on the delivery time of messages between honest participants, but the protocol itself does not contain any parameter that depends on this bound. 32 | Hence, while other protocols that do encode such parameters must operate with extreme safety margins, SPECTRE converges according to the actual network delay. 33 | 34 | SPECTRE的基础模型属于部分同步网络的范畴：其安全性取决于诚实参与者之间的消息传递时间的上限，但协议本身不包含依赖于该上限的任何参数。 35 | 因此，尽管编码这些参数的其他协议必须以极高的安全系数运行，但SPECTRE会根据实际的网络延迟收敛。 36 | （**译注：** 比如说比特币为了降低分叉概率，把出块时间设置为10分钟就是一个很高的安全系数） 37 | 38 | Key to SPECTRE’s achievements is the fact that it satisfies weaker properties than classic consensus requires. 39 | In the conventional paradigm, the order between any two transactions must be decided and agreed upon by all non-corrupt nodes. 40 | In contrast, SPECTRE only satisfies this with respect to transactions performed by honest users. 41 | We observe that in the context of money, two conflicting payments that are published concurrently could only have been created by a dishonest user, hence we can afford to delay the acceptance of such transactions without harming the usability of the system. 42 | Our framework formalizes this weaker set of requirements for a cryptocurrency’s distributed ledger. 43 | We then provide a formal proof that SPECTRE satisfies these requirements. 44 | 45 | SPECTRE成就的关键在于它只需满足比传统共识所要求的更弱的属性。 46 | 在传统模型中，任何两个交易之间的顺序必须由所有非损坏节点决定并同意。 47 | （**译注：** 这里的非损坏节点应该就是包括了作恶节点，因为下面SPECTRE与之比较的是诚实节点） 48 | 相反，SPECTRE只需满足诚实用户进行的交易。 49 | 我们观察到，在作为货币的场景下，同时发布的两个冲突的支付只能由非诚实的用户创建，因此我们可以承担延迟接受这种交易而不影响系统的使用性。 50 | 我们的框架先形式化定义了该加密货币的分布式账本所需的弱要求的集合。 51 | 然后我们提供一个SPECTRE满足这些要求的形式化证明。 52 | -------------------------------------------------------------------------------- /Papers/SPECTRE/APPENDIX B SIMULATION RESULTS.md: -------------------------------------------------------------------------------- 1 | > **Source：** [https://eprint.iacr.org/2016/1159.pdf](https://eprint.iacr.org/2016/1159.pdf) 2 | > **TranStudy：** [https://github.com/DAGfans/TranStudy/new/master/Papers/SPECTRE](https://github.com/DAGfans/TranStudy/new/master/Papers/SPECTRE) 3 | 4 | # APPENDIX B SIMULATION RESULTS 5 | # 附录B 模拟结果 6 | 7 | We implemented the SPECTRE protocol in Python along with an event-driven simulator of network dynamics. 8 | For each experiment we generated an Erd˝os-R´enyi random network topology with 20 nodes. 9 | Each node forms 5 outgoing links, in expectation. 10 | The delay on each link was uniformly distributed and later scaled linearly so that the diameter of the graph is D (for the given D). 11 | Every point represents the average outcome over at least 500 experiments. 12 | 13 | 我们在Python中实现了SPECTRE协议以及一个事件驱动的网络动态模拟器。 14 | 对于每个实验，我们生成了具有20个节点的Erd˝os-R'enyi随机网络拓扑。 15 | 预期每个节点形成5个对外的连接。 16 | 每个连接上的延迟均匀分布，然后线性缩放，使得图的直径为D（对于给定的D）。 17 | 每个点代表至少500次实验的平均结果。 18 | 19 | 20 | The main benefit of SPECTRE is fast transaction confirmation. 21 | The asymptotic waiting times derived from our formal analysis are in $O(\frac{ln(1/\varepsilon )}{\lambda (1-2\alpha )}+\frac{D}{1-2\alpha })$. 22 | In order to measure the actual waiting times, we utilized the online acceptance policy derived by Alg. 7. 23 | Accordingly, we stress that the merchant needs to wait additional D seconds in order to verify that no double-spend has been released in the past D seconds, as explained at the end of Appendix C. 18 24 | 25 | SPECTRE的主要好处是快速的交易确认。 26 | 通过我们的形式化分析得到渐进等待时间在 $O(\frac{ln(1/\varepsilon )}{\lambda (1-2\alpha )}+\frac{D}{1-2\alpha })$ 以内。 27 | 为了测量实际的等待时间，我们采用了算法7中生成的在线接受策略。 28 | 因此，我们强调商家需要额外等待D秒才能确认在过去的D秒内没有发生双花，如附录C末尾所述。 29 | 30 | How does the delay diameter affect acceptance times? 31 | Given that block creation rate is high, most of the waiting time for acceptance is dominated by the block propagation delay. 32 | Fig. 5 depicts the transaction acceptance times of SPECTRE, for various values of the delay diameter D, and for different security thresholds. 33 | Note that, unlike the Nakamoto Consensus, D affects the acceptance time of transactions but not their security. 34 | 35 | 延迟直径是怎样影响接受时间的？ 36 | 鉴于出块率高，大多数的接受等待时间是由区块传播时间决定的。 37 | 图5描绘了SPECTRE的交易接受时间, 针对多种延迟直径D, 以及不同的安全阈值。 38 | 请注意，与中本聪共识不同，D影响交易的接受时间，但不影响其安全性。 39 | 40 | 2018-07-17 2 09 12 41 | 42 | Fig. 5: The average time for a transaction to enter RobustTxO, assuming there’s no visible double-spend, for $\lambda = 10$ blocks per second and $\alpha = 0.25$. 43 | 44 | 图5：交易进入RobustTxO状态的平均时间，假设没有可见的双花，$\lambda = 10$块每秒，$\alpha = 0.25$。 45 | 46 | How does the block creation rate affect acceptance times? 47 | Fig. 6 depicts the acceptance times for various values of the block creation rate $\lambda$, under a constant delay $d = 5$ seconds. 48 | The graph reaffirms the role of $\lambda$ in our asymptotic bound: accelerating the block creation process allows for faster acceptance times. 49 | For comparison, Bitcoin’s block creation rate of 1/600 implies waiting times that are orders of magnitudes higher (not plotted). 50 | 51 | 出块率如何影响接受时间？ 52 | 图6描绘了在延迟恒定为$d = 5$秒时, 多种出块率$\lambda$对应的接受时间。 53 | 图表重现了$\lambda$在我们的渐近界中的作用：加速块创建过程允许更快的接受时间。 相比之下，比特币的出块率为1/600意味着等待时间更高（未绘制）。 54 | 55 | Fig. 6: The average time for a transaction to enter RobustTxO, assuming there’s no visible double-spend, for d = 5 seconds and $\alpha = 0.25$. 56 | 57 | 图6：交易进入RobustTxO集的平均时间，假设没有可见的双花交易，d = 5秒且$\alpha = 0.25$。 58 | 59 | Can an attacker delay acceptance? We now turn to demonstrate the effect of censorship attacks in which some dishonest nodes publish blocks that do not reference other miners’ blocks. Recall that the Weak Liveness property of SPECTRE (Proposition 3) guarantees fast acceptance of transactions that are not visibly double-spent, even in the presence of a censorship attack. However, such an attack still causes some delay in transaction acceptance, but this delay is minor for small attackers. 60 | 61 | 攻击者可以延迟接受交易吗？我们现在转向展示审查攻击的影响，其中一些不诚实的节点发布不引用其他矿工块的块。回想一下，即使在存在审查攻击的情况下，SPECTRE（命题3）的弱活性属性也能保证快速接受不明显双花的交易。但是，这种攻击仍会导致交易接受延迟，但对于小型攻击者来说这种延迟是微不足道的。 62 | 63 | In Fig. 7 we quantify this effect, by comparing the acceptance times in “peace days” to those under an active censorship attack. The parameters here are d = 5 seconds, $\lambda = 10$ blocks per second, and $\varepsilon = 0.01$. The results display a modest effect of the attack, and they show that in order to delay transaction acceptance by more than 5 to 10 seconds an attacker must possess a significant share of the computational power in the network. 64 | 65 | 在图7中，我们通过比较“和平日”中的接受时间与主动审查攻击下的接受时间来量化这种影响。这里的参数是d = 5秒，每秒$\ lambda =10$块，$\ varepsilon = 0.01$。结果显示了攻击的适度影响，并且它们表明，为了使交易接受延迟超过5到10秒，攻击者必须占有网络算力的重要份额。 66 | 67 | 2018-07-17 2 10 03 68 | 69 | Fig. 7: The average time for a transaction to enter RobustTxO, assuming there’s no visible double-spend, for $d = 5$ seconds, $\lambda = 10$ blocks per second, and $\varepsilon = 0.01$, in the presence and in the absence of a censorship attack. 70 | 71 | 图7：交易进入RobustTxO集的平均时间，假设没有可见的双花交易，$d = 5$秒，$\lambda = 10$块，$\varepsilon = 0.01$，在存在和不存在的审查攻击的情况下。 72 | 73 | How does $\varepsilon$ decrease for various sizes of the attacker? Once an honest node $\varepsilon$-accepts a transaction, there’s still a small risk ($\varepsilon$) that it would eventually be rejected. We show that the probability of this event vanishes quickly, even for an extremely capable attacker (e.g., with $\alpha = 0.4$ of the hashrate). This is illustrated in Fig. 8, assuming $d = 5$ seconds and $\lambda = 10$ blocks per second (notice that the y-axis is in log scale). 74 | 75 | 对于各种规模的攻击者，$\varepsilon$如何降低？一旦诚实的节点$\varepsilon$接受了一笔交易，那么它最终将被拒绝的风险很小（$\varepsilon$）。我们表明，即使对于一个非常有能力的攻击者（例如，使用$\alpha = 0.4$的哈希值），此事件的概率也会很快消失。这在图8中示出，假设$d = 5$秒并且$\lambda = 10$每秒块（注意y轴是对数刻度）。 76 | 77 | How tight is our security analysis? The analysis on which Alg. 3 relies makes several worst-case assumptions in order to bound the probability of a successful attack, e.g., that the attacker can broadcast blocks to and receive blocks from all nodes without any delay (see Appendix E, mainly Lemmas 14 and 20). 78 | 79 | 我们的安全分析有多严谨？算法3的分析依赖于做出几个最坏情况假设以限制攻击成功的概率，例如，攻击者可以毫无延迟地向所有节点广播块和接收块（参见附录E，主要是Lemmas 14和20）。 80 | 81 | Accordingly, the analysis is not tight, and in reality attacks are in fact less likely to succeed. In Fig. 9, we depict the comparison between the analytical bound and two different empirical simulations. In these simulations we explicitly generate blocks for the attacker and simulate the optimal double-spending attack. We repeat the experiment 10,000 times for each point in the graph, and measure the empirical success rate. 82 | 83 | 因此，分析并不严谨，在现实中，攻击实际上不太可能成功。在图9中，我们描绘了分析界限和两种不同的经验模拟实验之间的比较。在这些模拟中，我们显式地生成攻击者的块，并模拟最优的双花攻击。我们对图中的每个点重复实验10,000次，并测量经验成功率。 84 | 85 | The simulations assume two types of attackers: a worst-case attacker that is able to transmit and receive blocks with no delays, and a more realistic attacker that is connected to other nodes with typical delays. We compared the fraction of successful attacks under these setups to the analytical risk calculated by SPECTRE’s policy (Alg. 7). 86 | 87 | 模拟假设有两种类型的攻击者：能够发送和接收没有延迟的块的最坏情况的攻击者，和接到具有典型延迟的其他节点的更现实的攻击者。我们将这些设置下成功攻击的比例与SPECTRE策略计算的分析风险进行了比较（算法7）。 88 | 89 | The results show that the risk considered by SPECTRE’s RiskTxAccept indeed upper bounds the actual risk, and that transactions are even safer than we guarantee formally. 90 | 91 | 结果表明，SPECTRE的RiskTxAccept考虑的风险确实是实际风险的上限，这些交易甚至比我们一般保证的交易更安全。 92 | 93 | 2018-07-17 2 26 21 94 | 95 | Fig. 8: The probability of a successful double-spending attack, as a function of the waiting time before acceptance, under $d = 5$ seconds and $\lambda = 10$ blocks per second, for $\alpha$ = 0.1, 0.25, and 0.4. The probability here is the result of the calculation performed by Alg.3. 96 | 97 | 图8：成功的双花攻击的概率，作为接受前等待时间的函数，在$d = 5$秒和每秒$\lambda = 10$块之间，$\ alpha$= 0.1， 0.25和0.4。这里的概率是算法3计算的结果。 98 | 99 | 2018-07-17 2 27 17 100 | 101 | Fig. 9: The analytical vs. empirical probabilities of a successful double-spending attack, as a function of the waiting time before acceptance, under $d = 5$ seconds, $\lambda = 10$, and $\alpha = 0.25$. 102 | 103 | 图9：成功的双花攻击的分析概率对比经验概率，作为接受前等待时间的函数，在$d = 5$秒，$\lambda = 10$和$\alpha = 0.25$。 104 | -------------------------------------------------------------------------------- /Papers/Utreexo/0-Abstract.md: -------------------------------------------------------------------------------- 1 | > Source: https://eprint.iacr.org/2019/611.pdf 2 | 3 | # Utreexo: A dynamic hash-based accumulator optimized for the Bitcoin UTXO set 4 | 5 | # Utreexo: 针对比特币UTXO集优化的基于哈希的动态累加器 6 | 7 | > Thaddeus Dryja tdryja@media.mit.edu 8 | > MIT Digital Currency Initiative 9 | 10 | ## Abstract 11 | In the Bitcoin consensus network, all nodes come to agreement on the set of Unspent Transaction Outputs (The “UTXO” set). 12 | The size of this shared state is a scalability constraint for the network, as the size of the set expands as more users join the system, increasing resource requirements of all nodes. 13 | Decoupling the network’s state size from the storage requirements of individual machines would reduce hardware requirements of validating nodes. 14 | We introduce a hash based accumulator to locally represent the UTXO set, which is logarithmic in the size of the full set. 15 | Nodes attach and propagate inclusion proofs to the inputs of transactions, which along with the accumulator state, give all the information needed to validate a transaction. 16 | While the size of the inclusion proofs results in an increase in network traffic, these proofs can be discarded after verification, and aggregation methods can reduce their size to a manageable level of overhead. 17 | In our simulations of downloading Bitcoin’s blockchain up to early 2019 with 500MB of RAM allocated for caching, the proofs only add approximately 25% to the amount otherwise downloaded. 18 | 19 | ## 摘要 20 | 在比特币共识网络中， 21 | 所有节点都会就未花费交易输出集（“UTXO”集）达成协议 22 | 【译注：即每个节点都会在自己本地存储一份一模一样的UTXO集】。 23 | 此共享状态【译注：即UTXO集】的大小限制了网络的可伸缩性， 24 | 因为集合的大小会随着更多用户加入系统而扩展，从而增加了所有节点的资源需求。 25 | 将网络的状态大小与单个计算机的存储需求相解耦可以减少验证节点的硬件需求。 26 | 我们引入了一个基于哈希的累加器， 27 | 使得节点可以在本地存下能代表UTXO集的数据， 28 | 但所占用的存储空间大小相对于整个UTXO集的大小只是对数关系。 29 | 服务器节点在传输交易输入时需要带上交易的包含证明， 30 | 并与累加器状态一起提供验证交易所需的所有信息。 31 | 虽然包含证明的大小会导致网络流量增加， 32 | 但是我们可以在验证之后将这些证明丢弃， 33 | 并且可以通过聚合的方法将其大小减小到可管理的开销水平。 34 | 在我们的模拟测试中， 35 | 我们会下载比特币诞生一直到2019年初的比特币区块链， 36 | 并分配500MB的RAM用于缓存， 37 | 测试结果表明，交易的包含证明仅增加了大约25％的下载量。 38 | -------------------------------------------------------------------------------- /Papers/Utreexo/1-Introduction.md: -------------------------------------------------------------------------------- 1 | > Source: https://eprint.iacr.org/2019/611.pdf 2 | # 1 Introduction 3 | # 1 介绍 4 | 5 | As cryptographic currencies such as Bitcoin [1] have seen increased adoption, scalability limitations persist as one of the major drawbacks of the technology. 6 | While Bitcoin’s original author was optimistic that the network would scale well, later research has both tempered that optimism as well as presented novel solutions to reduce the resource requirements for operating the network. 7 | 8 | 虽然加密货币（例如比特币[1]）逐渐得到普及， 9 | 但可伸缩性限制一直是该技术的主要缺点之一。 10 | 比特币的原作者对网络的扩展性持乐观态度， 11 | 不过后来的研究一方面给这种乐观态度浇了冷水， 12 | 另一方面也提出了新颖的解决方案来减少网络运营所需的资源。 13 | 14 | Every node in the network verifies and stores the entire state of the system. 15 | Each user of the system has a wallet, which tracks at least one UTXO, but generally several. 16 | As the number of users of the system increases, the UTXO set grows, and the resource cost of running a node increases. 17 | This has led to a progressively smaller proportion of users running their own node as more users rely on light clients or on 3rd party nodes to inform them of the state of the network. 18 | Light clients, nodes that do not store the system state and do not validate transactions, can still obtain some assurance about transactions through Simplified Payment Verification (SPV), which leverages Bitcoin’s Proof-of-Work and block commitment scheme to give compact proofs of transaction inclusion into a (not necessarily valid) blockchain. 19 | 20 | 网络中的每个节点都需要验证并存储整个系统状态。 21 | 系统里的的每个用户都有一个钱包， 22 | 该钱包可以跟踪至少一个UTXO，但通常要跟踪多个。 23 | 随着系统用户数量的增加，UTXO集会变大，并且运行节点的资源成本也会增加。 24 | 随着越来越多的用户依赖轻型客户端或第三方节点来同步他们的网络状态， 25 | 自己运行服务器节点的用户比例也在逐渐减少。 26 | 轻客户端，即不存储系统状态并且不验证交易的节点， 27 | 仍然可以通过简化支付验证（SPV）获得一些交易保证， 28 | SPV利用比特币的工作量证明和区块提交机制来提供紧凑的交易证明， 29 | 证明交易确实被包含在某条（不一定有效的）区块链中。 30 | 31 | SPV, while reducing the resource costs of operating a network node, comes with a number of security and privacy weaknesses not present in full nodes. 32 | SPV nodes rely on fully validating nodes to enforce the rules of the system as they cannot do so themselves. 33 | An adversary with sufficient hashing power can present transactions which SPV nodes will accept as confirmed, but which will be rejected by fully validating nodes. 34 | While improving the security and privacy of SPV is a promising area of research, this work focuses only on fully validating nodes, and on reducing the resource requirements to run one. 35 | 36 | SPV在降低网络节点的运营资源成本的同时， 37 | 也带来了一些在全节点中不存在的安全性和隐私弱点。 38 | SPV节点依靠全节点来执行系统规则，因为它们自己做不了。 39 | 这样具有足够的算力的攻击者就可以提出自己构造的恶意交易， 40 | SPV节点会确认接受这些交易，但全节点却会拒绝这些交易。 41 | 虽然提高SPV的安全性和隐私性是一个有潜力的研究领域， 42 | 但本文的工作仅关注全节点，以及如何降低一个全节点所需的资源。 43 | 44 | In this paper we present Utreexo, a method for greatly reducing the storage needed to run a fully validating node. 45 | In hardware setups where disk I/O speeds and storage requirements are the bottleneck, this can significantly accelerate the validation process, or make validation possible on hardware where it previously has not been. 46 | 47 | 在本文中，我们介绍了Utreexo， 48 | 这是一种极大减少全节点所需的存储空间的方法。 49 | 在磁盘I/O速度和存储要求成为瓶颈的硬件配置中， 50 | 这可以显著加快验证过程， 51 | 或者使以前因为硬件限制而不可行的验证变为可能。 52 | 53 | Utreexo uses a hash-based cryptographic accumulator and introduces a new type of node, the “Compact State Node”, which stores only an accumulator representation of the state. 54 | These nodes require additional inclusion proofs before they are able to verify transactions, and while the CPU time cost of this verification is small, the network bandwidth of these proofs is a trade-off made to achieve the lower state size. 55 | We explore several techniques to limit the size of these proofs. 56 | We observe that the spending patterns of outputs in Bitcoin follow a Pareto distribution where many outputs are short-lived. 57 | We can exploit this locality to keep outputs that are likely to be removed clustered together and use shorter, overlapping proofs when proving their inclusion. 58 | In addition, we are able to cache recent additions, and even anticipate deletions before they occur when catching up to the current network state. 59 | While the proofs add on the order of O(n log n) space overhead to synchronization, in practice with the empirical blockchain data and reasonable caching, about 25% more data needs to be downloaded. 60 | 61 | Utreexo使用基于哈希的密码学累加器， 62 | 并引入了一种名为“紧凑状态节点”的新型节点， 63 | 该节点用累加器表示整个系统的状态， 64 | 并仅将累加器保存在存储中。 65 | 这些节点在能够验证交易之前需要额外的包含证明， 66 | 这些验证的CPU时间开销很小， 67 | 不过会占用网络带宽， 68 | 但这也是为了减小系统状态大小而必须付出的成本。 69 | 我们会探索几种技术来限制这些证明的大小。 70 | 我们发现比特币产出的花费模式遵循Pareto分布， 71 | 其中许多输出很快就会被花费。【译注：80/20法则】 72 | 我们可以利用这种局部性将有可能被成片删除掉的UTXO（即生存时间短的UTXO）聚集在一起， 73 | 并在提供它们的包含证明时使用较短的可复用的证明。 74 | 【译注：重叠是指这个证明可以复用, 可以同时证明多笔交易，详见第5节。】 75 | 此外，我们可以缓存最近添加的内容， 76 | 甚至可以在同步当前网络状态前预测会被删除的内容。 77 | 虽然证明增加了O(n log n)数量级的空间开销来进行同步， 78 | 但实际上如果能利用区块链的先验数据并合理地分配缓存， 79 | 那么下载流量大约只会增加25％。 80 | 81 | # References 82 | 83 | [1] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 84 | 85 | http://bitcoin.org/bitcoin.pdf, 2008. 86 | -------------------------------------------------------------------------------- /Papers/Utreexo/2-Related Work.md: -------------------------------------------------------------------------------- 1 | > Source: https://eprint.iacr.org/2019/611.pdf 2 | # 2 Related Work 3 | # 2 相关工作 4 | 5 | The limitations of having every client store the UTXO set have been clear since Bitcoin was first introduced; in fact this was the first comment ever recorded about Bitcoin [2]. 6 | Earlier work has focused on UTXO commitments [3], where some representation of the UTXO set would be included in the blockchain itself. 7 | With a consensus rule enforcing the validity of this UTXO commitment, users could get some assurance, similar to SPV security, about the representation of the UTXO set without downloading or validating it themselves. 8 | In contrast to UTXO commitments, Utreexo state is not transmitted to clients, but instead computed by them. 9 | 10 | 自从首次引入比特币以来，让每个客户端都存储UTXO集的局限性就很明显了。实际上，这是有史以来关于比特币的第一个评论[2]。 11 | 早期的工作专注在UTXO提交[3]上，其中UTXO集以某种表示形式被包含在区块链本身中。 12 | 通过一种强制保证此UTXO提交有效性的共识规则，用户可以像SPV安全性一样，获得有关UTXO集表示形式的某种保证，而无需自己下载或验证UTXO集。 13 | 与UTXO提交相反，Utreexo状态不是传输给客户端的，而是由客户端自己计算得出的。 14 | 15 | Techniques for speeding up or skipping parts of Initial Block Download have been proposed, the most promising of which is Mimblewimble [4]. 16 | While Mimblewimble maintains the same cryptographic security as downloading and verifying the transaction history, it is a substantial change in transaction format and is difficult to implement in a backwards-compatible way to the existing Bitcoin network. 17 | Systems which do implement Mimblewimble benefit from a decrease in data needed to perform initial synchronization, but once synchronized still maintain a full UTXO set. 18 | It’s possible that Utreexo and Mimblewimble techniques could be implemented simultaneously, which would allow for both reduced state size and efficient initial synchronization. 19 | 20 | 已经有人提出了加快或部分跳过“初始区块下载”的技术 21 | 【译注：*初始区块下载*又叫初始同步。英文原文是Initial Block Download（IBD）， 22 | 是指一个全节点初次上线，在其有能力校验一个未确认的交易和最近新挖到的区块前， 23 | 必须下载并校验从创世区块起的整个交易历史记录的初始化过程】， 24 | 其中最具代表性的是Mimblewimble[4]。 25 | 尽管Mimblewimble在没有下载和验证整个交易历史记录的情况下依然可以保持同等的密码学安全性， 26 | 但其交易格式产生了重大变化，并且难以以向后兼容的方式应用到现有的比特币网络中。 27 | 那些确实实现了Mimblewimble的系统虽然在初始同步时所需的数据量有所减少， 28 | 但是一旦同步完成，节点仍然会维护着一份完整的UTXO集。 29 | 其实Utreexo和Mimblewimble技术可以同时实施，这既可以减小状态大小，又可以进行高效的初始同步。 30 | 31 | Other recent work on accumulators for blockchain state has introduced constant-size accumulators using groups of unknown order [5]. 32 | While this construction has superior properties in terms of proof size and batching, it depends on either a trusted setup or novel cryptographic primitives. 33 | Another difficulty with accumulators using groups of unknown order is that while transmission of proofs can be batched and thus made very small, updating and maintaining many proofs (such as all of them) may be infeasible, due to proof updates not batching as is possible with Utreexo’s hash based accumulator. 34 | 35 | 还有一些有关区块链状态累加器的最新研究成果引入了使用未知顺序组的恒定大小累加器[5]。 36 | 这种构想在证明大小和批处理方面具有更好的特性，但它需要依赖可信设置或更新的密码学原语。 37 | 【译注：*可信设置（trusted setup）*又称为“可信启动”， 38 | 在密码学中是指创建一个密码学系统时生成其初始参数所需的配置。 39 | 生成的初始参数在稍后会被销毁。 40 | 之所以叫“可信设置”是因为你必须相信配置的作者一定会销毁那些参数。 41 | 具体可参见：[《What is trusted setup?》](https://zcoin.io/ufaqs/what-is-trusted-setup/)。 42 | 可信设置常用在零知识证明中。 43 | *密码学原语*可以简单理解为：你想做什么事情？ 44 | 比如“加密”、“签名”是个原语，“密钥交换”、“零知识证明”也是个原语。】 45 | 使用未知顺序组的累加器所带来的另一个困难是， 46 | 虽然可以批量发送证明从而使发送量变得很小， 47 | 但由于无法像Utreexo的基于哈希的累加器那样批量地更新证明， 48 | 因此当证明量很大时，更新和维护（例如要更新所有证明）就可能变得不可行。 49 | 50 | # References 51 | 52 | [1] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 53 | 54 | http://bitcoin.org/bitcoin.pdf, 2008. 55 | 56 | [2] James A. Donald. Re: Bitcoin p2p e-cash paper. http: //www.metzdowd.com/pipermail/cryptography/2008-November/ 014814.html, 2008. 57 | 58 | [3] Peter Todd. Making utxo set growth irrelevant with lowlatency delayed txo commitments. https://petertodd.org/2016/ delayed-txo-commitments, 2016. Accessed: 2019-05-10. 59 | 60 | [4] Tom Elvis Jedusor. Mimblewimble. http://diyhpl.us/ ~ bryan/ papers2/bitcoin/mimblewimble.txt, 2016. Accessed: 2019-05-22. 61 | 62 | [5] Dan Boneh, Benedikt Bnz, and Ben Fisch. Batching techniques for accumulators with applications to iops and stateless blockchains. Cryptology ePrint Archive, Report 2018/1188, 2018. https://eprint.iacr. org/2018/1188. 63 | -------------------------------------------------------------------------------- /Papers/Utreexo/3-Application to Bitcoin.md: -------------------------------------------------------------------------------- 1 | > Source: https://eprint.iacr.org/2019/611.pdf 2 | # 3 Application to Bitcoin 3 | # 3 在比特币上的应用 4 | 5 | In contrast to account based systems where user balances can be incremented and decremented, the Bitcoin protocol keeps track of Unspent Transaction Outputs (referred to as UTXOs). 6 | A transaction in Bitcoin has inputs and outputs (TXOs), the inputs referring to, and consuming, previously created outputs. 7 | In this design, the only operations on the data set are create, read, and delete. 8 | There is no modification other than deletion possible of a set element after it is written. 9 | 10 | 与可以增加和减少用户余额的基于帐户的系统不同，比特币协议会跟踪未花费的交易输出（称为UTXO）。 11 | 比特币中的交易具有输入和输出（TXO），这些输入引用并使用先前创建的输出。 12 | 这种设计对数据集只能执行创建，读取和删除操作。 13 | 系统无法修改一个已经写入集合的元素，只能删除。 14 | 15 | Cryptographic accumulators, first introduced in [6], allow for set query operations without storing or revealing all members of the set. 16 | Bitcoin’s UTXO set is well-suited to an accumulator construction; for each transaction we would like to query whether the TXOs being spent are indeed members of the UTXO set, and if not, reject the transaction. 17 | 18 | 最早在[6]中引入的密码学累加器允许执行集合查询操作，而无需存储或显示集合的所有成员。 19 | 比特币的UTXO集非常适合用来构造累加器；对于每笔交易，我们希望能查询被花费的TXO是否确实为UTXO集的成员，如果不是，则拒绝该交易。 20 | 21 | In Bitcoin, clients verify all state changes. 22 | This significantly limits scalability of the system, as raising the resource requirements to participate reduces the number of participants in the system, in many cases forcing them to rely on SPV or custodial wallets. 23 | As of early 2019, the initial synchronization process, called “Initial Block Download” (IBD), requires users to download over 200 gigabytes of historic data and to verify hundreds of millions of digital signatures. 24 | The end state of the system is much smaller than the historic transcript – the UTXO set is closer to 4 gigabytes. 25 | 26 | 在比特币中，只要状态发生了变化，客户端就要进行验证。 27 | 这很大程度上限制了系统的可伸缩性， 28 | 因为这对系统参与者的资源【译注：比如存储容量、网速等】提出了更高的要求， 29 | 从而减少了系统参与者的数量。很多时候他们只能依赖SPV或托管钱包。 30 | 截至2019年初，称为“初始区块下载”（IBD）的初始同步过程要求用户下载超过200 GB的历史数据，并验证数亿个数字签名。 31 | 【译注：初始区块下载又叫初始同步。 32 | 英文原文是Initial Block Download（IBD）， 33 | 是指一个全节点初次上线，在其有能力校验一个未确认的交易和最近新挖到的区块前， 34 | 必须下载并校验从创世区块起的整个交易历史记录的初始化过程】 35 | 但其实系统的最终状态比历史记录要小得多——UTXO集只有约4GB。 36 | 37 | Long initial synchronization times and large data storage requirements present a burden to users and limit the reach and scalability of the system. 38 | IBD times vary widely depending on hardware, and there are several different constraints which can be the limiting factor for IBD speed. 39 | Disk I/O, especially the ability to rapidly perform random access reads, is very important for fast IBD. 40 | In machines with solid state drives, disk I/O is not usually the limiting factor, and the CPU will be kept busy with signature verification. 41 | In machines using mechanical hard drives however, disk I/O is usually the limiting factor, and the CPU will spend most of its time waiting for disk reads to complete. 42 | IBD times for a machine with an SSD can be around 6 hours, while the same machine using a mechanical hard drive can take more than a week.1 43 | 44 | 1Recently tested with Bitcoin Core 0.17.1 on a AMD Ryzen 1700 Machine using a Samsung 960 EVO 500GB SSD, in comparison with the same machine where the bitcoin folder was instead stored on a Samsung HD154UI 1.5TB mechanical drive. 45 | 46 | 较长的初始同步时间和大量的数据存储要求会给用户带来负担，并限制系统的覆盖范围和可伸缩性。 47 | IBD时间因硬件而异，其速度受多个因素限制。 48 | 其中磁盘I/O，特别是快速执行随机访问读取的能力，对于快速IBD至关重要。 49 | 在带有固态驱动器的机器中，磁盘I/O通常不是限制因素，CPU将忙于签名验证。 50 | 但是，在使用机械硬盘的机器中，磁盘I/O通常就是限制因素，CPU将花费大部分时间等待磁盘读取完成。 51 | 具有SSD的计算机的IBD时间可能约为6个小时，而使用机械硬盘的同一台计算机则可能需要一周以上的时间。1 52 | 53 | 1这个测试是最近在使用三星960 EVO 500GB SSD的AMD Ryzen 1700机器上使用Bitcoin Core 0.17.1进行的， 54 | 比较对象是将比特币文件夹存储在三星HD154UI 1.5TB机械硬盘上的同一台机器。 55 | 56 | Current Bitcoin client implementations store the UTXO set in an ondisk database, so that nodes can verify the existence and details of every UTXO when performing the read and delete operations at the end of the UTXO’s life in the database. 57 | From the creation of a UTXO to just before it is spent, a duration that is often several years, the UTXO has no effect on the system, and its database entry is never accessed. 58 | A transaction in Bitcoin cannot query the state or existence of other UTXOs, and UTXOs are only read from disk when they are being spent. 59 | 60 | 当前比特币客户端的实现方式是将UTXO集存储在磁盘数据库中，使得节点在UTXO生命周期结束，执行读取和删除操作时，可以验证每个UTXO的存在状态和详细信息。 61 | UTXO从其被创建到被花费的期间（往往为数年）内都不会对系统产生影响，并且其数据库条目永远不会被访问。 62 | 比特币中的交易无法查询交易外的其它UTXO的状态，也无法得知它们是否存在。 63 | UTXO只有在被花费时才会从磁盘中被读取出来。 64 | 65 | A design in which clients do not need to store UTXOs during this dormant period offers many benefits. 66 | Currently the system’s state can be stored on inexpensive hardware, but as there is is no limit on the state’s size, this may not continue to be the case. 67 | (Bitcoin’s block size limit does limit the growth rate of the UTXO set to approximately 1MB every 10 minutes, but does not impose an absolute limit on the set size). 68 | Omitting dormant UTXOs not only helps long term scalability, but also increases synchronization speed as disk reads and writes are minimized. 69 | Full validation is possible using only data arriving over the network and a small in-memory state representation. 70 | Additionally, this type of client allows for better code separation as evaluating the validity of a transaction or block can be done in isolation, since all data needed to validate a transaction is comparable in size to the transaction itself, rather than the size of the entire UTXO database as is currently the case. 71 | 72 | 如果客户端在UTXO的休眠期中无需存储UTXO，那将带来很多好处。 73 | 按当前的设计，虽然我们可以将系统状态存储在便宜的硬件上，但是由于状态大小没有限制，因此这样的设计不可持续。 74 | （虽然比特币的块大小限制确实将UTXO的增长率控制在了每10分钟1MB，但却并没有限制整个UTXO集合的大小）。 75 | 删掉休眠的UTXO不仅有助于长期扩容，而且还可以最大程度地减少磁盘读写，从而提高同步速度。 76 | 相应地，我们可以仅通过网络数据和较小的内存状态来做完全验证。 77 | 此外，在这类客户端上，交易或区块的有效性验证工作可以彼此隔离，从而实现更好的代码分离， 78 | 因为验证交易所需的所有数据的大小可以缩小到与交易本身相当， 79 | 而不是跟现在一样，验证一笔交易要用到的数据就跟整个UTXO数据库一样大。 80 | 81 | # Reference 82 | [6] Josh Benaloh and Michael de Mare. One-way accumulators: A decentralized alternative to digital sinatures (extended abstract). In EUROCRYPT, 1993. 83 | -------------------------------------------------------------------------------- /Papers/Utreexo/6-Conclusion.md: -------------------------------------------------------------------------------- 1 | > Source: https://eprint.iacr.org/2019/611.pdf 2 | 3 | # 6 Conclusion 4 | 5 | # 6 结论 6 | 7 | We have introduced a hash-based dynamic accumulator and architecture for using this accumulator in the Bitcoin network. 8 | Nodes using the accumulator need only store a logarithmically sized representation of the UTXO set, greatly reducing storage space and disk seek times. 9 | The trade-off is the additional download requirements of inclusion proofs, but with proof aggregation and caching the increase is of a manageable size. 10 | 11 | # Acknowledgments 12 | 13 | 我们介绍了基于哈希的动态累加器和体系结构， 14 | 目的是将该累加器应用于比特币网络。 15 | 使用累加器的服务器节点存储UTXO集所用的内存空间可以缩小至对数级别， 16 | 从而大大减少了存储空间和磁盘查找时间。 17 | 相应的代价是需要从网络额外下载包含证明， 18 | 但是通过证明的聚合和缓存， 19 | 我们可以将增加的下载流量保持在可控范围。 20 | 21 | # 致谢 22 | 23 | Thanks to Neha Narula and Cory Fields for discussion without which this paper would not have happened. 24 | Thanks to Pieter Wuille for discussions about the applicability of other accumulator designs and the difficulties of bridge nodes (as well as coining the term). 25 | Thanks to Sophia Yakoubov for discussing her work which can be extended and applied here. 26 | Thanks to Kalle Alm for discussion about caching strategies, Dan Cline for suggesting optimal caching strategies, and Peter Malamud Smith for comments and feedback. 27 | 28 | 感谢Neha Narula和Cory Fields的讨论， 29 | 否则这篇文章就写不出来。 30 | 感谢Pieter Wuille讨论了其他累加器设计的适用性和桥节点的难点（以及创造了该术语）。 31 | 感谢Sophia Yakoubov分享了她的成果， 32 | 使我们可以在本文扩展和应用她的成果。 33 | 感谢Kalle Alm关于缓存策略的讨论， 34 | 感谢Dan Cline提出最佳缓存策略的建议， 35 | 以及Peter Malamud Smith的评论和反馈。 36 | 37 | # References 38 | [1] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 39 | 40 | http://bitcoin.org/bitcoin.pdf, 2008. 41 | 42 | [2] James A. Donald. Re: Bitcoin p2p e-cash paper. http: //www.metzdowd.com/pipermail/cryptography/2008-November/ 014814.html, 2008. 43 | 44 | [3] Peter Todd. Making utxo set growth irrelevant with lowlatency delayed txo commitments. https://petertodd.org/2016/ delayed-txo-commitments, 2016. Accessed: 2019-05-10. 45 | 46 | [4] Tom Elvis Jedusor. Mimblewimble. http://diyhpl.us/ ~ bryan/ papers2/bitcoin/mimblewimble.txt, 2016. Accessed: 2019-05-22. 47 | 48 | [5] Dan Boneh, Benedikt Bnz, and Ben Fisch. Batching techniques for accumulators with applications to iops and stateless blockchains. Cryptology ePrint Archive, Report 2018/1188, 2018. https://eprint.iacr. org/2018/1188. 49 | 50 | 20 [6] Josh Benaloh and Michael de Mare. One-way accumulators: A decentralized alternative to digital sinatures (extended abstract). In EUROCRYPT, 1993. 51 | 52 | [7] Ralph C. Merkle. Protocols for public key cryptosystems. 1980 IEEE Symposium on Security and Privacy, pages 122–122, 1980. 53 | 54 | [8] Leonid Reyzin and Sophia Yakoubov. Efficient asynchronous accumulators for distributed pki. Cryptology ePrint Archive, Report 2015/718, 2015. https://eprint.iacr.org/2015/718. 55 | 56 | [9] Charles Bouillaguet, Pierre-Alain Fouque, Adi Shamir, and Sebastien Zimmer. Second preimage attacks on dithered hash functions. Cryptology ePrint Archive, Report 2007/395, 2007. https://eprint.iacr. org/2007/395. 57 | 58 | [10] Laszlo A. Belady. A study of replacement algorithms for a virtual-storage computer. IBM Systems journal, 5(2):78–101, 1966. 59 | 60 | [11] MIT DCI. Utreexo implementation. https://github.com/mit-dci/ utreexo, 2019. 61 | -------------------------------------------------------------------------------- /Papers/Utreexo/7-Appendix.md: -------------------------------------------------------------------------------- 1 | > Source: https://eprint.iacr.org/2019/611.pdf 2 | # 7 Appendix 3 | 4 | # 7 附录 5 | 6 | ## 7.1 Batch deletion process 7 | 8 | ## 7.1 批量删除过程 9 | 10 | The following is a description of the batch deletion process. While the single element deletion process is sufficient and can be invoked repeatedly, it is inefficient to do so. When many deletions occur simultaneously we can significantly reduce the number of hash operations needed to remove elements from the accumulator by batching the deletions. 11 | 12 | 以下是批量删除过程的说明。 13 | 尽管单个元素的删除过程已经够用， 14 | 并且可以重复调用，但这样做的效率很低。 15 | 当大量的删除操作同时发生时， 16 | 我们可以通过批量删除来显著减少从累加器中删除元素时所需的哈希操作。 17 | 18 | Similar to the DeleteOne() function, the process for deleting many elements operates a row at a time, climbing from the bottom to the top of the forest. At each row, the same phases are followed. The data operated on at each row, includes the known hashes and their positions, as well a list of which locations to delete. The phases are, in order: “Twin”, or twin extraction, “Swap”, or sibling swapping, “Root”, promoting a node to or demoting a node from a root position, and “Climb”, ascending to the next row up. These 4 phases are described with accompanying diagrams. In the following diagrams, green nodes are nodes which are always known, as they are or were tree roots. Pink nodes are nodes which are being deleted. 19 | 20 | 与DeleteOne()函数类似， 21 | 删除多个元素的过程一次操作一行， 22 | 从森林的底部爬升到顶部。 23 | 每一行执行相同的运行阶段。 24 | 在每一行上操作的数据包括已知的哈希及其位置， 25 | 以及要删除的元素的位置列表。 26 | 运行阶段依次为： 27 | “双胞胎”或“双胞胎提取”； 28 | “交换”或同级交换； 29 | “根”，将节点提升到根位置或从根位置降级； 30 | 以及“爬升”，升至下一行。 31 | 这四个阶段将通过附图进行描述。 32 | 在下图中，绿色节点始终是已知的， 33 | 因为它们是或曾经是树根。 34 | 粉色节点是要删除的节点。 35 | 36 | ## 7.2 Twin 37 | 38 | ## 7.2 双胞胎 39 | 40 | While the twin step is optional, we can save time from the next step by immediately dealing with “twin” deletions; we define a twin deletion as a deletion where both the left and right sibling have been deleted. If we have a sorted list of locations to be deleted, a simple way to find these is to check if the next deletion is equal to the current deletion bitwise or’ed with 1. If so, we can remove both “twins” from the deletion list, and add the parent position to the next higher row of deletions to process. 41 | 42 | 尽管双胞胎步骤是可选的， 43 | 但我们可以通过立即处理“双胞胎”删除来节省下一步的时间。 44 | 我们将双胞胎删除定义为左兄弟和右兄弟都要删除的操作。 45 | 如果我们有要删除的位置的顺序列表， 46 | 那么找到双胞胎删除的简便方法是检查下一个删除的位置是否等于当前的删除位置按位或1。 47 | 如果是的话，就可以从删除列表中删除这两对“双胞胎”， 48 | 然后将父职位添加到要处理的下一个较高的删除行中。 49 | 50 | ![5](./Figures/5.jpg) 51 | 52 | > Figure 5: Twin phase; nothing moves, and 4 is marked for deletion. 53 | 54 | > 图5：双胞胎阶段；没有任何元素被移动，节点4被标记为删除。 55 | 56 | ## 7.3 Swap 57 | 58 | ## 7.3 交换 59 | 60 | While there are 2 or more deletion positions left in the list, we iterate through them. Call the two positions deletionA and deletionB. 61 | 62 | 如果列表中还有2个或更多的元素位置待删除， 63 | 我们会对其进行遍历。 64 | 称这两个位置为deletionA和deletionB。 65 | 66 | Move the hash at deletionB ⊕ 1 to deletionA. When moving a node, all the node’s children move with it. The parent of deletionB is added to the deletion list for the next row, and both deletionA and deletionB are removed from the current list. Note that in all cases we know the hash at deletionB⊕1, as it is the sibling of something being deleted (or the sibling of a parent of something being deleted) and thus is given to us in the inclusion proof. 67 | 68 | 将deletionB ⊕ 1位置的哈希移动到deletionA。 69 | 移动节点时，该节点的所有子节点都随之移动。 70 | deletionB的父亲将被添加到下一行的删除列表中， 71 | 并且deletionA和deletionB都将从当前列表中被删除。 72 | 请注意，无论何时我们都知道在deletionB⊕1处的哈希， 73 | 因为它是某项被删除元素的兄弟（或某项被删除的父亲的兄弟）， 74 | 因此包含证明会含有它们。 75 | 76 | ![6](./Figures/6.jpg) 77 | 78 | > Figure 6: Swap phase; deletionA is 1, deletionB is 2. 3 moves to 1, and 5 is marked for deletion. 79 | 80 | > 图6：交换阶段；deletionA是1，deletionB是2。3被移动到1，5被标记为删除。 81 | 82 | ## 7.4 Root 83 | 84 | ## 7.4 根 85 | 86 | If there are an even number of deletions on a row, the twin and swap phases will finish with no unpaired deletions, and the root phase is skipped. In cases where there are an odd number of deletions, however, the swap phase will finish with a single deletion remaining in the list. This final deletion is handled by the root phase. 87 | 88 | 如果一行里被删除的元素数目为偶数， 89 | 则双胞胎和交换阶段结束后， 90 | 不会留下还未配对的待删除元素，根阶段会被跳过。 91 | 但是，在删除数量为奇数的情况下， 92 | 交换阶段结束后，列表中还会剩下一个待删除元素。 93 | 最后一个删除操作由根阶段执行。 94 | 95 | For every row in the forest, there either is or is not a tree with a root at that height. For example, in the forest of 133 leaves, there is a root at height 0, but there is no root at height 1. There is a root at height 2, and no roots for several rows above that. 96 | 97 | 对于森林中的每一行， 98 | 在该行所在高度都有一个或零个树根。 99 | 例如，在有133个叶子的森林中， 100 | 在高度0处有一个根，但在高度1处没有根。 101 | 在高度2处有一个根，在此之上的几行都没有根。 102 | 103 | If we are on a row where a root is present, we move that root into the position of the remaining deletion, clear the deletion and are then finished with that row, adding no deletions for the next row. If a root is absent, we move the sibling of the deletion (position ⊕ 1) to the root position for this height, creating a new tree in the forest, and leaving a twin pair of deletions. We then mark the parent of the final deletion for deletion in the next row. 104 | 105 | 如果我们当前所处的行高度上出现了一个根， 106 | 则将该根移动到剩余被标记为删除的位置， 107 | 覆盖被标记为删除的元素，然后结束该行， 108 | 不给下一行添加任何删除标记。 109 | 如果这一行的高度没有根， 110 | 那就将被标记为删除的位置的兄弟（位置⊕1）移动到该高度的根位置， 111 | 在森林中创建一棵新树，并留下一对双胞胎删除。 112 | 然后，将最后一个删除位置的父亲标记为留到下一行删除。 113 | 114 | ![7](./Figures/7.jpg) 115 | 116 | > Figure 7: Root phase with root present; 4 is demoted from a root to the sibling of 2. 117 | 118 | > 图7：出现了树根的根阶段；4从树根被降级为2的兄弟。 119 | 120 | ![8](./Figures/8.jpg) 121 | 122 | > Figure 8: Root phase with root absent; 2 is promoted to root of the height 1 tree. 123 | 124 | > 图8：没有出现树根的根阶段；2被升级为高度为1的树的根。 125 | 126 | ## 7.5 Climb 127 | 128 | ## 7.5 爬升 129 | 130 | When the root phase has finished, the climb phase transitions between levels of the forest. All deletions will be in pairs of two deleted siblings. The parent nodes of all deleted sibling pairs are marked as deleted, and parents of nodes which moved in the swap or root phase are recomputed. When the deletion and hashing are finished, the per-row phases (starting with twin) begin on the next level up. 131 | 132 | 当根阶段结束时， 133 | 爬升阶段会在森林的各个层之间进行迁移。 134 | 所有的待删除元素将以成对的被删除兄弟出现。 135 | 我们会将所有已删除的双胞胎兄弟的父节点标记为已删除， 136 | 并且为交换或根阶段移动的节点重新生成父节点。 137 | 完成删除和哈希操作后，就上升到下一行， 138 | 从双胞胎阶段重新执行四个阶段。 139 | 140 | When the top of the forest is reached, the deletion process is finished. If a row is reached with no deletions, the process can terminate early. 141 | 142 | 当到达森林的顶部时，删除过程完成。 143 | 如果到达某一行没有出现删除，则该过程可以提前终止。 144 | 145 | ![9](./Figures/9.jpg) 146 | 147 | > Figure 9: Climb phase; Begin a new deletion list from positions marked in the previous other 3 phases and climb to the next row. 148 | 149 | > 图9：爬升阶段； 150 | 从前三个阶段中标记的位置开始构造一个新的删除列表， 151 | 然后爬升到下一行。 152 | 153 | ## 7.6 Integrated batched deletion example 154 | 155 | ## 7.6 一个完整的批量删除例子 156 | 157 | In this example, there are 8 leaves in a single tree. Leaves 5 and 6 are being deleted. An inclusion proof for both 5 and 6 is provided. Note that an inclusion proof for these nodes does not contain any nodes from the 2nd row, as both 10 and 11 are computable from data known in the first row. 158 | 159 | 在这个例子中，一棵树上有8个叶子。 160 | 第5和第6个叶子正被删除。 161 | 我们提供了5和6的包含证明。 162 | 请注意，这些节点的包含证明不包含第二行中的任何节点， 163 | 因为10和11均可从第一行中已知的数据中计算得出。 164 | 165 | 166 | ![10](./Figures/10.jpg) 167 | 168 | > Figure 10: There are no twins, so first 7 is swapped with 5 169 | 170 | > 图10：没有双胞胎，所以首先将7和5交换。 171 | 172 | 173 | ![11](./Figures/11.jpg) 174 | 175 | > Figure 11: The bottom row is finished and 11 is marked for deletion as its children are gone. 10 is computed. 176 | 177 | > 图11：最底下一行已经结束，11被标记为删除，因为它的孩子都没了。10被重新生成。 178 | 179 | ![12](./Figures/12.jpg) 180 | 181 | > Figure 12: On the second row, there are no twins, and we cannot swap, so we proceed directly to root. 182 | 183 | > 图12：第二行没有双胞胎，并且无法做交换，因此直接进入根阶段。 184 | 185 | ![13](./Figures/13.jpg) 186 | 187 | > Figure 13: 10 becomes the root of its own tree, leaving 13 to be deleted as well. 188 | 189 | > 图13：10变成它自己的树的根，留下13待删除。 190 | 191 | ![14](./Figures/14.jpg) 192 | 193 | > Figure 14: 14 is deleted as 12 becomes the root of its tree. 194 | 195 | > 图14：14被删除，因为12变成了它自己的树的根。 196 | 197 | ![15](./Figures/15.jpg) 198 | 199 | > Figure 15: The final forest state after deletion is complete. 200 | 201 | > 图15：删除操作结束后的最终森林状态。 202 | -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/1.jpg -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/10.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/10.jpg -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/11.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/11.jpg -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/12.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/12.jpg -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/13.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/13.jpg -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/14.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/14.jpg -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/15.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/15.jpg -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/2.png -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/3.png -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/4.png -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/5.jpg -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/6.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/6.jpg -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/7.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/7.jpg -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/8.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/8.jpg -------------------------------------------------------------------------------- /Papers/Utreexo/Figures/9.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DAGfans/TranStudy/f041c09467c394aebf59e7c534d8cc725085a0a6/Papers/Utreexo/Figures/9.jpg -------------------------------------------------------------------------------- /Projects/Byteball/2. Database structure.md: -------------------------------------------------------------------------------- 1 | >* **Source：** [https://byteball.org/Byteball.pdf](https://byteball.org/Byteball.pdf) 2 | >* **TranStudy：** [https://github.com/DAGfans/TranStudy/tree/master/Projects/Byteball 3 | ](https://github.com/DAGfans/TranStudy/tree/master/Projects/Byteball) 4 | 5 | # 2. Database structure 6 | # 2. 数据库结构 7 | 8 | When a user wants to add data to the database, he creates a new storage unit and broadcasts it to his peers. 9 | The storage unit includes (among other things): 10 | 11 | * The data to be stored. A unit may include more than one data package called a message. There are many different types of messages, each with its own structure. One of the message types is payment, which is used to send bytes or other assets to peers. 12 | 13 | * Signature(s) of one or more users who created the unit. Users are identified by their addresses. Individual users may (and are encouraged to) have multiple addresses, like in Bitcoin. In the simplest case, the address is derived from a public key, again similar to Bitcoin. 14 | 15 | * References to one or more previous units (parents) identified by their hashes. 16 | 17 | 当用户想要将数据添加到数据库时，他创建一个新的存储单元并将其广播给他的对等节点。 18 | 存储单元包括（除其他外）： 19 | 20 | * 要存储的数据。 一个单元可能包含多个称为消息的数据包。 有很多不同类型的消息，每个消息都有自己的结构。 消息类型之一是支付，用于向对等节点发送字节或其他资产。 21 | 22 | * 创建单元的一个或多个用户的签名。 用户通过他们的地址标识身份。 个人用户可能（并且被鼓励）拥有多个地址，比如比特币。 在最简单的情况下，地址来源于公钥，与比特币类似。 23 | 24 | * 引用一个或多个以前的单元（上级）的散列。 25 | 26 | 27 | 28 | References to parents is what establishes the order (only partial order so far) of units and generalizes the blockchain structure. 29 | Since we are not confined to one-parent–one-child relationships between consecutive blocks, we do not have to strive for near-synchrony and can safely tolerate large latencies and high throughputs: we’ll just have more parents per unit and more children per unit. 30 | If we go forward in history along parent-child links, we’ll observe many forks when the same unit is referenced by multiple later units, and many merges when the same unit references multiple earlier units (developers are already used to seeing this in git). 31 | This structure is known in graph theory as directed acyclic graph (DAG). 32 | Units are vertices, and parent-child links are the edges of the graph. 33 | 34 | 对上级单元的引用用于确定单元的顺序（至今只有偏序），并泛化区块链结构。 (译注: 泛化这里指区块链结构是一种只有单个父子单元的特殊DAG) 35 | 由于我们不限定连续块之间遵守单亲-单子关系，因此我们不必争取近似同步，并且可以安全地忍受较大的延迟和高吞吐量：我们可以在每个单元内拥有更多的父单元和子单元。 (译注: 这里的近似同步相对于严格同步, 以比特币为例, 平均出块时间虽然远大于平均传播时间, 但是理论上后者是可以大于前者的, 造成不同步) 36 | 如果我们沿父子链接往前走，我们会观察到当单元被多个后续单元引用时会产生分叉, 当引用多个前置单元时会产生合并 ( 开发者可能已经在git中经常看到这种情况 )。 37 | 这种结构在图论中称为有向无环图（DAG）。 38 | 单元是顶点，父子链接是图的边。 39 | 40 | ![Figure 1. Storage units connected into a DAG. Arrows are from child to parent, G is the genesis unit.](https://user-images.githubusercontent.com/22833166/39611663-fd2cb7d6-4f8b-11e8-99e6-983dec901ae3.png) 41 | 42 | Figure 1. Storage units connected into a DAG. Arrows are from child to parent, G is the genesis unit. 43 | 图 1. 连接到DAG的存储单元。 箭头从子单元指向父单元，G是创世单元。 44 | 45 | 46 | In the special case when new units arrive rarely, the DAG will look almost like a chain, with only occasional forks and quick merges. 47 | 48 | 在新单元很少到达的特殊情况下，DAG将看起来几乎像一条链，只有偶尔的分叉和快速合并。 49 | 50 | Like in blockchains where each new block confirms all previous blocks (and transactions therein), every new child unit in the DAG confirms its parents, all parents of parents, parents of parents of parents, etc. 51 | If one tries to edit a unit, he will also have to change its hash. 52 | Inevitably, this would break all child units who reference this unit by its hash as both signatures and hashes of children depend on parent hashes. 53 | Therefore, it is impossible to revise a unit without cooperating with all its children or stealing their private keys. The children, in turn, cannot revise their units without cooperating with their children (grandchildren of the original unit), and so on. 54 | Once a unit is broadcast into the network, and other users start building their units on top of it (referencing it as parent), the number of secondary revisions required to edit this unit hence grows like a snowball. 55 | That’s why we call this design Byteball (our snowflakes are bytes of data). 56 | 57 | 就像在每个新块确认所有先前块（以及其中的交易）的区块链中一样，DAG中的每个新的子单元都确认其父单元，父单元的所有父单元，父单元的父单元的父单元等。 58 | 如果试图编辑单元， 也将不得不改变它的散列。 59 | 不可避免的是，这将破坏所有通过散列引用本单元的子单元，因为子单元的签名和散列都依赖于父散列。 60 | 因此，如果不与所有的子单元合作或窃取它们的私钥，就不可能修改一个单位。 61 | 反过来，子单元如果不与其子单元（原单元的孙单元）合作，就不能修改它们的单元，以此类推。 62 | 一旦一个单元被广播到网络中，并且其他用户开始在它之上建立他们的单元（引用它作为父单元），编辑这个单元所需的连带修改的数量就会像雪球一样增长。 63 | 这就是为什么我们将这种设计称为Byteball（我们的雪花是数据的字节）的原因。 64 | 65 | Unlike blockchains where issuing a block is a rare event and only a privileged caste of users is in practice engaged in this activity, in a new Byteball unit starts accumulating confirmations immediately after it is released and confirmations can come from anyone, every time another new unit is issued. 66 | There is no two-tier system of ordinary users and miners. 67 | Instead, users help each other: by adding a new unit its author also confirms all previous units. 68 | 69 | 与区块链不同，区块链发布区块是非常罕见的事件，只有特权级别的用户实际参与此活动，而新的Byteball单元在发布后立即开始累积确认信息，确认信息可以来自任何人，只要他们有新的单元发布。 70 | 没有普通用户和矿工的双层体系。 71 | 相反，用户互相帮助：通过添加一个新单元，它的作者也确认了以前的所有单元。 72 | 73 | Unlike Bitcoin, where an attempt to revise a past transaction requires a large computational effort, an attempt to revise a past record in Byteball requires coordination with a large and growing number of other users, most of whom are anonymous strangers. 74 | The immutability of past records is therefore based on the sheer complexity of coordinating with such a large number of strangers, who are difficult to reach, have no interest in cooperation, and where every single one of them can veto the revision. 75 | 76 | 与比特币尝试修改过去交易需要大量计算量不同，尝试修改Byteball中的过去记录需要与大量且不断增加的其他用户进行联合，其中大部分用户都是匿名的陌生人。 77 | 因此，过去记录的不可变性基于与大量陌生人进行联合的高度复杂性，这些陌生人难以联系，对联合没有兴趣，并且每个人都可以否决这次修改。(译注: 这里的说法也不完全对, 理论上如果有足够的算力和资源其实也是可以发动女巫攻击的, 所以雪球会有见证人这样的共识机制) 78 | 79 | By referencing its parents, a unit includes the parent. 80 | It doesn’t include the full content of the parent; rather, it depends on its information through the parent’s hash. 81 | In the same way, the unit indirectly depends on and therefore includes the parents of the parent, their parents, and so on, and every unit ultimately includes the genesis unit. 82 | 83 | 一个单元通过引用其父单元来包含它们。 84 | 它不包含父单元的全部内容; 相反，它依赖于父单元的散列信息。 85 | 同样，单元间接依赖并因此包括父单元的父单元等，以及更上一级的父单元, 以此类推, 最终每个单元会包含创世单位。 86 | 87 | There is a protocol rule that a unit cannot reference redundant parents – that is such parents that one parent includes another. 88 | For example, if unit B references unit A, then unit C cannot reference both units A and B at the same time. 89 | A is already, in a way, contained within B. 90 | This rule removes unnecessary links that don’t add any new useful connectivity to the graph. 91 | 92 | 有一个协议规则要求，一个单元不能引用冗余的父单元 - 就是指其中一个父单元包含另一个父单元。 93 | 例如，如果单元B引用单元A，则单元C不能同时引用单元A和B. 94 | 因为A已经以某种方式包含在B中。 95 | 该规则移除了冗余的链接，因为它们不会为图添加任何新的有用连接性。 96 | -------------------------------------------------------------------------------- /Projects/Byteball/3. Native currency - bytes.md: -------------------------------------------------------------------------------- 1 | >* **Source：** [https://byteball.org/Byteball.pdf](https://byteball.org/Byteball.pdf) 2 | >* **TranStudy：** [https://github.com/DAGfans/TranStudy/tree/master/Projects/Byteball 3 | ](https://github.com/DAGfans/TranStudy/tree/master/Projects/Byteball) 4 | 5 | # 3. Native currency: bytes 6 | # 3. 原生货币：字节(bytes) 7 | 8 | Next, we need to introduce some friction to protect against spamming the database with useless messages. 9 | The barrier to entry should roughly reflect the utility of storage for the user and the cost of storage for the network. 10 | The simplest measure for both of these is the size of the storage unit. 11 | Thus, to store your data in the global decentralized database you have to pay a fee in internal currency called bytes, and the amount you pay is equal to the size of data you are going to store (including all headers, signatures, etc). 12 | Similar to pound sterling, which was equal to one pound of silver when it was first introduced, the name of the currency reflects its value. 13 | 14 | 接下来，我们需要引入一些门槛来防止滥发无用的消息到数据库。 15 | 进入门槛大致反映了用户存储的效用和网络存储成本。 16 | 最简单的衡量两者的方法就是存储单元的大小。 17 | 因此，要将数据存储在全局的去中心化数据库中，你必须要用被成为字节(bytes)的内部货币支付手续费，并且你支付的金额就是等于你要存储的数据的大小（包括所有头部，签名等）。 18 | 与英镑一样，它在首次引进时相当于一磅白银，货币的名称反映了它的价值。 19 | 20 | To keep the incentives aligned with the interests of the network, there is one exception in size calculation rules. 21 | For the purposes of calculating unit size, it is assumed that the unit has exactly two parents, no matter the real number. 22 | Therefore, the size of two hashes of parent units is always included in the unit size. 23 | This exception ensures that users will not try to include just one parent in an effort to minimize cost. 24 | The cost is the same no matter how many parents are included. 25 | 26 | 为保持激励与网络利益一致，尺寸计算规则中有一个例外。 27 | 在计算单元大小时，假定单元正好有两个父单元，而不管实际情况是几个。 28 | 因此，父单元的两个散列的大小总是包含在单元尺寸中。 29 | 这种例外可以确保用户不会尝试仅包含一个父单元，以尽可能降低成本。 30 | 无论包括多少父单元，成本是相同的。 31 | 32 | To keep the DAG as narrow as possible, we incentivize users to include as many parents as possible (as mentioned before, this does not negatively affect payable size), and as recent parents as possible, by paying part of the unit’s fees to those who are first to include it as a parent. 33 | We’ll define later what exactly is ‘first’. 34 | 35 | 为了使DAG尽可能变窄，(译注: 变窄的是指DAG不要产生过多的分支)我们鼓励用户尽可能多地包含父单元（如前所述，这不会对支付金额的大小产生负面影响），然后通过将单元的手续费支付给最先将其作为父单元包含进来的单元, 鼓励尽可能地包含最近的父单元。 36 | 我们将在后面定义'最先'到底是什么。 37 | 38 | Bytes can be used not only for payment of storage fees (also called commissions), but also can be sent to other users to pay for goods or services or in exchange for other assets. 39 | To send a payment, the user creates a new unit that includes a payment message such as the following (from now on, we use JSON to describe data structures): 40 | 41 | 字节不仅可以用于支付存储费用（也称为手续费），还可以发送给其他用户以支付商品或服务或换取其他资产。 42 | 要发送支付，用户需要创建一个包含如下格式的支付消息的新单元（从现在开始, 我们使用JSON来描述数据结构）： 43 | 44 | ```javascript 45 | { 46 | 47 | inputs: [ { 48 | 49 | unit: "hash of input unit", message_index: 2, // index of message where this utxo was created output_index: 0 // index of output where this utxo was created 50 | 51 | }, … 52 | 53 | ], outputs: [ { 54 | 55 | address: "RECEIVER ADDRESS", amount: 15000 // in bytes 56 | 57 | }, … 58 | 59 | ] 60 | 61 | } 62 | ``` 63 | 64 | 65 | The message contains: 66 | 67 | * An array of outputs: one or more addresses that receive the bytes and the amounts they receive. 68 | 69 | * An array of inputs: one or more references to previous outputs that are used to fund the transfer. These are outputs that were sent to the author address(es) in the past and are not yet spent. 70 | 71 | 该消息包含： 72 | 73 | * 一组输出：一个或多个接收字节的地址以及接收数量。 74 | 75 | * 一组输入：一个或多个之前的输出的引用, 用于提供该转账所需的资金。 这些输出是之前被发送到交易发起人的地址上但是还未被花费的交易。 76 | 77 | The sum of inputs should be equal to the sum of outputs plus commissions (input amounts are read from previous outputs and are not explicitly indicated when spending). 78 | The unit is signed with the author’s private keys. 79 | 80 | 输入总和应等于输出加手续费的总和（输入的金额是从上一个输出的汇总得到的, 所以不需要明确指示）。 81 | 该单元使用交易发起人的私钥签名。(译注: 注意区别两个输出, 一个是当前交易的输出, 一个是当前输入所引用的之前未花费的交易的输出) 82 | 83 | The total number of bytes in circulation is $10^{15}$ , and this number is constant. 84 | All bytes are issued in the genesis unit, then transferred from user to user. 85 | Fees are collected by other users who help to keep the network healthy (more details about that later), so they stay in circulation. 86 | The number $10^{15}$ was selected as the largest round integer that can be represented in JavaScript. 87 | Amounts can only be only integers. 88 | Larger units of the currency are derived by applying standard prefixes: 1 kilobyte (Kb) is 1,000 bytes, 1 megabyte (Mb) is 1 million bytes, etc. 89 | 90 | 流通中的总字节数是$10^{15}$，并且这个数字是恒定的。 91 | 所有字节都在创世单元中发布，然后从用户转移到用户。 92 | 被其他用户收集的费用有助于保持网络的健康（稍后会有更多详细信息），因此它们会保持流通。 93 | 选择数字$10^{15}$ 是因为它是JavaScript可以表示的最大整数。 94 | 数量只能是整数。 95 | 较大的货币单位使用标准的尺寸单位：1千字节（Kb）是1,000字节，1兆字节（Mb）是100万字节等等。 96 | -------------------------------------------------------------------------------- /Projects/Byteball/4. Double-spends.md: -------------------------------------------------------------------------------- 1 | ## 4. Double-Spends 2 | 3 | ## 4.双花 4 | 5 | If a user tries to spend the same output twice, there are two possible situations: 6 | 如果一个用户两次尝试花费相同的输出，有两种可能的解决方案： 7 | 8 | 1. There is partial order between the two units that try to spend the same output, i.e. one of the units (directly or indirectly) includes the other unit, and therefore comes after it. 9 | 两个尝试花费相同输出的单元之间存在偏序，即，其中一个单元（直接或间接地）包括另一个单元，因此被包含的单元会跟在后面尝试花费输出。 10 | In this case, it is obvious that we can safely reject the later unit. 11 | 在这种情况下，显然，我们可以安全地拒绝后面的单元。 12 | 13 | 2. There is no partial order between them. In this case, we accept both. 14 | 它们之间没有偏序。在这种情况下，我们两个单元都接受。 15 | We establish a total order between the units later on, when they are buried deep enough under newer units (see below how we do it). 16 | 当这些单元被深埋在新单元之下时（参见下面我们是怎么做的），我们在它们之间建立一个全序关系。 17 | The one that appears earlier on the total order is deemed valid, while the other is deemed invalid. 18 | 在全序中较早出现的被认为是有效的，而另一个被视为无效。 19 | 20 | 21 | There is one more protocol rule that simplifies the definition of total order. 22 | 有一个协议规则简化了全序的定义。 23 | 24 | We require, that if the same address posts more than one unit, it should include (directly or indirectly) all its previous units in every subsequent unit, i.e. there should be partial order between consecutive units from the same address. 25 | 如果相同地址发布多于一个单元，它在每一个后续单元中应该（直接地或间接地）包括所有它之前的单元，即，在同一地址的连续单元中应该有一个偏序。 26 | 27 | In other words, all units from the same author should be serial. 28 | 换句话说，所有来自同一个发起者的单元应该是连续的。 29 | 30 | If someone breaks this rule and posts two units such that there is no partial order between them (nonserial units), the two units are treated like double-spends even if they don’t try to spend the same output. 31 | 如果某人打破了这条规则并且发布了两个在它们之间没有偏序的单元（不连续单元），这两个单元被认为是双花，即使它们没有尝试花费相同的输出。 32 | 33 | Such nonserials are handled as described in situation 2 above. 34 | 这样不连续的单元按照上面的情况2处理。 35 | 36 | 2018-07-30 4 20 37 37 | 38 | >Figure 2. Double-spends. There is no partial order between them. 39 | 图2.双花 彼此之间没有偏序。 40 | 41 | 42 | If a user follows this rule but still tries to spend the same output twice, the double-spends become unambiguously ordered and we can safely reject the later one as in situation 1 above. 43 | 如果一个用户遵循这个规定但仍然尝试花相同的输出两次，双花变得明确有序，并且我们可以安全地拒绝拒绝后面的单元，像上面的情况1。 44 | 45 | The double-spends that are not nonserials at the same time are hence easily filtered out. 46 | 因此，在同一时间不是连续的双花很容易被过滤出来。 47 | 48 | 49 | This rule is in fact quite natural. 50 | 事实上，这条规则是很自然的。 51 | 52 | When a user composes a new unit, he selects the most recent other units as parents of his unit. 53 | 当用户组成一个新的单元，它选择最近的其它单元作为它的父单元。 54 | 55 | By putting them on his parents list, he declares his picture of the world, which implies that he has seen these units. 56 | 通过把它们列到它的父辈清单，它向世界宣布了它的构图，这暗示了它已经看到了这些单元。 57 | 58 | He has therefore seen all parents of parents, parents of parents of parents, etc up until the genesis unit. 59 | 因此，它已经看到了所有父辈的父辈，父辈的父辈的父辈，直到创世单元。 60 | 61 | This huge set should obviously include everything that he himself has produced, and therefore has seen. 62 | 这个巨大的集合应该显然包含了它自己产生的一切，因此已经看到了。 63 | 64 | By not including a unit (even indirectly, through parents) the user denies that he has seen it. 65 | 通过不包括一个单元（甚至间接地通过父母），用户否认它已经看到它。 66 | 67 | If we see that by not including his own previous unit a user denies having seen it, we’d say it’s odd, something fishy is going on. 68 | 如果我们看到用户否认看见它，通过不包含包括它自己和它之前的单元，我们会认为这是奇怪的，可疑的事情正在发生。 69 | 70 | We discourage such behavior. 71 | 我们会阻止这种行为。 72 | -------------------------------------------------------------------------------- /Projects/Byteball/5. The Main Chain.md: -------------------------------------------------------------------------------- 1 | ## 5.The main chain 2 | 3 | ## 5.主链 4 | 5 | Our DAG is a special DAG. 6 | 我们的DAG是一个特殊的DAG。 7 | 8 | In normal use, people mostly link their new units to slightly less recent units, meaning that the DAG grows only in one direction. 9 | 在常规使用中，人们大多把新单元与稍早出现的单元连接起来，这意味着DAG只朝一个方向发展。 10 | 11 | One can picture it as a thick cord with many interlaced wires inside. 12 | 我们可以把它想象成一根粗的电线，里面有许多交错的电线。 13 | 14 | This property suggests that we could choose a single chain along child-parent links within the DAG, and then relate all units to this chain. 15 | 这个属性表明我们可以在DAG中的父子链中选择单个链，然后将所有单元与此链相关联。 16 | 17 | All the units will either lie directly on this chain, which we’ll call the main chain, or be reachable from it by a relatively small number of hops along the edges of the graph. 18 | 所有单元可以直接在这条链上，我们称这条链位主链，或者沿着图的边缘在几步之内可以到达这条主链。 19 | 20 | It’s like a highway with connecting side roads. 21 | 这像一条连着辅路的高速公路。 22 | 23 | 24 | One way to build a main chain is to develop an algorithm that, given all parents of a unit, selects one of them as the “best parent”. 25 | 建立主链的一个方法是设计一个算法，已知一个单元的所有父辈单元，选择它们中的一个作为“最优父辈单元”。 26 | 27 | The selection algorithm should be based only on knowledge available to the unit in question, i.e. on data contained in the unit itself and all its ancestors. 28 | 选择算法应该仅仅基于对于所讨论单元可用的知识，即，关于单元本身及其所有祖先的数据。 29 | 30 | Starting from any tip (a childless unit) of the DAG, we then travel backwards in history along the best parent links. 31 | 从DAG的任一末端单元（无后代单元）开始，我们沿着最优父辈单元链向过去集前进。 32 | 33 | Traveling this way, we build a main chain and eventually arrive at the genesis unit. 34 | 以这种方法前进，我们建立了一条主链并且最终到达创世单元。 35 | 36 | Note that the main chain built starting from a specific unit will never change as new units are added. 37 | 注意，从一个特定单元开始的主链将不会随着新单元的添加而改变。 38 | 39 | This is because on each step we are traveling from child to parent, and an existing unit can never acquire new parents. 40 | 这是因为每一步，我们都是从孩子单元到父母单元，而现有的单元永远无法获得新的父母单元。 41 | 42 | If we start from another tip, we’ll build another main chain. 43 | 如果我们换一个末端单元开始，我们将建立另一条主链。 44 | 45 | Of note here is that if those two main chains ever intersect while they go back in history, they will both go along the same path after the intersection point. 46 | 值得注意的是，如果这两个主链在向过去集行进时相交，它们将在交点之后沿着同一条路径前进。 47 | 48 | In the worst case, the main chains will intersect only in genesis. 49 | 更坏的情况是，主链仅仅在创世单元相交。 50 | 51 | Given that the process of unit production is not coordinated among users, however, one might expect to find a class of main chains that do converge not too far from the tips. 52 | 已知单元产生的过程用户间没有协调，然而，用户可能希望找到在末端单元不远处会于一点的一类主链。 53 | 54 | 55 | 56 | 2018-07-30 10 23 46 57 | 58 | >Figure 3. Main chains built from different childless units intersect and then go along the same path. Of the two double-spends, the one with the lower main chain index (5) wins, while the other (with MCI=6) is deemed invalid. 59 | 60 | >图3. 不同的无后代单元构建的主链相交，然后沿着相同的路径行进。在双花中，主链索引值（5）较低的获胜，而另一条（MCI = 6）被认为无效。 61 | 62 | 63 | Once we have a main chain (MC), we can establish a total order between two conflicting nonserial units. 64 | 一旦我们有主链，我们可以在两个冲突且不连续的单元之间建立一个全序。 65 | 66 | Let’s first index the units that lie directly on the main chain. 67 | 首先为直接在链上的单元建立索引。 68 | 69 | The genesis unit has index 0, the next MC unit that is a child of genesis has index 1, and so on traveling forward along the MC we assign indexes to units that lie on the MC. 70 | 创世单元索引值为0，下一个主链单元是创世单元的孩子单元索引为1，因此沿着主链向前，我们给每一个在主链上的单元分配一个索引值。 71 | 72 | For units that do not lie on the MC, we can find an MC index where this unit is first included (directly or indirectly). 73 | 对于不在主链上的单元，我们可以找到最先（直接或间接地）包括这个单元的主链的索引值。 74 | 75 | In such a way, we can assign an MC index (MCI) to every unit. 76 | 在这种方式中，我们给每一个单元分配了一个主链索引值（MCI） 77 | 78 | Then, of the two nonserials, the one that has a lower MCI is considered to come earlier and deemed valid, while the other is invalid. 79 | 之后，两个不连续的单元中，具有更低的MCI的单元被认为是较早的和有效的，而另一个是无效的。 80 | 81 | If both nonserials happen to have the same MCI, there is tiebreaker rule that the unit with the lower hash value (as represented in base64 encoding) is valid. 82 | 如果不连续的单元碰巧有相同的MCI，有一个决胜局规则，具有较低哈希值的单元（如base64编码所示）有效。 83 | 84 | Note that we keep all versions of the double-spend, including those that eventually lose. 85 | 请注意，我们会保留所有形式的双花，包括那些最终会失败的形式。 86 | 87 | DagCoin [3] was the first published work that suggested storing all conflicting transactions and deciding which one to treat as valid. 88 | DagCoin[3]是第一个被发布的建议存储所有冲突交易和决定哪一个被认为是有效的成果。 89 | 90 | The MC built from a specific unit tells us what this unit’s author thinks about the order of past events, i.e. his point of view about the history. 91 | 由一个特定单元创建的主链会告诉我们这个单元的创建者如何看待过去集的顺序，即他对过去集的看法。 92 | 93 | The order then implies which nonserial unit to consider valid, as described above. 94 | 顺序表明了哪一个不连续的单元被认为是无效的，如上所述。 95 | 96 | Note that by choosing the best parent among all parents of a given unit, we are simultaneously making a choice among their MCs: 97 | 注意通过在一个已知单元的所有父辈中选择最优父辈单元，我们也同时在他们的主链中做出选择： 98 | 99 | the MC of the unit in question will be the MC of its best parent extended forward by one link. 100 | 所讨论的单元的主链将是其最优父辈单元通过一个个连接单元向前扩展的主链。 101 | 102 | Recognizing that many (or even all) parent units might be created by an attacker, and remembering that the choice of best parent is essentially the choice among versions of history, we should require from our best parent selection algorithm that it favors histories that are “real” from the point of view of the child unit. 103 | 考虑到许多（甚至所有）父辈单元可能由攻击者创建而且最优父辈单元的选择本质上是历史版本之间的选择，我们需要从我们最优父辈单元的选择算法，从子单元的角度来看有利于“真实”的过去集。 104 | 105 | We hence need to devise a “reality test” that our algorithm would run against all candidate MCs to select the one that scores best. 106 | 因此，我们需要设计一个“真实测试”，我们的算法将对所有候选主链测试，选择一个得分最高的主链。 107 | -------------------------------------------------------------------------------- /Projects/Byteball/6. Witnesses.md: -------------------------------------------------------------------------------- 1 | ## 6. Witnesses 2 | ## 6.见证人 3 | 4 | Looking for a “reality test”, observe that some of the participants of our network are non-anonymous reputable people or companies who might have a long established reputation, or they are businesses interested in keeping the network healthy. 5 | 寻找“真实测试”时，发现我们网络中的一些参与者是非匿名的信誉良好的人或可能具有长期声誉的公司，或者他们是对保持网络健康感兴趣的企业。 6 | 7 | We’ll call them witnesses. 8 | 我们称他们为见证人。 9 | 10 | While it is reasonable to expect them to behave honestly, it is also unreasonable to totally trust any single witness. 11 | 当希望他们表现出诚实行为的同时，完全相信任何一个见证人也是不合理的。 12 | 13 | If we know the Byteball addresses of several witnesses, and also expect them to post frequently enough, then to measure the reality of a candidate MC one might travel along the MC back in time and count the witness-authored units (if the same witness is encountered more than once, he is not counted again). 14 | 如果我们知道几个见证人的雪球地址，也期待他们足够频繁地发布单元，然后去衡量候选主链的真实性，可以及时沿着主链回退，数出见证人授权的单元（如果相同的见证人相遇不止一次，他就不会再被计数了）。 15 | 16 | We would stop traveling as soon as we had encountered the majority of witnesses. 17 | 一旦我们遇到大量的见证人，我们将停止回退。 18 | 19 | We would then measure the length of the longest path on the graph from the point at which we stopped to the genesis. 20 | 之后我们将测量从我们停下来的单元到创世单元在图中最长路径的长度。 21 | 22 | We’ll call this length the level of the unit where we stopped, and the witnessed level of the parent whose MC we are testing. 23 | 我们将这个长度称为我们停止的单元的级别和我们正在测试的主链的父辈单元的见证级别。 24 | 25 | The candidate MC that yields the greater witnessed level is considered more “real”, and the parent bearing this MC is selected as best parent. 26 | 产生更高见证级别的候选主链被认为是更“真实的”，带有该主链的父辈单元被选为最优父辈单元。 27 | 28 | In case there are several contenders with a maximum witnessed level, we would select the parent whose own level is the lowest. 29 | 如果有几个具有最大见证级别的竞争者，我们会选择具有最低级别的父级单元。 30 | 31 | If the tie persists, we would select the parent with the smallest unit hash (in base64 encoding). 32 | 如果仍然是平局，我们将选择拥有最小单元哈希值的父辈（使用base64编码）。 33 | 34 | This algorithm allows the selection of the MC that gravitates to units authored by witnesses, and the witnesses are considered to be representative of reality. 35 | 该算法允许选择被见证人授权的单元所在的主链，并且见证人被认为是真实的代表。 36 | 37 | If, for example, an attacker forks from the honest part of the network and secretly builds a long chain of his own units (shadow chain), one of them containing a double-spend, and later merges his fork back into the honest DAG, the best parent selection algorithm at the merger point will choose the parent that drives the MC into the honest DAG, as this is where the witnesses were active. 38 | 39 | 例如，如果攻击者从网络诚实单元处分叉，并且秘密地创建一条他自己的单元的长链（影子链），他们中的一个包含双花，之后分叉的单元又合并回诚实的DAG中，在合并点的最优父辈单元选择算法将选出将主链趋向诚实DAG的父辈单元，因为这是见证人活跃的位置。 40 | 41 | The witnesses were not able to post into the shadow chain simply because they didn’t see it before the merger. 42 | 见证人不能仅仅因为在合并之前没有看到它而进入影子链。 43 | 44 | This selection of MC reflects the order of events as seen by the witnesses and the user who appointed them. 45 | 主链的选择影响了见证人和指定他们的用户所看到的事件的顺序。 46 | 47 | After the attack is over, the entire shadow chain will land on the MC at one point, and the double-spend contained in the shadow chain will be deemed invalid because its valid counterpart comes earlier, before the merger point. 48 | 在攻击结束之后，整个影子链将在一点处连到主链上，被包含在影子链中的双花将被认为是无效的，因为它的有效对应部分在合并点之前出现。 49 | 50 | 2018-07-30 10 25 41 51 | 52 | >Figure 4. When an attacker rejoins his shadow DAG into the lit DAG, his units lose competition to become best parent as the choice favors those paths that have more witnesses (marked with w). 53 | 54 | >图4. 当攻击者将他的影子DAG重新加入到诚实的DAG中时，他的单元将失去成为最优父辈单元的竞争力，同时选择支持那些拥有更多见证人的路径（标有w）。 55 | 56 | This example shows why the majority of witnesses has to be trusted to post only serially. 57 | 这个例子表明了大多数被信任的见证人只能连续发布单元。 58 | 59 | The majority should not collude with the attacker and post on his shadow chain. 60 | 大多数见证人不应该与攻击者勾结并在他的影子链上发布单元。 61 | 62 | Note that we trust the witnesses only to be signs of reality and to not post nonserial units on any shadow chains. 63 | 注意，我们相信见证人仅仅是真实的标志并且没有在任何影子链上发布单元。 64 | 65 | We are not giving any of them control over the network or any part thereof. 66 | 我们不会让任何人控制网络或其任何部分。 67 | 68 | Even for this small duty, it is users who appoint the witnesses and they can change their decisions at any time. 69 | 即使对于这个小职责，也是指定见证人的用户，他们可以随时改变他们的决定。 70 | 71 | The idea of looking at some known entity as a sign of reality is not new. 72 | 将一些已知实体视为事实的标志的想法并不新鲜。 73 | 74 | It has long been known, and some companies have engaged in such activity, that to prove that some data existed before a specific date, one can hash the data and publish the hash in some hard-to-modify and widely witnessed media, like printed newspaper [6]. 75 | 人们早就知道，并且一些公司已经参与了这样的活动，为了证明某些数据在特定日期之前存在，人们可以对数据进行哈希运算并在一些难以修改和广泛被见证的媒体中发布哈希值，如印刷，报纸[6]。 76 | 77 | Witnesses in Byteball serve the same function as the newspaper. 78 | 在雪球中的见证人具有与报纸同样的功能。 79 | 80 | Like newspapers, they are well known and trusted. 81 | 像报纸一样，他们是广为人知的也是值得信任的。 82 | 83 | As for newspapers where trust is limited to trusting them to publish the data they are given, witnesses in Byteball are only trusted to post serially, and not much more. 84 | 对于那些仅限于信任发布他们已知数据的报纸，在雪球中的见证人仅仅信任连续发布的单元，而且没有很多。 85 | 86 | Like newspapers, witnesses don’t know what’s behind the hashes they are witnessing and have few reasons to care. 87 | 像报纸一样，见证人不知道他们所见证单元的哈希值并且没有理由去在意这个问题。 88 | 89 | 90 | Newspapers are hard to modify (but possible, and in 1984 they do it), while everything produced by witnesses is protected by digital signatures, which makes any modifications impossible. 91 | 报纸很难去修改（但是是可能的，在1984年他们做到了），而由证人产生的一切都受到数字签名的保护，这使得任何修改都不可能。 92 | 93 | For reliability, we have several witnesses, not just one, and for speed and convenience, these are online. 94 | 为了可靠性，我们有几个见证人，不止一个，为了速度和便利，他们都是在线的。 95 | 96 | Having decided on a list of witnesses, we can then select best the parent and the corresponding history that best fits the definition of reality as “somewhere where these witnesses live”. 97 | 已经决定见证人名单，之后，我们可以选择最优父辈和与像“这些见证人住在哪”的现实定义相符的历史单元。 98 | 99 | At the same time, the parents themselves might have different witness lists and consequently different definitions of reality. 100 | 与此同时，父辈本身可能有不同的见证人列表，因此，对真实有不同的定义。 101 | 102 | We want the definitions of reality, and histories that follow from them, to converge around something common. 103 | 我们需要真实的定义，跟随他们的历史单元，来围绕一些共同的事物汇聚。 104 | 105 | To achieve this, we introduce the following additional protocol rule. 106 | 为了实现这个，我们介绍以下额外的协议规则。 107 | 108 | 109 | The “near-conformity rule”: best parents must be selected only among those parents whose witness list differs from the child’s witness list by no more than one mutation. 110 | “近乎一致的规则”：最优父辈必须只在那些与见证人列表不同于孩子见证人且超过一个变化的父辈中选择。 111 | 112 | This rule ensures that witness lists of neighboring units on the MC are similar enough, therefore their histories mostly agree with one another. 113 | 这条规则确保见证人列表中在主链上的邻居单元足够相似，因此，他们历史单元大多数都认同另一个单元。 114 | 115 | The parents whose witness list differs by 0 or 1 mutation will be called compatible (with the unit that includes them directly), while the others are incompatible. 116 | 见证人列表变化为0或1的父辈单元将被称为是兼容的（与直接包括他们的单元），而其他单元是不兼容的。 117 | 118 | Incompatible parents are still permitted, but they have no chance of becoming best parent. 119 | 不兼容的父辈仍然被承认，但是他们没有机会成为最优父辈。 120 | 121 | If there are no compatible potential parents among childless units (an attacker could flood the network with his units that carry a radically different witness list), one should select parents from older units. 122 | 如果在没有后代的单元中没有兼容性的父辈（攻击者可能会将他的单元引入一个完全不同的证人名单），那么应该从较老的单元中选择父辈。 123 | 124 | 125 | The above means that each unit must list its witnesses so that they can be compared. 126 | 以上意味着每一个单元必须列出他的见证人以便于他们能被比较。 127 | 128 | We require that the number of witnesses is exactly 12. 129 | 我们需要见证人人数正好是12. 130 | 131 | This number 12 was selected because: 132 | 选择12是因为： 133 | 134 | • it is sufficiently large to protect against the occasional failures of a few witnesses (they might prove dishonest, or be hacked, or go offline for a long time, or lose their private keys and go offline forever); 135 | • 它是足够大的，可以防止少数证人的偶然失败（他们可能被证明是不诚实的，被黑，或长时间离线，或丢失私钥并永远离线）； 136 | 137 | • it is sufficiently small that humans can keep track of all the witnesses to know who is who and change the list when necessary; 138 | • 它是足够小的，保证人们保持追踪所有见证人，知道谁是谁并且在必要的时候可以改变列表； 139 | 140 | • the one allowed mutation is sufficiently small compared with the 11 unchanged witnesses. 141 | • 与11名未改变的见证人相比，一个改变是足够小的。 142 | 143 | In case a user thinks that any of the witnesses has lost his credibility, or there are just better candidates, the user can replace the witness with a new witness in his list, bearing in mind that his witness list may not differ from that of other units by more than one position. 144 | 如果用户认为任何见证人失去了信誉，或者有更好的候选人，用户可以用他的列表中的新见证人代替原来的见证人，请记住，他的见证人名单可能不止一个位置与其他单元的名单不同。 145 | 146 | This means that any changes can happen only gradually, and a general consensus is required for a change bigger than one position. 147 | 这意味着任何变化只能逐渐发生，并且对于多于一个位置的变化需要达成普遍共识。 148 | -------------------------------------------------------------------------------- /Projects/Byteball/7. Finality.md: -------------------------------------------------------------------------------- 1 | 2 | ## 7. Finality 3 | ## 7. 最终确认性 4 | 5 | As new units arrive, each user keeps track of his current MC which is built as if he were going to issue a new unit based on all current childless units. 6 | 当新单元出现时，每个用户注意他当前的主链，这条主链就好像他基于所有当前无后代单元发布的新单元建立的。 7 | 8 | The current MC may be different at different nodes because they may see different sets of childless units. 9 | 当前的主链在不同节点处可能是不同的，因为他们可能看到不同的无后代单元的集合。 10 | 11 | We require that the current MC be built without regard of witness lists, i.e. the user’s own witness list doesn’t matter and even incompatible parents can be selected as best parents. 12 | 我们需要建立当前的主链且不考虑见证人列表，即，与用户的见证人列表无关，甚至不相容的父辈可以被选作最优父辈。 13 | 14 | That means that if two users have the same set of childless units, but have different witness lists, their current MCs will still be identical. 15 | 那意味着如果两个用户有相同的无后代单元集合，但是有不同的见证人列表，他们当前的主链将是相同的。 16 | 17 | The current MC will constantly change as new units arrive. 18 | 当新的单元出现的时候，当前的主链经常改变。 19 | 20 | However, as we are about to show, a part of the current MC that is old enough will stay invariant. 21 | 然而，正如我们即将展示的那样，当前主链较老的一部分将保持不变。 22 | 23 | 24 | We expect witnesses (or rather the majority thereof) to behave honestly, therefore necessarily include their previous unit in the next unit authored by the same witness. 25 | 我们希望见证人（或者更确切地说是其中的大多数人）表现诚实，因此必须将他们以前的单元包括在由同一见证人发布的下一单元中。 26 | 27 | This means that when a witness composes a new unit, only recent units are candidates to be chosen as parents. 28 | 这意味着当一个见证人发布一个新单元时，仅仅最近的单元被选作父辈的候选单元。 29 | 30 | We might expect, therefore, that all future current MCs will converge no farther (when traveling back in time) than a particular stability point. 31 | 因此，我们会希望所有未来的当前主链将比特殊的稳定点更远地收敛（当及时回退时）。 32 | 33 | Indeed, the genesis unit is a natural initial stability point. 34 | 确实，创世单元本质上是一个最初的稳定点。 35 | 36 | Assume we have built a current MC based on the current set of childless units, and there was some point on this MC that was previously believed to be stable, i.e. all future current MCs are believed to converge on or before this point (again, when traveling back in time), and then travel along the same route. 37 | 假设我们建立一条基于当前无后代单元集合的主链，在这条主链上某个点之前被认为是稳定的，即，所有未来的当前主链被认为会收敛于这个点或在这个点之前收敛（当及时回退时），之后沿着相同的路径前进。 38 | 39 | If we can find a way of advancing this point forward (away from the genesis), we can prove by induction that a stability point exists. 40 | 如果我们能找到推进这个点的方法（远离创始单元），我们可以通过归纳证明稳定点的存在。 41 | 42 | 43 | Note that if we forget about all parents except the best parent, our DAG will be reduced to a tree that consists only of best parent links. 44 | 注意如果我们忘记所有父辈除了最优父辈，我们的DAG将缩减为仅仅包含与最优父辈联系的一颗树。 45 | 46 | Obviously, all MCs will go along the branches of this tree. 47 | 显然，所有主链将沿着这棵树的分支前进。 48 | 49 | We then need to consider two cases – when the tree does branch in the current stability point and when it does not – and decide if we can advance the stability point to the next MCI. 50 | 之后我们需要考虑两种情况———当树在当前稳定点分支时或当他不存在时，并决定是否我们可以从稳定点到下一个MCI。 51 | 52 | 53 | 54 | 2018-07-30 10 28 00 55 | 56 | >Figure 5. A tree composed of best-parent links. All but one branches stop growing after some point. 57 | 58 | >图5. 由最好的父辈链接组成的树。在某个时刻，除了一个分支其他分支都停止生长。 59 | 60 | 61 | First, assume the tree does not branch. 62 | 首先，假设树没有分支。 63 | 64 | We then need to consider the possibility that a new branch will still be added and somehow supported by the witnesses so that it outgrows the existing branch. 65 | 之后，我们需要考虑新的分支将仍会被添加的可能性，而且在某种程度上被见证人支持所以他超出了现有的分支。 66 | 67 | The other possibility is that the witnesses put so much weight in support of the existing branch, that the requirement of including one’s previous unit leaves them no options but continue supporting the existing branch. 68 | 另一种可能性是见证人对现有的分支给予了很大的支持，包括前一个单元的要求使他们没有选择余地，但继续支持现有的分支。 69 | 70 | Let’s quantify the latter possibility. 71 | 让我们量化后一种可能性。 72 | 73 | Remember that best parent is selected as the parent with the greatest witnessed level. 74 | 请记住，最优父辈被选为父辈的见证水平最高。 75 | 76 | Let’s travel back in time along the current MC from the tip until we meet the majority of witnesses (we are referring to witnesses as defined by the unit lying on the current stability point). 77 | 让我们从无后代单元沿着当前主链及时回退直到我们遇到大多数的见证者（我们指的是由当前稳定点所在单元定义的目击者）。 78 | 79 | If at least one of them lies earlier than the current stability point, we do not try to advance the stability point, otherwise we proceed. 80 | 如果他们中至少一个位于比当前稳定点早的位置，我们不尝试推进稳定点，否则我们继续进行。 81 | 82 | In this case, all these witnesses are already “invested” into the current MC. 83 | 在这种情况下，所有见证人都已经“投资”到当前主链。 84 | 85 | Among these witnesses, we find the minimum witnessed level min_wl. 86 | 在这些见证人中，我们得到最小被见证级别min_wl。 87 | 88 | When any of these witnesses posts a new unit, this unit might have parents whose MC leads to the current MC and parents whose MC leads to a competing branch, and the parent with the highest witnessed level will be selected as best parent and will define the direction of the next current MC. 89 | 当任何一个见证人发布一个新的单元，该单元可能具有其主链引导当前主链并且导致竞争分支的父辈，而且具有最高见证级别的父辈将被选择为最优父辈，并且将定义下一个当前主链的方向。 90 | 91 | Since the witness has to include its previous unit, the witnessed level of the parent leading to the current MC will be at least min_wl. 92 | 因为见证人不得不包括他之前的单元，引导当前主链的父辈见证级别至少是min_wl。 93 | 94 | The witnessed level of any parent leading to the alternative branch will never exceed the level of the current stability point, even if all remaining (minority) witnesses flock to the alternative branch. 95 | 任何一个导致替换分支的父辈见证级别永远不会超过当前稳定点的水平，即使所有剩余的（少数）目击者聚集到另一个分支。 96 | 97 | Therefore, if the current MC grows far enough so that min_wl is greater than the level of the current stability point, the majority of witnesses will have to increase support for the existing current MC, the alternative branch has then lost all chances to win, and we can move the stability point forward to the next MCI. 98 | 因此，如果当前主链增长足够远，所以min_wl大于当前稳定点的水平，见证人的最大值将不得不加大对当前已知主链支持，另一个分支则失去了获胜的机会，我们可以从稳定点到下一个MCI。 99 | 100 | 101 | Next, assume the tree does branch. 102 | 之后，假设树有分支。 103 | 104 | We need to find a condition where the alternative branches will lose any chance to outgrow the current MC. 105 | 我们需要找到一个条件，其中替代分支将失去任何机会超越当前主链。 106 | 107 | Let’s start by defining min_wl as in the previous case. 108 | 让我们从前面定义的min_wl开始。 109 | 110 | Among all units on the alternative branches, we then select those that increase the witness level, i.e. their own witnessed level is greater than that of every parent. 111 | 在替代分支的所有单元中，我们选择那些增加见证级别的单元，即，他们自己的见证级别比他的每一个级别都大。 112 | 113 | Among these, we find the maximum level. 114 | 在这些级别中，我们找到最大的级别。 115 | 116 | Then, even if all the remaining (minority) witnesses gather on the alternative branches, the witnessed level on the alternative branches will never exceed this maximum level. 117 | 之后，即使所有剩余的（少数）见证人聚集在替代分支上，见证级别的替代分支将永远不会超过这一最高水平。 118 | 119 | Therefore, if this maximum level is less than min_wl, game is over for the alternative branches, and we can advance the stability point along the current MC. 120 | 因此，如果这个最大级别少于min_wl，博弈结束了替代分支，我们可以沿着当前的主链提高稳定点。 121 | 122 | 123 | Thus, there is a point on the current MC before which the MC will never change (assuming the majority of witnesses don’t post nonserial units). 124 | 因此，在当前主链之前有一个点的主链不会改变（假设大多数见证人不发布非连续单元）。 125 | 126 | The total order defined relative to this MC is therefore also final. 127 | 因此，相对于该主链定义的全序也是不可更改的。 128 | If we had nonserials, our decision about which one of them is valid, is final as well. 129 | 如果我们有非连续的单元，我们关于哪一个单元是有效的决定也是不可更改的。 130 | 131 | 132 | If a new nonserial ever appears that conflicts with anything already on the stable MC, the new nonserial unit will definitely be ordered after the old counterpart, and the new one will be deemed invalid. 133 | 如果一个新的非连续单元显示在稳定的主链上的任何内容有冲突，新的非连续单元肯定会在较老的部分之后被定序，新的单元将被视为无效。 134 | 135 | Therefore, any payment made in the unit included on the stable MC is already irreversible. 136 | 因此，在稳定的主链中包括的任何支付都是不可逆转的。 137 | 138 | Unlike Bitcoin where transaction finality is only probabilistic, this is deterministic transaction finality. 139 | 不同于比特币的交易最终确认性是概率性的，这是确定的交易确认性。 140 | 141 | Every user builds his own (subjective) current MC based on the units that he sees. 142 | 每一个用户基于他所看见单元创建他自己的（主观的）当前主链。 143 | 144 | Since the propagation of new units is not instant, and they may arrive in different order to different users, the users will have different current MCs and different opinions about the last stable point of the MC at any given time. 145 | 由于新单元的传播不是即时的，并且它们可能以不同的顺序到达不同的用户，因此用户将具有不同的当前主链并且关于在任何给定时间的主链的最后稳定点的不同意见。 146 | 147 | However, since the current MC is defined solely by the set of units known to the user, in case user B hasn’t yet advanced his stability point to the same MCI as user A, he will inevitably do that later – i.e. as soon as he receives the same units as user A, or more. 148 | 然而，由于当前主链仅由用户已知的一组单元定义，如果用户B还没有将其稳定性点提升到与用户A相同的MCI，那么他将不可避免地稍后再做这一点——即一旦他接收到与用户A相同的单元，或更多。 149 | 150 | Thus the opinions of different users about the state of any given unit are eventually consistent. 151 | 因此，不同用户关于任何给定单元的状态的意见最终是一致的。 152 | -------------------------------------------------------------------------------- /Projects/Byteball/8. Storage of nonserial units.md: -------------------------------------------------------------------------------- 1 | ## 8. Storage of nonserial units 2 | ## 8. 存储非连续单元 3 | 4 | When we decide that a unit is a nonserial, we still have to store it. 5 | 当我们认为一个单元是不连续的，我们仍然需要存储它。 6 | 7 | However, part of its data is replaced with a hash of the data. 8 | 然而，它的部分数据辈数据的哈希值代替。 9 | 10 | This rule serves two purposes. 11 | 这条规则有两个目的。 12 | 13 | First, to reduce storage consumed by a unit that nobody paid for (the entire content of the nonserial unit is deemed invalid, including its payment of commissions). 14 | 第一，减少没有人支付的单位所消耗的存储量（非串行单元的全部内容被认为无效，包括支付佣金）。 15 | 16 | Second, to reduce the utility of the nonserial to the user who sent it, because the hash replaces all useful data that the author wanted to store (for free). 17 | 第二，为了减少非连续单元给发送它的用户的存储效率，因为散列取代了发布者想要存储的所有有用数据（免费）。 18 | 19 | This prevents attackers from abusing nonserials as a way to store large amounts of data for free. 20 | 这可以防止攻击者滥用非连续单元作为免费存储大量数据的方式。 21 | 22 | 23 | The hash that is stored instead of the full content still has some utility to the attacker, as he can store the original data himself and use the hash to prove that the data existed. 24 | 存储的哈希值代替完整内容对攻击者仍然有用，因为他能存储他自己的原始数据并使用哈希值来证明数据存在。 25 | 26 | But remember that: 27 | 但是记住： 28 | 29 | 1. He still has to pay for one unit that is deemed valid 30 | 他仍然不得不为一个被认为是有效的单元支付手续费。 31 | 32 | 2. If the attacker is already internally storing metadata that is necessary to interpret Byteball data, he could do equally well by just combining all his data into a Merkle tree and using Byteball to store only its Merkle root for the cost of one small unit. 33 | 如果攻击者已经在内部存储解释字节球数据所必需的元数据，那么他可以通过将所有的数据组合成Melkle树，并使用字节雪球来存储MelKel的根用于存储一个小单元的成本，这同样可以做得很好。 34 | 35 | 36 | Under this design, there is therefore no self-interest in trying to send nonserials. 37 | 因此，在这种设计中，尝试发送非连续的单元是没有私利的。 38 | 39 | It ought to be mentioned that we cannot just reject nonserials the first time we see them. 40 | 应该提到的是，我们第一次看到非连续单元就不能拒绝。 41 | 42 | If we did, an attacker could send his nonserials to different users in different order. 43 | 如果我们这么做了，攻击者可能以不同的顺序发送他的非连续单元给不同的用户。 44 | 45 | Different users would then stick to the versions they first received and reject everything based on the other version, so the attacker would succeed in partitioning the network. 46 | 然后，不同的用户会坚持他们最初收到的版本，并拒绝所有基于其他版本的内容，因此攻击者将成功分割网络。 47 | 48 | That’s why we have to store both versions and then decide on their order. 49 | 这就是为什么我们必须存储两个版本，然后决定他们的顺序。 50 | 51 | Even more, users should forward nonserials to peers just like any other units, as the sooner peers learn about the nonserials the better. 52 | 更重要的是，用户应该像任何其他单元一样将非连续的单元转发给同级的单元，因为越接近同级的单元就越了解非连续单元。 53 | 54 | We still try to avoid including nonserials if possible: the parent selection algorithm excludes nonserials as long as they are childless. 55 | 如果可能的话，我们仍然尝试避免包括非连续单元：父辈选择算法不包括非连续单元，只要它们是无子女的单元都不包括在内。 56 | 57 | For this reason, it’s desirable to help peers learn about nonserials as soon as possible. 58 | 出于这个原因，最好是帮助同级的单元尽快了解非连续单元。 59 | -------------------------------------------------------------------------------- /Projects/Byteball/ABSTRACT.md: -------------------------------------------------------------------------------- 1 | 2 | >* **Source：** [https://byteball.org/Byteball.pdf](https://byteball.org/Byteball.pdf) 3 | >* **TranStudy：** [https://github.com/DAGfans/TranStudy/tree/master/Projects/Byteball 4 | ](https://github.com/DAGfans/TranStudy/tree/master/Projects/Byteball 5 | ) 6 | 7 | # Byteball: A Decentralized System for Storage and Transfer of Value 8 | # 字节雪球: 去中心化的存储和价值转移系统 9 | 10 | #### Anton Churyumov 11 | #### tonych@byteball.org 12 | 13 | ## Abstract 14 | ## 摘要 15 | 16 | Byteball is a decentralized system that allows tamper proof storage of arbitrary data, including data that represents transferrable value such as currencies, property titles, debt, shares, etc. 17 | Storage units are linked to each other such that each storage unit includes one or more hashes of earlier storage units, which serves both to confirm earlier units and establish their partial order. 18 | The set of links among units forms a DAG (directed acyclic graph). 19 | There is no single central entity that manages or coordinates admission of new units into the database, everyone is allowed to add a new unit provided that he signs it and pays a fee equal to the size of added data in bytes. 20 | The fee is collected by other users who later confirm the newly added unit by including its hash within their own units. 21 | As new units are added, each earlier unit receives more and more confirmations by later units that include its hash, directly or indirectly. 22 | 23 | Byteball是一个去中心化的系统，允许防篡改地存储任意数据，包括表示货币，财产所有权，债务，股份等可转移价值的数据。 24 | 存储单元彼此链接，以使每个存储单元包含一个或多个先前存储单元的散列，这既用于确认先前的单元，也用于确定它们的偏序。 (译注: 偏序这里指两个单元之间的顺序, 但是无法确定这些单元在在所有单元之间的顺序) 25 | 单元之间的链接集形成了一个DAG（有向无环图）。 26 | 没有一个单一的中央实体管理或协调新单元加入到数据库中，每个节点都可以添加一个新的单元，只要它签名并支付与添加数据大小相等的费用（以字节为单位）。 27 | 该费用由其他用户收集，后者通过将其散列包含在其自己的单元中来确认新添加的单元。 28 | 随着新单元的添加，每个较早的单元将通过后续单元（包括其散列）直接或间接地收到越来越多的确认。 29 | 30 | There is an internal currency called ‘bytes’ that is used to pay for adding data into the decentralized database. 31 | Other currencies (assets) can also be freely issued by anyone to represent property rights, debt, shares, etc. 32 | Users can send both bytes and other currencies to each other to pay for goods/services or to exchange one currency for another; 33 | the transactions that move the value are added to the database as storage units. 34 | If two transactions try to spend the same output (double-spend) and there is no partial order between them, both are allowed into the database but only the one that comes earlier in the total order is deemed valid. 35 | Total order is established by selecting a single chain on the DAG (the main chain) that is attracted to units signed by known users called witnesses. 36 | A unit whose hash is included earlier on the main chain is deemed earlier on the total order. 37 | Users choose the witnesses by naming the user-trusted witnesses in every storage unit. 38 | Witnesses are reputable users with real-world identities, and users who name them expect them to never try to double-spend. 39 | As long as the majority of witnesses behave as expected, all double-spend attempts are detected in time and marked as such. 40 | As witnesses-authored units accumulate after a user’s unit, there are deterministic (not probabilistic) criteria when the total order of the user’s unit is considered final. 41 | 42 | 有一种称为“字节(bytes)”的内部货币，用于支付将数据添加到去中心化数据库的费用。 43 | 其他货币（资产）也可以由任何人免费发行以代表产权，债务，股票等。 44 | 用户可以相互将字节和其他货币发送给对方以支付商品/服务或兑换一种货币为另一种货币; 45 | 转移价值的交易将作为存储单元添加到数据库中。 46 | 如果两个交易尝试花费相同的输出（双花）并且它们之间没有偏序，则两个交易都被允许进入数据库，但只有全序中较早的交易才被视为有效。(译注: 全序代表所有交易都需要排序, 而上文中的偏序只要指定的交易集可以排序) 47 | 全序是通过选择被称为见证人的已知用户签名的单元组成的DAG上的单条链（主链）来建立的。 48 | 单元的散列如果在主链上较早地被包含则在全序中被认为较早。 49 | 用户通过在每个存储单元中指定信任的见证人来选择它们。 50 | 见证人是有真实世界身份的且有信誉的用户，并且指定它们的用户也期望它们永远不会尝试双花。 51 | 只要大多数见证人的行为如预期一样，所有的双花尝试都会被及时发现并被标记。 52 | 随着见证人产生的单元在用户单元之后积累，会有明确的（非概率性）标准来判断用户单元的全序能否最终确认。 53 | 54 | Users store their funds on addresses that may require more than one signature to spend (multisig). 55 | Spending may also require other conditions to be met, including conditions that are evaluated by looking for specific data posted to the database by other users (oracles). 56 | 57 | 用户可将他们的资金存储在需要多重签名（multisig）才能花费的地址上。 58 | 花费也可能需要满足其他条件，例如需要通过查找其他用户发布到数据库的特定数据（预言机）才能得到。 59 | 60 | Users can issue new assets and define rules that govern their transferability. 61 | The rules can include spending restrictions such as a requirement for each transfer to be cosigned by the issuer of the asset, which is one way for financial institutions to comply with existing regulations. 62 | Users can also issue assets whose transfers are not published to the database, and therefore not visible to third parties. 63 | Instead, the information about the transfer is exchanged privately between users, and only a hash of the transaction and a spend proof (to prevent double-spends) are published to the database. 64 | 65 | 用户可以发布新资产并定义规则来管理转账。 66 | 这些规则可以包括花费限制，例如每次转账要求由资产发行人联合签名，这是金融机构遵守现有规定的一种方式。 67 | 用户也可以发布不公布转账信息到数据库的资产，因此对第三方不可见。 68 | 相反，有关转账的信息是在用户之间私下交换的，只有交易散列和花费证明（防止双花）才会公布到数据库。 69 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 边学边译 2 | 翻译是很好的学习方法，不给自己留下任何偷懒的空间。学习完了，也留下了一个公开的详尽的读书笔记, 利人利己，更有可能和志同道合的朋友一同交流，实为美事一桩。 3 | 4 | ## 分栏介绍 5 | - Blogs 优质文章，科普入门 6 | - Papers 严肃论文, 深度学习 7 | 8 | ## 协定 9 | 1. 翻译只是手段，学习才是目的，尽可能多加注释 10 | 2. 机译直译意译均可，表达清楚即可 11 | 3. 必须完全理解，即使不确定也要写清注释 12 | 13 | ## 排版 14 | 1. 文章头部贴上原文链接，对原作者表示尊重 15 | 2. 简单的公式尽量用字符或者HTML表示 16 | 3. 复杂的公式采用编辑器， https://latex.codecogs.com/eqneditor/editor.php，必须是SVG格式 17 | 4. 编辑试图中每一句都要加单换行, 方便定位，但是不影响展示 18 | 5. 脚注直接在所在段落后面添加，方便定位 19 | 6. 每一章节都需要添加该章节的参考目录 20 | 7. 标题到摘要合并为第0章, 鸣谢和参考可以合并为最后一章 21 | 8. 一个项目对应Papers下面的一个文件夹，一章一个文档，标题为 [Chapter NO]-[Chapter Name].md --------------------------------------------------------------------------------