{"id":30047,"date":"2019-10-31T21:33:25","date_gmt":"2019-10-31T18:33:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/razbiraemsya-v-protokole-konsensusa-stellar\/"},"modified":"2019-10-31T21:33:25","modified_gmt":"2019-10-31T18:33:25","slug":"razbiraemsya-v-protokole-konsensusa-stellar","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/razbiraemsya-v-protokole-konsensusa-stellar","title":{"rendered":"Understanding the Stellar Consensus Protocol","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Understanding
\n
\nThe Stellar Consensus Protocol is first described in a scientific paper<\/a><\/noindex> by David Mazieres in 2015. It is a 'federated Byzantine agreement' system that allows decentralized computing networks without leaders to efficiently reach consensus on any decision. The Stellar payment network utilizes the Stellar Consensus Protocol (SCP) to maintain a consistent transaction history visible to all participants.<\/p>\n

Consensus protocols are considered to be difficult to understand. SCP is simpler than most of them, yet still shares this reputation\u2014partly due to the misconception that the 'federated voting' discussed in the first half of the scientific paper is SCP. But that is not the case! It is merely an important building block used in the second half of the paper to construct the actual<\/i> Stellar Consensus Protocol.
\n<\/a><\/noindex>
\nIn this article, we will briefly explain what an 'agreement system' is, what can make it 'Byzantine', and why a Byzantine system should be 'federated'. We will then explain the federated voting procedure described in the SCP paper and finally explain the SCP itself.<\/p>\n

Agreement Systems<\/h1>\n

\nAn agreement system allows a group of participants to reach consensus on a topic, such as what to order for lunch.<\/p>\n

At Interstellar, we have implemented our own lunch agreement system: we order what our operations manager John says. It is a simple and effective agreement system. We all trust John and believe he will find something interesting and nutritious every day.<\/p>\n

But what if John abuses our trust? He could unilaterally decide that we should all become vegetarians. Within a week or two, we might likely overthrow him and hand the power to Elizabeth. But what if she loves avocado with anchovies and thinks everyone should be that way? Power corrupts. So it\u2019s better to find a more democratic method: a way to ensure that different preferences are considered while also providing a timely and clear result, so that it doesn\u2019t end up with no one ordering lunch or five people placing different orders, or the discussion dragging on until evening.<\/p>\n

It may seem like a simple solution: hold a vote! But this is a misleading impression. Who will collect the ballots and announce the results? And why should the others trust what he says? Perhaps we can first<\/i> vote for a leader we trust to conduct the voting \u2014 but who will lead this the first<\/i> voting? What if we can't agree on a leader? Or if we do agree, and this leader gets stuck in a meeting or falls ill?<\/p>\n

Similar problems occur in distributed computer networks. All participants or nodes need to agree on some decision, such as whose turn it is to update a shared file or take a task from the processing queue. In a cryptocurrency network, nodes often have to choose what the complete history looks like from several possible versions, which sometimes conflict. This network agreement guarantees the recipient that the coin is (a) valid (not counterfeit) and (b) not yet spent elsewhere. It also ensures that they will be able to spend the coins in the future, as the new recipient will have the same guarantees for the same reasons.<\/p>\n

Any consensus system in a distributed computing network must be fault-tolerant: it should provide consistent results despite errors, such as slow communication lines, unresponsive nodes, and incorrect message ordering. Byzantine<\/i> consensus systems are additionally resilient to 'Byzantine' faults: nodes that provide false information, whether due to error or a deliberate attempt to undermine the system or gain some advantage. 'Byzantine' fault tolerance \u2014 the ability to trust a group decision even when some members of the group may lie or otherwise break the decision-making rules \u2014 is named after the fable of the Byzantine generals<\/a><\/noindex>, who tried to coordinate an attack. A good description<\/a><\/noindex> is by Anthony Stevens.<\/p>\n

Let's consider the cryptocurrency owner Alice, who has to choose between buying delicious ice cream from Bob and paying off her debt to Carol. Perhaps Alice wants to pay both at once, fraudulently spending the same coin. To do this, she must convince Bob's computer that the coin was never paid to Carol and convince Carol's computer that the coin was never paid to Bob. The Byzantine agreement system makes this virtually impossible using a majority rule form called a quorum<\/i>. A node in such a network refrains from transitioning to a certain version of history until it sees that a sufficient number of peer nodes\u2014a quorum\u2014agree to that transition. Once this happens, they will form a large enough electoral block to compel the remaining nodes in the network to accept their decision. Alice can force some nodes to lie on her behalf, but if the network is large enough, her attempt will be suppressed by the votes of honest nodes.<\/p>\n

How many nodes are required for a quorum? At least a majority, or more precisely, a qualified majority to combat errors and fraud. But to count a majority, the total number of participants must be known. In an Interstellar office or local elections, these numbers are easy to ascertain. But if your group is a loosely defined network in which nodes can join and leave at will without consent from a center, then a federated<\/i> Byzantine agreement system is required, one capable of determining quorums not from a pre-defined list of nodes, but dynamically, from a constantly changing and inevitably incomplete snapshot of nodes at any given moment in time.<\/p>\n

It may seem impossible to create a quorum from the perspective of a single node in an expansive network, but it is indeed possible. Such a quorum can even guarantee the results of decentralized voting. The technical document SCP shows how to achieve this using a procedure called federated voting.<\/i>.<\/p>\n

For the impatient<\/h1>\n

\nThe rest of the article goes into more detail about federated voting and the Stellar consensus protocol. If you're not interested in the specifics, here\u2019s a general overview of the process.<\/p>\n

    \n
  1. Nodes conduct rounds of federal voting on 'nominees.' A round of federal voting means:\n