TThe DCS Theorem
Greg Slepak [email protected]
Anya Petrova [email protected]
October 4, 2017
Abstract.
Blockchain design involves many tradeoffs, and much debatehas focused on tradeoffs related to scaling parameters such as blocksize.To address some of the confusion around this subject, we present a prob-ability proof of the
DCS Triangle [1][2]. We use the triangle to showdecentralized consensus systems, like blockchains, can have
Decentraliza-tion , Consensus , or
Scale , but not all three properties simultaneously. Wethen describe two methods for getting around the limitations suggestedby the triangle. A system is defined as any set of components (see Decentralization Scope) fol-lowing precise rules in order to provide service(s) to the users of the system.These services constitute the system’s intended behavior .In other words, a system 𝑆 consists of a set of components, called its scope {𝑆} , and a program (“state transition function”, 𝑓 𝑆 ), that together define thesystem’s intended behavior , which means: upon receipt of message 𝑚 , 𝑆 uses 𝑓 𝑆 to update the internal state from 𝑠 to 𝑠 ′ and send back reply 𝑦 within a timeinterval 𝑆 𝜏 . 𝑆(𝑡) = { {𝑆} = {𝑐𝑜𝑚𝑝𝑜𝑛𝑒𝑛𝑡 , 𝑐𝑜𝑚𝑝𝑜𝑛𝑒𝑛𝑡 , ⋯}𝑓 𝑆 (𝑚, 𝑠) = {𝑠 ′ , 𝑦} We note, additionally:• The scope {𝑆} may change over time, but there are always several compo-nents of a vital type (i.e. “all systems always have at least one
CPU , one developer , and one user ”).• The system’s state 𝑠 includes all data necessary for the system to compute 𝑓 𝑆 given a message 𝑚 . The system may limit messages to those that are1uthorized in some way (in order to prevent denial-of-service). • 𝑆 is considered compromised if it fails to perform its intended behaviorwithin the interval 𝑆 𝜏 .We will proceed to prove that any single such system may possess, at most, twoof three properties: Consensus Scale Decentralized• Consensus means the system uses a collective decision-making process(“consensus algorithm”) to update the system’s state, 𝑠 , which is sharedby all consensus participants . The result of the consensus algorithm de-termines the network’s accepted output of 𝑓 𝑆 , and whether or not 𝑓 𝑆 completes within 𝑆 𝜏 .• Scale means the system is capable of handling the transactional demandsof any competing system providing the same service to the same arbitraryset of users across the globe ( “at scale” ). • Decentralized means the system has no single point of failure or control (SPoF). Another way to state this is: if any single element is removed from {𝑆} , the system continues to perform its intended behavior, and no singlecomponent in {𝑆} has the power to redefine 𝑓 𝑆 on its own. The concept of a “consensus participant” is sometimes confused with the conceptof a “validator”, and in order to understand what the DCS Triangle is sayingit’s necessary to understand the difference between the two.Every consensus process has three ingredients: voters (consensus participants),voting rules, and the votes themselves.In distributed systems, the job of a validator is to verify that the voting ruleswere followed, accepting the outcome of the vote if that is so, and rejecting theoutcome otherwise. For example, in the physical world a validator might beresponsible for verifying ballot forms were filled out correctly and were cast by For decentralized systems, this is okay as long as there is no central authority determiningwho is or isn’t authorized. Examples of “services” include: streaming video, sending messages, maintaining balanceson a ledger, etc.
Definition.
𝐶𝑜𝑛𝑠𝑒𝑛𝑠𝑢𝑠 𝑝𝑎𝑟𝑡𝑖𝑐𝑖𝑝𝑎𝑛𝑡𝑠 are independent entities who each main-tain a complete copy of a system’s state, and together vote on updates to thisshared state.The notion of a “complete copy of a system’s state” is of utmost importancefor our proof. In other words, our proof focuses specifically on the strongestnotion of “consensus”, where each consensus participant has full knowledge ofthe entire system state, and therefore is able to cast a vote without needing totrust any other participant.To emphasize this notion of consensus over weaker forms, we’ll refer to it as full consensus in our theorem.In §3 - Getting around the DCS Triangle , we’ll explore how, by loosening thisrequirement and treating “consensus” as a spectrum of trust assumptions, itmay be possible to design decentralized consensus systems that scale with “good-enough-consensus”. scope & relativity Implicit to our definition of a decentralized system is the idea that the systemis not compromised. A non-functioning system does not fulfill its intendedbehavior, and therefore, by our definition, is not decentralized.Imagine a decentralized system 𝑆 , whose intended behavior (its purpose) is tomaintain the integrity of a database while being responsive to queries. It doesso by attempting to eliminate all single points of failure within a given scope. Definition.
The 𝑠𝑐𝑜𝑝𝑒 of a system refers to all subcomponents and all entitiesreasonably relevant to a system’s functioning.If we consider the scope of our “decentralized” database to be a computer withtwo CPUs and two hard disks (one primary, another backup), then we can say 𝑆 is “decentralized” at 𝑡 = 0 (has no single point of failure). However, if at 𝑡 = 1 one of the hard disk fails, it is no longer decentralized since now theredoes exist a single component capable of compromising the entire system.3his means:• Whether or not a system is decentralized can change over time.• Any system can be called “decentralized” if we define the scope narrowlyenough.• All decentralized systems can be called “centralized” if we define theirscope broadly enough. The narrowing and enlarging of the scope is called the relativity of decentraliza-tion , and it is why first agreeing on a reasonable definition for a system’s scopeis vital before deciding whether or not it is “decentralized”.
Definition.
The 𝑐𝑜𝑚𝑝𝑢𝑡𝑎𝑡𝑖𝑜𝑛𝑎𝑙 𝑡ℎ𝑟𝑜𝑢𝑔ℎ𝑝𝑢𝑡 of a consensus system refers to therate at which the system updates its state by processing all input messages.We’ll use the shorthand
𝑇 (𝑆) to represent this concept and note three factorsthat determine its value:1. The computational power of each consensus participant.2. The amount of time after which the consensus algorithm considers mes-sages to be lost (the timeout period).3. The consensus threshold that decides when consensus has been reached(i.e. “how big of a quorum is required”).Note that if the computational power of a consensus participant is significantlyless than that of the other participants, they are more likely to be excluded fromthe deciding quorum for several reasons:• If there are no network partitions to determine otherwise, fast consensusparticipants will process messages more quickly and therefore will be firstto create a quorum.• If there are enough fast consensus participants to create a large enoughquorum to exceed the system’s consensus threshold, then there is no needto wait for the remaining votes of the slow participants.• Slow consensus participants are more likely than fast consensus partici-pants to hit the system’s timeout period for processing and respondingto messages, and therefore are more at risk of being excluded from theconsensus process entirely.Therefore, 𝑇 (𝑆) is a function that is limited by the slowest consensus partici-pants not excluded in the deciding quorum. The entire Internet could be considered centralized if we include the entire solar systemas part of the scope. The “single point of failure” could be the Earth itself, its atmosphere,the Sun, etc. Or, perhaps in the not distant future, a single ISP. This refers to all computational requirements relevant for consensus participation, such asbandwidth, data storage, and processing speed. .4 Coordination costs Relevant for our proof is the notion of coordination costs , or the difficulty forone entity to engage another and work toward a common goal, because that canresult in the formation of a cartel, which in turn violates the requirement thatconsensus participants be independent .For example, when Bitcoin was first launched, it would be difficult for anyminer to find enough collaborating miners to create a cartel with >50% ofthe hash power, simply because there were many “relevant miners” (consensusparticipants) distributed all over the world.Today, however, there are significantly fewer consensus participants in Bitcoin,and it is much easier to (1) identify them, and (2) bring them together tocoordinate around some goal. Therefore, we say the coordination costs arelower today than before.We can approximate the coordination costs
𝐶(𝑆) of any consensus system simplyas the number of consensus participants:
𝐶(𝑆) = num _ consensus _ participants ({𝑆}) Population of potential users
Users of 𝑆 Consensus participants
Fig. 1: If 𝑆 is a decentralized consensus system, the DCS Theorem states that as the numberof users increases (red circle), the number of consensus participants decreases (green circle). Theorem 1.
Decentralized consensus systems centralize at scale when consen-sus participants maintain full consensus over the entire state of the system.
5e begin with the following axioms accepted as true:
Axiom 1.
In any sufficiently large population (at scale), individual access tocomputational power is distributed unequally. Most have access to average com-putational power, and a few have access to large amounts.
Justification: empirically true.
Axiom 2.
For any two systems offering the same service to the same largepopulation, the transactional demands of the average user converge at scale.
Justification: follows from central limit theorem and the law of large numbers.
Axiom 3.
Most users of a system do not have the computational power requiredto store and process all of the messages generated by all of the users of that systemat scale.
Justification: empirically true. From those axioms, we derive the following lemmas:
Lemma 1.
Let 𝑆 be a decentralized consensus system whose consensus partic-ipants maintain full consensus over the system’s state. Let 𝑇 (𝑆) refer to itscomputational throughput and 𝑐 refer to the average computational power of allhistorical consensus participants at any relevant instant in time. At scale, 𝑇 (𝑆) exceeds 𝑐 , and the more users 𝑆 obtains, the more 𝑇 (𝑆) exceeds 𝑐 . slow fastThroughput capability u s e r s w i t h c a p a b ili t y Fig. 2:
Visualization of (Axiom 1).
Proof.
This follows directly from Axiom 1, 3, and our definition of a decentral-ized system, which includes the understanding that for a system to be considered And perhaps provably true, though such a proof is beyond the scope of this paper. messages from new users within some interval 𝑆 𝑡 . Forit to do this, 𝑇 (𝑆) must exceed 𝑐 , per (Axiom 1) and (Axiom 3). Lemma 2.
Let 𝑆 be a consensus system as in (Lemma 1). The coordinationcosts for 𝑆 , 𝐶(𝑆) , decrease at scale.Proof.
This follows directly from our proof for (Lemma 1) and our definitionof
𝐶(𝑆) . The more 𝑆 scales, the more 𝑇 (𝑠) exceeds 𝑐 , and the fewer potentialconsensus participants are able to participate in consensus. This, in turn, makesit easier for the remaining consensus participants to identify and coordinate witheach other. Lemma 3.
Let 𝑆 be a consensus system as in (Lemma 1). The probability that {𝑆} contains a colluding group capable of censoring transactions increases atscale, and therefore 𝑆 tends toward centralization at scale.Proof of the Main Theorem. The final lemma restates our original theorem. Ascoordination costs decrease (Lemma 2), the probability of a colluding group(a cartel) increases. The presence of a cartel capable of controlling consensusrepresents a single point of failure capable of preventing the system from fulfillingits intended purpose. The definition of a centralized system is one that hasa single point of failure. Therefore, we’ve shown that the probability of theinitially decentralized system becoming centralized increases at scale.It is also worth considering our definition of scale and the implications of (Ax-iom 2). Per (Axiom 2), when a decentralized consensus system 𝑆 scales to thesize of a similar centralized consensus system 𝑆 , it will experience the sametransactional demands as 𝑆 . However, 𝑆 may scale to a size that would guar-antee cartel formation in 𝑆 if it were to scale to the same size. Therefore, 𝑆 cannot scale to such a size while remaining decentralized, and therefore 𝑆 cannot satisfy our definition of scale. As mentioned, the DCS triangle applies to systems employing “full consensus”,or in other words, when all consensus participants are required to fully andindependently verify the entire state of the system.It may be possible to “get around” the DCS Triangle by relaxing our definitionof consensus. In this section we’ll consider two such approaches. See footnote 1 on page 1. .1 Combining DC and DS systems Let us suppose we have a DC-system that we wish to scale while preserving itsdecentralization. An example of such a system is Bitcoin.[3]Per the triangle, we know that increasing the system’s throughput,
𝑇 (𝑆) , viaany mechanism that requires all consensus participants to process the additionaldata, will result in a reduction in the number of independent consensus partici-pants. And so, instead, we may choose to pair our DC-system with a DS-systemin some clever way. D S C + C S D
Our DS-system will give us the scale we’re looking for, while our DC-systemprovides a stable and secure source of “ultimate truth” on an as-needed basis.We can connect the two systems in such a way that our DS-system only requiresconsensus in rare moments, and when it does it may communicate with our DC-system.The Lightning Network[4] is a real-world example of such a pairing.
Yet another possibility is to combine multiple DC systems to create a super-system of DC groups .This approach explores a middle-ground within the DCS triangle, and is theapproach taken by systems like OmniLedger.[5]Consensus Scale DecentralizedAlso known as sharding, each group (or shard ) of consensus participants nolonger has complete knowledge of the entire system state, and therefore must(at least partially) trust the other consensus groups. Transparency techniques,8uch as merkle tree logs, make it possible to minimize the amount of “faith”groups must place in each other.Overall system consensus is progressively “sacrificed” as the system scales, butonly in small, manageable increments. If the system does not need much inter-group consensus, it can scale significantly without issue. If necessary, a DS-system can be added for additional scale.
Thanks to Trent McConaghy and Andrea Devers for their feedback.
References [1] T. McConaghy, “The DCS Triangle,” 10-Jul-2016. https://medium.com/the-bigchaindb-blog/the-dcs-triangle-5ce0e9e0f1dc .[2] G. Slepak, “Slepak’s Triangle,”
Rebooting Web-of-Trust , 17-Oct-2016. https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/Slepaks-Triangle.pdf .[3] S. Nakamoto, “Bitcoin: A Peer-to-peer Electronic Cash System.” Oct-2008. https://bitcoin.org/bitcoin.pdf .[4] J. Poon and T. Dryja, “The Bitcoin Lightning Network: Scalable Off-ChainInstant Payments,” 14-Jan-2016. https://lightning.network/lightning-network-paper.pdf .[5] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, and B. Ford,“OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding,” 2017. https://eprint.iacr.org/2017/406.pdfhttps://eprint.iacr.org/2017/406.pdf