In this section, the taxonomy is described along with the process for building it.
4.2. Derivation of Dimensions
Seven dimensions are derived by their characteristics and are listed in the taxonomy of blockchain consensus methods (Table 3
). The dimensions are scarce resource, fault tolerance, block proposal, transaction finality, network timing, network accessibility, and network communication, as defined below.
Scarce Resource A resource that is difficult to replace, access, or create and thus scarce, accrues value as it is consumed or exploited. The potential for the growth of value is a motivation that encourages acceptable behaviour in the emergence of consensus. Six types of resource are identified.
Clock-cycles have non-zero cost, meaning the computational work done to find a hash value that is subject to a target requirement. The computational work cannot be recovered or undone. A cryptographic requirement is that the hash function is one-way, so the originating data cannot be inferred, but is easily verifiable.
Tokens held by a user may be committed to maintaining a protocol. PoS allocates users a stake in the system proportionate to their number of tokens. In general, tokens that are held as stake cannot be used in transactions. Honesty is encouraged by both advantaging nodes that validate transactions and create blocks at the risk of forfeiting their stake (slashing) for dishonest behaviour. A variation, DPoS, hands block production responsibility to a set of validators, or delegates, which are a subset of the network. Often the validators must be known to the network and thus subject to ridicule if they behave maliciously as in proof-of-authority.
are used to determine a majority and is a common method for gaining consensus with nearly half of the methods in Table 3
employing votes as the scarce resource. A BFT system must determine consensus by the replicas voting on the state. Votes have no tradable value and generally a node is permitted one vote per round, although an additional vote may be permitted in each subsequent round. Classical consensus methods that maintain state in a non-blockchain system, such as PBFT, use voting or a round-robin style to elect leaders.
represent the state of a transistor and occupy a finite amount of space in storage. PoCapacity methods allocate a user some stake in the system by requiring that a proportion of storage is kept aside. If the computer is a blockchain node, the allocation cannot be used for other purposes. PoMemory requires access to volatile storage; Ethash (Ethereum) commits a pseudorandom dataset to a DAG which grows linearly resulting in access that is limited by the memory bandwidth [18
]. Storage volumes tend to scale more slowly than computer processor clock-cycles and can reduce the domination of performance-enhanced processor architectures, such as Application Specific Integrated Circuits (ASICs).
Time is independent of computing advances. As clock-cycles and read/write times reduce, blockchains secured by these resources may be exposed to unforeseen factors. Thus, PoET processors provide additional execution environments or enclaves, that cannot be accessed by the system. These modules can return a random delay to a process that can then be used to assign block proposers.
Biometrics are a range of indicators that can verify identity or life. Similar to a PoW hash function requiring a known average number of clock-cycles, a blockchain based on proof-of-biometrics can require a unique biological solution. While biometrics are typically understood to be consistent parameters, such as facial, iris, voice, and fingerprint recognition systems, other systems may include affordances available only to humans or to specific humans. To be successful, such a system must be easy to use, require minimal input, and validate or authenticate rapidly. For example, the Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) system is easy for humans to solve but difficult for a computer.
Fault Tolerance At the base level, fault tolerance refers to crash-fault tolerance where a node can fail and will resume operation once it has been brought back online. These nodes cannot exhibit arbitrary behaviour, such as sending faulty information and so if a single node becomes compromised, the entire system is compromised. Consensus requires a majority of nodes—for example, with 2PC up to c nodes can crash, requiring replicas. Systems, such as Google’s Bigtable, are guaranteed five replicas and can tolerate two failures. If the replicas can be subverted and send incorrect information the system must be Byzantine-fault tolerant. PBFT and its derivatives can handle up to f Byzantine faults of replicas.
are integers; whereas for a proofing type method, fault tolerance is the percentage of total resource that may be sacrificed before consensus is lost. P2p systems assume bad actors will attempt to subvert the network, possibly colluding with each other, and may only be held off for as long as there is an honest majority. A 51% attack occurs when adversaries obtain >50% control of the scarce resource and can then alter, control, predetermine, or direct the consensus process. The selfish mining strategies of [31
] have shown that an actor with <50% can withhold blocks and earn more of the reward; however, this does not affect liveness or safety.
The question of who gets to propose new blocks (Figure 1
) is fundamental to consensus. Selecting a validator must be fair and secure. A decentralised open system allows any participant the opportunity to propose blocks and a fair way to accomplish this is by random selection. If peers do not find out who proposed the block until after it is proposed, this is a leader-free scenario. Leader election can also be accomplished by using randomized processes at which point the lead replica is responsible for coordinating the subsequent update. These systems are usually private as replicas require known IDs. A committee-based system relies on a predetermined set of validators to be responsible for updates. Participants may join the network but not necessarily be part of the committee.
The exception occurs in the case of the DAG, in which no node is responsible or chosen for updates and there is no block proposer. A DAG links transactions in a similar manner to a blockchain with the exception that a graph node can have n outgoing verticies. A traditional family tree satisfies this condition; however, so does a PoW chain in the presence of n forks (not necessarily in consensus). With IOTA, the graph breadth continues to grow.
There are two approaches to determining a transaction is complete. The first is deterministic and guarantees the data are written and committed to the blockchain as soon as the block is posted. The second is probabilistic, where a transaction is confirmed with increasing probability as more blocks are added—e.g., with PoW. There is a chance that transactions are added to a fork of the chain that does not represent the most computational work. Over time the longest chain will emerge and forked blocks become orphaned. Bitcoin’s proof-of-work is often called Nakamoto
consensus because the more chain work that is done after a transaction is in a block, the more likely it is to be committed to the ledger. PoS systems, such as Ethereum’s Casper [32
] have checkpoints before which all data finality is probabilistic. After a checkpoint is reached, the transactions are finalised.
The timing considerations may be synchronous, asynchronous, or partially synchronous. Networks such as PoW and proof-of-capacity are generally considered synchronous because they are guaranteed to update the state upon completion of every round. What is not guaranteed is that every round will complete because there are no timing assumptions; the protocol will run as long as necessary to append a block. Recently it has been shown that Nakamoto consensus, operating in a dynamic participant pool maintains safety and liveness in bounded-delay networks [33
]. A fully asynchronous network has no known upper bound for message delivery. A limitation of 2PC is that it will stall if a message is delayed for an arbitrarily long amount of time [10
]. A partially synchronous model may employ timeouts, rules, learning algorithms, and predetermined hierarchies to resolve deadlocks.
Network Accessibility Categories for blockchain network access are public, private or a combination of the two. In a public network, anyone can join the network and participate, then leave the network without penalty. Most decentralised blockchains are public and so they need to be secured against Byzantine behaviour. Private blockchains require nodes to be validated and external participants may not be able to participate or view activity. Enterprise blockchains are typically private for a range of reasons, including efficiency and security. A consortium is comprised of a group of parties, such as financial institutions that share access to a network. The reasons for establishing a consortium vary and include common goals, sharing of resources, mutual agreement on consensus methods, development opportunities, and so on. Individual consensus methods, such as PoS, may have instantiations of different access types—for example PoS may be public as in Decred, or consortium as in EOS. Any public PoS system can be adapted for private use.
Nodes exchange transaction or block data via a range of network communication methods. A trusted setup requires nodes to validate each other through a key-exchange procedure or similar. Open p2p networks communicate via a gossip protocol flooding nearest-neighbours with information until all nodes are in agreement. Network Communication could be both point-to-point and peer-to-peer—for example, trusted channels can be built on top of a peer-to-peer network [34
In a few cases, the characteristics that identify methods in Table 3
are not exclusive but lead to a range of blockchain implementations. While there may be an argument for additional dimensions (such as performance, scalability, message complexity, etc.), the contribution is not sufficient to warrant their inclusion here. Performance criteria apply to specific cases: the Example Blockchains in Table 3
, or the Validation Cases in Table 4
; thus they are characteristics not only of the protocol but the implementation. For example, transactions per second (TPS) is often cited as a performance metric [2
]; Bitcoin and Litecoin both use PoW but utilise different hashing algorithms and due to design factors such as blocktime Bitcoin can handle ≈7 TPS, and Litecoin ≈56 TPS. These variations have not been included in Table 3
to keep the focus on consensus.