0% found this document useful (0 votes)
53 views10 pages

Ripple Consensus Whitepaper

The document discusses a consensus algorithm for distributed payment systems called the Ripple Protocol. It aims to achieve correctness, agreement, and utility through minimizing latency. Components of the Ripple Protocol are defined, as are the goals of consensus algorithms. Previous work on the Byzantine Generals Problem and its relation to distributed systems is also summarized.

Uploaded by

bitjacky.xu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
53 views10 pages

Ripple Consensus Whitepaper

The document discusses a consensus algorithm for distributed payment systems called the Ripple Protocol. It aims to achieve correctness, agreement, and utility through minimizing latency. Components of the Ripple Protocol are defined, as are the goals of consensus algorithms. Previous work on the Byzantine Generals Problem and its relation to distributed systems is also summarized.

Uploaded by

bitjacky.xu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 10

The Ripple Protocol Consensus Algorithm

David Schwartz This paper does not reflect the current state of the ledger consensus protocol or its
[email protected] analysis. We will continue hosting this draft for historical interest, but it SHOULD NOT be
used as a reference. For an updated analysis and presentation of the consensus
protocol, please refer to arXiv:1802.07242 (https://arxiv.org/abs/1802.07242), released
Noah Youngs 20 February 2018.
[email protected]

Arthur Britto
[email protected]

Abstract
While several consensus algorithms exist for the Byzantine Generals Problem, specifically as it
pertains to distributed payment systems, many suffer from high latency induced by the requirement
that all nodes within the network communicate synchronously. In this work, we present a novel
consensus algorithm that circumvents this requirement by utilizing collectively-trusted subnetworks
within the larger network. We show that the “trust” required of these subnetworks is in fact minimal
and can be further reduced with principled choice of the member nodes. In addition, we show that
minimal connectivity is required to maintain agreement throughout the whole network. The result is
a low-latency consensus algorithm which still maintains robustness in the face of Byzantine failures.
We present this algorithm in its embodiment in the Ripple Protocol.

Contents 1. Introduction
1 Introduction 1
2 Definitions, Formalization and Previous Work 2 Interest and research in distributed consensus systems
has increased markedly in recent years, with a central
2.1 Ripple Protocol Components...........................2 focus being on distributed payment networks. Such
2.2 Formalization.......................................................3 net- works allow for fast, low-cost transactions which are
2.3 Existing Consensus Algorithms.......................3 not controlled by a centralized source. While the
economic benefits and drawbacks of such a system are
2.4 Formal Consensus Goals..................................3
worthy of much research in and of themselves, this
3 Ripple Consensus Algorithm 4 work focuses on some of the technical challenges that
3.1 Definition..............................................................4 all distributed payment systems must face. While these
3.2 Correctness.........................................................4 problems are varied, we group them into three main
categories: cor- rectness, agreement, and utility.
3.3 Agreement...........................................................5 By correctness, we mean that it is necessary for a
3.4 Utility.....................................................................5 distributed system to be able to discern the difference be-
Convergence • Heuristics and Procedures tween a correct and fraudulent transaction. In traditional
4 Simulation Code 7 fiduciary settings, this is done through trust between
institutions and cryptographic signatures that
5 Discussion 7
guarantee a transaction is indeed coming from the
6 Acknowledgments 8 institution that it claims to be coming from. In
References 8 distributed systems, however, there is no such trust, as
the identity of any and all members in the network may
not even be known. Therefore, alternative methods for
correctness must be
utilized. a distributed payment system must be robust both in
Agreement refers to the problem of maintaining a the face of standard failures, and so-called
single global truth in the face of a decentralized account- “Byzantine” failures, which may be coordinated and
ing system. While similar to the correctness problem, originate from multiple sources in the network.
the difference lies in the fact that while a malicious In this work, we analyze one particular implemen-
user of the network may be unable to create a fraudu- tation of a distributed payment system: the Ripple Pro-
lent transaction (defying correctness), it may be able tocol. We focus on the algorithms utilized to achieve
to create multiple correct transactions that are the above goals of correctness, agreement, and utility,
somehow unaware of each other, and thus combine to and show that all are met (within necessary and predeter-
create a fraudulent act. For example, a malicious user mined tolerance thresholds, which are well-understood).
may make two simultaneous purchases, with only In addition, we provide code that simulates the
enough funds in their account to cover each purchase consen- sus process with parameterizable network
individually, but not both together. Thus each size, number of malicious users, and message-sending
transaction by itself is correct, but if executed latencies.
simultaneously in such a way that the distributed
network as a whole is unaware of both, a clear 2. Definitions, Formalization
problem arises, commonly referred to as the “Double- and Previous Work
Spend Problem” [1]. Thus the agreement problem can We begin by defining the components of the Ripple
be summarized as the requirement that only one set of Protocol. In order to prove correctness, agreement,
globally recognized transactions exist in the network. and utility properties, we first formalize those properties
Utility is a slightly more abstract problem, which we into axioms. These properties, when grouped together,
define generally as the “usefulness” of a distributed pay- form the notion of consensus: the state in which nodes
ment system, but which in practice most often simplifies in the network reach correct agreement. We then
to the latency of the system. A distributed system that highlight some previous results relating to consensus
is both correct and in agreement but which requires algorithms, and finally state the goals of consensus for
one year to process a transaction, for example, is the Ripple Protocol within our formalization
obviously an inviable payment system. Additional framework.
aspects of util- ity may include the level of computing
power required to participate in the correctness and 2.1 Ripple Protocol Components
agreement processes or the technical proficiency We begin our description of the ripple network by defin-
required of an end user to avoid being defrauded in the ing the following terms:
network.
Many of these issues have been explored long before • Server: A server is any entity running the
the advent of modern distributed computer systems, Ripple Server software (as opposed to the
via a problem known as the “Byzantine Generals Ripple Client software which only lets a user
Problem” [2]. In this problem, a group of generals send and receive funds), which participates in
each control a portion of an army and must the consensus pro- cess.
coordinate an attack by sending messengers to each
• Ledger: The ledger is a record of the amount
other. Because the gener- als are in unfamiliar and of currency in each user’s account and
hostile territory, messengers may fail to reach their represents the “ground truth” of the network.
destination (just as nodes in a distributed network may The ledger is repeatedly updated with transactions
fail, or send corrupted data in- stead of the intended that success- fully pass through the consensus
message). An additional aspect of the problem is that process.
some of the generals may be traitors, either
individually, or conspiring together, and so messages • Last-Closed Ledger: The last-closed ledger is
may arrive which are intended to create a false plan the most recent ledger that has been ratified by the
that is doomed to failure for the loyal gener- als (just consensus process and thus represents the
as malicious members of a distributed system may current state of the network.
attempt to convince the system to accept fraudulent
transactions, or multiple versions of the same truthful • Open Ledger: The open ledger is the current
operating status of a node (each node maintains
transaction that would result in a double-spend). Thus
its own open ledger). Transactions initiated by
end users of a given server are applied to the open
ledger of that server, but transactions are not previous work has included extensions to cases where all
con- sidered final until they have passed through participants in the network are not known ahead of time,
the consensus process, at which point the open where the messages are sent asynchronously (there is
ledger becomes the last-closed ledger. no bound on the amount of time an individual node
will take to reach a decision), and where there is a
• Unique Node List (UNL): Each server, s, delineation between the notion of strong and weak
main- tains a unique node list, which is a set of
consensus.
other servers that s queries when determining
One pertinent result of previous work on consen-
consen- sus. Only the votes of the other
sus algorithms is that of Fischer, Lynch, and Patterson,
members of the UNL of s are considered when
1985 [4], which proves that in the asynchronous case,
determining con- sensus (as opposed to every
non-termination is always a possibility for a consen-
node on the network). Thus the UNL represents a
sus algorithm, even with just one faulty process. This
subset of the network which when taken
introduces the necessity for time-based heuristics, to
collectively, is “trusted” by s to not collude in an
ensure convergence (or at least repeated iterations of
attempt to defraud the net- work. Note that this
non-convergence). We shall describe these heuristics for
definition of “trust” does not require that each
the Ripple Protocol in section 3.
individual member of the UNL be trusted (see
The strength of a consensus algorithm is usually
section 3.2).
measured in terms of the fraction of faulty processes
it can tolerate. It is provable that no solution to the
• Proposer: Any server can broadcast
transactions to be included in the consensus Byzantine Generals problem (which already assumes
process, and every server attempts to include synchronicity, and known participants) can tolerate more
every valid transaction when a new consensus than (n 1)/3 byzantine faults, or 33% of the network
round starts. During the consensus process, acting maliciously [2]. This solution does not,
however, only proposals from servers on the however, require verifiable authenticity of the
UNL of a server s are considered by s. messages delivered between nodes (digital signatures).
If a guarantee on the unforgeability of messages is
2.2 Formalization possible, algorithms ex- ist with much higher fault
We use the term nonfaulty to refer to nodes in the net- tolerance in the synchronous case.
work that behave honestly and without error. Conversely, Several algorithms with greater complexity have
a faulty node is one which experiences errors which may been proposed for Byzantine consensus in the asyn-
be honest (due to data corruption, implementation er- chronous case. FaB Paxos [5] will tolerate (n 1)/5
rors, etc.), or malicious (Byzantine errors). We reduce Byzantine failures in a network of n nodes, amounting
the notion of validating a transaction to a simple to a tolerance of up to 20% of nodes in the network
binary decision problem: each node must decide from colluding maliciously. Attiya, Doyev, and Gill [3] in-
the in- formation it has been given on the value 0 or 1. troduce a phase algorithm for the asynchronous case,
As in Attiya, Dolev, and Gill, 1984 [3], we define which can tolerate (n 1)/4 failures, or up to 25% of
consensus according to the following three axioms: the network. Lastly, Alchieri et al., 2008 [6] present
BFT-CUP, which achieves Byzantine consensus in the
1. (C1): Every nonfaulty node makes a decision in asynchronous case even with unknown participants, with
finite time the maximal bound of a tolerance of (n 1)/3 failures,
2. (C2): All nonfaulty nodes reach the same deci- but with additional restrictions on the connectivity of
sion value the underlying network.
3. (C3): 0 and 1 are both possible values for all
non- faulty nodes. (This removes the trivial 2.4 Formal Consensus Goals
solution in which all nodes decide 0 or 1 Our goal in this work is to show that the consensus
regardless of the information they have been algorithm utilized by the Ripple Protocol will achieve
presented). consensus at each ledger-close (even if consensus is
the trivial consensus of all transactions being rejected),
2.3 Existing Consensus Algorithms and that the trivial consensus will only be reached
There has been much research done on algorithms that with a known probability, even in the face of Byzantine
achieve consensus in the face of Byzantine errors. failures.
This
Since each node in the network only votes on on a transaction. All transactions that meet this
proposals from a trusted set of nodes (the other nodes requirement are applied to the ledger, and that
in its UNL), and since each node may have differing ledger is closed, becoming the new last-closed
UNLs, we also show that only one consensus will be ledger.
reached amongst all nodes, regardless of UNL
membership. This goal is also referred to as 3.2 Correctness
preventing a “fork” in the network: a situation in In order to achieve correctness, given a maximal amount
which two disjoint sets of nodes each reach consensus of Byzantine failures, it must be shown that it is im-
independently, and two different last-closed ledgers possible for a fraudulent transaction to be confirmed
are observed by nodes on each node-set. during consensus, unless the number of faulty nodes
Lastly we will show that the Ripple Protocol can exceeds that tolerance. The proof of the correctness of
achieve these goals in the face of (n 1)/5 failures, the RPCA then follows directly: since a transaction is
which is not the strongest result in the literature, but only approved if 80% of the UNL of a server agrees
we will also show that the Ripple Protocol possesses with it, as long as 80% of the UNL is honest, no fraud-
several other desirable features that greatly enhance its ulent transactions will be approved. Thus for a UNL
utility. of n nodes in the network, the consensus protocol will
maintain correctness so long as:
3. Ripple Consensus Algorithm
f  (n 1)/5 (1)
The Ripple Protocol consensus algorithm (RPCA), is
applied every few seconds by all nodes, in order to main- where f is the number Byzantine failures. In fact, even
tain the correctness and agreement of the network. in the face of (n 1)/5 + 1 Byzantine failures, correct-
Once consensus is reached, the current ledger is ness is still technically maintained. The consensus pro-
considered “closed” and becomes the last-closed cess will fail, but it will still not be possible to confirm
ledger. Assum- ing that the consensus algorithm is a fraudulent transaction. Indeed it would take (4n +
successful, and that there is no fork in the network, the 1)/5 Byzantine failures for an incorrect transaction to be
last-closed ledger maintained by all nodes in the con- firmed. We call this second bound the bound for
network will be identical. weak correctness, and the former the bound for strong
correct- ness.
3.1 Definition It should also be noted that not all “fraudulent” trans-
The RPCA proceeds in rounds. In each round: actions pose a threat, even if confirmed during consen-
sus. Should a user attempt to double-spend funds in
• Initially, each server takes all valid transactions two transactions, for example, even if both
it has seen prior to the beginning of the
transactions are confirmed during the consensus
consensus round that have not already been
process, after the first transaction is applied, the
applied (these may include new transactions
second will fail, as the funds are no longer available.
initiated by end- users of the server, transactions
This robustness is due to the fact that transactions are
held over from a previous consensus process,
applied deterministically, and that consensus ensures
etc.), and makes them public in the form of a list
that all nodes in the network are applying the
known as the “candidate set”.
deterministic rules to the same set of transactions.
• Each server then amalgamates the candidate For a slightly different analysis, let us assume that
sets of all servers on its UNL, and votes on the the probability that any node will decide to collude
veracity of all transactions. and join a nefarious cartel is pc. Then the probability
of correctness is given by p⇤, where:
• Transactions that receive more than a minimum
d( n 5 1 )e ✓ ◆
percentage of “yes” votes are passed on to the next n
round, if there is one, while transactions that do

p = Â i p (1c pc)
i n i
(2)
i=0
not receive enough votes will either be
discarded, or included in the candidate set for
the beginning
of the consensus process on the next
ledger.
The final round of consensus requires a minimum
• This probability represents the likelihood that the size
percentage of 80% of a server’s UNL agreeing of the nefarious cartel will remain below the maximal
threshold of Byzantine failures, given pc. Since this
likelihood is a binomial distribution, values of pc
greater than 20% will result in expected cartels of size
greater than 20% of the network, thwarting the
consensus pro- cess. In practice, a UNL is not chosen
randomly, but rather with the intent to minimize pc.
Since nodes are not anonymous but rather
cryptographically identifiable, selecting a UNL of nodes
from a mixture of continents, nations, industries,
ideologies, etc. will produce values of pc much lower
than 20%. As an example, the proba- bility of the
Anti-Defamation League and the Westboro Baptist
Church colluding to defraud the network, is cer- tainly
much, much smaller than 20%. Even if the UNL has a
relatively large pc, say 15%, the probability of
correctness is extremely high even with only 200
nodes in the UNL: 97.8%. Figure 2. An example of the connectivity required to
A graphical representation of how the probability prevent a fork between two UNL cliques.
of incorrectness scales as a function of UNL size for
differ- ing values of pc is depicted in Figure 1. Note
that here the vertical axis represents the probability of a prove agreement is given by:
nefarious cartel thwarting consensus, and thus lower 1
values indi- cate greater probability of consensus |UNLi \UNL j | max(|UNLi|, |UNLj|)8i, j (3)
success. As can be seen in the figure, even with a pc as 5
high as 10%, the probability of consensus being This upper bound assumes a clique-like structure of
thwarted very quickly becomes negligible as the UNL UNLs, i.e. nodes form sets whose UNLs contain other
grows past 100 nodes. nodes in those sets. This upper bound guarantees that
no two cliques can reach consensus on conflicting
trans- actions, since it becomes impossible to reach the
3.3 Agreement
80% threshold required for consensus. A tighter
To satisfy the agreement requirement, it must be
bound is possible when indirect edges between UNLs
shown that all nonfaulty nodes reach consensus on the
are taken into account as well. For example, if the
same set of transactions, regardless of their UNLs.
structure of the network is not clique-like, a fork
Since the UNLs for each server can be different,
becomes much more difficult to achieve, due to the
agreement is not inherently guaranteed by the
greater entanglement of the UNLs of all nodes.
correctness proof. For example, if there are no
restrictions on the member- ship of the UNL, and the It is interesting to note that no assumptions are made
size of the about the nature of the intersecting nodes. The
⇤ UNL is not larger than 0.2 ntotal where ntotal intersec- tion of two UNLs may include faulty nodes,
is the number of nodes in the entire network, then a
fork is possible. This is il- lustrated by a simple but so long as the size of the intersection is larger than
example (depicted in figure 2): imagine two cliques the bound required to guarantee agreement, and the
within the total number of faulty nodes is less than the bound
⇤ UNL graph, each larger than 0.2 ntotal. By required to satisfy strong correctness, then both
cliques, we mean a set of nodes where each node’s
UNL is the selfsame set of nodes. Because these two correctness and agreement will be achieved. That is to
cliques do not share any members, it is possible for say, agreement is dependent solely on the size of the
each to achieve a correct consensus independently of intersection of nodes, not on the size of the
each other, violating agreement. If the connectivity of intersection of nonfaulty nodes.

the two cliques surpasses 0.2 ntotal, then a fork is no
longer possible, as disagreement be- tween the cliques 3.4 Utility
would prevent consensus from being reached at the While many components of utility are subjective, one
80% agreement threshold that is required. that is indeed provable is convergence: that the
consen- sus process will terminate in finite time.
An upper bound on the connectivity required to
Figure 1. Probability of a nefarious cartel being able to thwart consensus as a function of the size of the UNL,
for different values of pc, the probability that any member of the UNL will decide to collude with others. Here,
lower values indicate a higher probability of consensus success.

3.4.1 Convergence
Since the consensus algorithm itself is deterministic,
We define convergence as the point in which the and has a preset number of rounds, t, before consensus
RPCA reaches consensus with strong correctness on the is terminated, and the current set of transactions are
ledger, and that ledger then becomes the last-closed de- clared approved or not-approved (even if at this
ledger. Note that while technically weak correctness point no transactions have more than the 80% required
still represents convergence of the algorithm, it is only agree- ment, and the consensus is only the trivial
convergence in the trivial case, as proposition C3 is consensus), the limiting factor for the termination of
violated, and no transactions will ever be confirmed. the algorithm is the communication latency between
From the results above, we know that strong correctness nodes. In order to bound this quantity, the response-
is always achiev- able in the face of up to (n 1)/5 time of nodes is monitored, and nodes who’s latency
Byzantine failures, and that only one consensus will grows larger than a preset bound b are removed from
be achieved in the entire network so long as the UNL- all UNLs. While this guarantees that consensus will
connectedness con- dition is met (Equation 3). All that terminate with an upper bound of tb, it is important to
remains is to show that when both of these conditions note that the bounds described for correctness and
are met, consensus is reached in finite time. agreement above must be met by the final UNL,
after all nodes that will be
dropped have been dropped. If the conditions hold for to publish a “partial
the initial UNLs for all nodes, but then some nodes
are dropped from the network due to latency, the
correctness and agreement guarantees do not
automatically hold but must be satisfied by the new set
of UNLs.
3.4.2 Heuristics and Procedures
As mentioned above, a latency bound heuristic is en-
forced on all nodes in the Ripple Network to guarantee
that the consensus algorithm will converge. In addi-
tion, there are a few other heuristics and procedures
that provide utility to the RPCA.

• There is a mandatory 2 second window for all


nodes to propose their initial candidate sets in
each round of consensus. While this does intro-
duce a lower bound of 2 seconds to each
consen- sus round, it also guarantees that all
nodes with reasonable latency will have the
ability to partici- pate in the consensus process.

• As the votes are recorded in the ledger for each


round of consensus, nodes can be flagged and
removed from the network for some common,
easily-identifiable malicious behaviors. These
in- clude nodes that vote “No” on every
transaction, and nodes that consistently propose
transactions which are not validated by
consensus.

• A curated default UNL is provided to all users,


which is chosen to minimize pc, described in
sec- tion 3.2. While users can and should select
their own UNLs, this default list of nodes
guarantees that even naive users will participate
in a consen- sus process that achieves
correctness and agree- ment with extremely high
probability.

• A network split detection algorithm is also em-


ployed to avoid a fork in the network. While
the consensus algorithm certifies that the
transac- tions on the last-closed ledger are
correct, it does not prohibit the possibility of
more than one last- closed ledger existing on
different subsections of the network with poor
connectivity. To try and identify if such a split
has occurred, each node monitors the size of the
active members of its UNL. If this size suddenly
drops below a preset threshold, it is possible that
a split has occurred. In order to prevent a false
positive in the case where a large section of a
UNL has temporary latency, nodes are allowed
validation”, in which they do not process or Asynchronous Byzantine consensus, do
vote on transactions, but declare that are still
partic- ipating in the consensus process, as
opposed to a different consensus process on a
disconnected subnetwork.

While it would be possible to apply the RPCA •


in just one round of consensus, utility can be
gained through multiple rounds, each with an
increas- ing minimum-required percentage of
agreement, before the final round with an 80%
requirement. These rounds allow for detection
of latent nodes in the case that a few such
nodes are creating a bottleneck in the
transaction rate of the network. These nodes
will be able to initially keep up dur- ing the
lower-requirement rounds but fall behind and
be identified as the threshold increases. In the
case of one round of consensus, it may be the
case that so few transactions pass the 80%
threshold, that even slow nodes can keep up,
lowering the transaction rate of the entire
network.

4. Simulation Code
The provided simulation code demonstrates a round
of RPCA, with parameterizable features (the number
of nodes in the network, the number of malicious nodes,
la- tency of messages, etc.). The simulator begins in
perfect disagreement (half of the nodes in the network
initially propose “yes”, while the other half propose
“no”), then proceeds with the consensus process,
showing at each stage the number of yes/no votes in the
network as nodes adjust their proposals based upon the
proposals of their UNL members. Once the 80%
threshold is reached, consensus is achieved. We
encourage the reader to ex- periment with different
values of the constants defined at the beginning of
“Sim.cpp”, in order to become familiar with the
consensus process under different conditions.

5. Discussion
We have described the RPCA, which satisfies the
con- ditions of correctness, agreement, and utility
which we have outlined above. The result is that the
Ripple Pro- tocol is able to process secure and
reliable transactions in a matter of seconds: the length
of time required for one round of consensus to
complete. These transactions are provably secure up
to the bounds outlined in sec- tion 3, which, while not
the strongest available in the literature for
allow for rapid convergence and flexibility in network [4]
Fischer, Michael J., Nancy A. Lynch, and Michael
membership. When taken together, these qualities allow S. Paterson. “Impossibility of distributed consensus
the Ripple Network to function as a fast and low-cost with one faulty process.” Journal of the ACM (JACM)
global payment network with well-understood 32.2 (1985): 374-382.
security and reliability properties. [5]
Martin, J-P., and Lorenzo Alvisi. “Fast byzan-
While we have shown that the Ripple Protocol is
tine consensus.” Dependable and Secure
provably secure so long as the bounds described in equa-
Computing, IEEE Transactions on 3.3 (2006): 202-
tions 1 and 3 are met, it is worth noting that these are
215.
maximal bounds, and in practice the network may be
secure under significantly less stringent conditions. It
[6]
Alchieri, Eduardo AP, et al. “Byzantine consensus
is also important to recognize, however, that satisfying with unknown participants.” Principles of Distributed
these bounds is not inherent to the RPCA itself, but Systems. Springer Berlin Heidelberg, 2008. 22-40.
rather requires management of the UNLs of all users.
The default UNL provided to all users is already suffi-
cient, but should a user make changes to the UNL, it
must be done with knowledge of the above bounds. In
addition, some monitoring of the global network struc-
ture is required in order to ensure that the bound in
equation 3 is met, and that agreement will always be
satisfied.
We believe the RPCA represents a significant step
forward for distributed payment systems, as the low-
latency allows for many types of financial transactions
previously made difficult or even impossible with
other, higher latency consensus methods.

6. Acknowledgments
Ripple Labs would like to acknowledge all of the peo-
ple involved in the development of the Ripple Protocol
consensus algorithm. Specifically, Arthur Britto, for
his work on transaction sets, Jed McCaleb, for the
original Ripple Protocol consensus concept, and David
Schwartz, for his work on the “failure to agree is
agreement to de- fer” aspect of consensus. Ripple Labs
would also like to acknowledge Noah Youngs for his
efforts in preparing and reviewing this paper.

References
[1]
Nakamoto, Satoshi. “Bitcoin: A peer-to-peer elec-
tronic cash system.” Consulted 1.2012 (2008): 28.
[2]
Lamport, Leslie, Robert Shostak, and Marshall
Pease. “The Byzantine generals problem.” ACM
Transactions on Programming Languages and Sys-
tems (TOPLAS) 4.3 (1982): 382-401.
[3]
Attiya, C., D. Dolev, and J. Gill. “Asynchronous
Byzantine Agreement.” Proc. 3rd. Annual ACM
Symposium on Principles of Distributed
Computing. 1984.

You might also like