Protocol 2 records values one by one. When using state machine replication to implement a distributed service, the throughput is limited to one state update per solved puzzle instance. In order to allow the network to synchronize between recorded events, the average time between found solutions must be long compared to the maximum network delay∆. Thus, the overall throughput is very low.
One way around this limitation is to bundle multiple events in blocks and treat them as a single record. For that purpose, the environment facing part of the protocol can be modified to accumulate incoming requests. Nodes order incoming events locally, execute them, check for conflicts and put them into a temporary list. The puzzle is constantly updated to match the list. As soon as a puzzle solution is found, the block of events is broadcasted to the other nodes and the node starts to build a new block from scratch.
Algorithm 6 shows the necessary changes. In practice this would be combined with the changes introduced in section 6.2, but we skip this in order to avoid convolution.
In practice, the proposed protocol extension is accompanied by a second synchronisa- tion mechanism on the level of transactions or events. After receiving a transaction from the environment, honest nodes broadcast it to the rest of the network. This allows all nodes to include a transaction equally. Inclusion happens on the next few blocks in the network instead of the next block of the nodes that received the transaction from the environment.
Algorithm 5Modified consensus using a hash linked list
1: procedureinit
2: c←0 .candidate for extension
3: r← { } .records
4: l←0 .end of hash-list
5: extend ()
6: procedureextend
7: terminate other instances of extend
8: p←Solve (c, l) . call a competitive solving algorithm
9: h← H(c, l, p) 10: r[h]←(c, l, p) 11: l←h 12: send (c, l, p) 13: extend () 14: procedurerequest (x) 15: c←x 16: out (c :: read (r, l)) 17: extend () 18: procedurereceive(c0, l0, p0) 19: if Verif ((c0, l0), p0) then 20: h0 ← H(c0, l0, p0) 21: r[h0]←(c0, l0, p0) 22: s←read(r, l) 23: s0 ←read(r, h0) 24: if |s0|>|s|then 25: l←h0 26: extend () 27: functionread (r, h) 28: p←h . pointer 29: a←[ ] . accumulator 30: whiler[p]existsdo 31: (e, l,_)←r[p] 32: a←a::e 33: p←l 34: returna
Algorithm 6Consensus algorithm that accumulates events in blocks 1: procedureinit 2: b←[ ] .next block 3: h←[ ] .history 4: p←[ ] .proofs 5: extend () 6: procedureextend
7: terminate other instances of extend
8: s←Solve (h::b) . call a competitive solving algorithm
9: h←h::b 10: p←p::s 11: send (h, p) 12: c←[ ] 13: extend () 14: procedurerequest (x)
15: if x is transaction and does not conflict with hand b then
16: b←b::x
17: extend ()
18: else
19: out (h::b)
20: procedurereceive(h0, p0)
21: if valid (h0, p0) and|h0|>|h|then
22: h←h0
23: remove now invalid or duplicate transactions from b
24: extend ()
25: functionvalid (h, p)
26: if |h| 6=|p|then return⊥
27: fori∈[1,|h|]do
28: if Verif (h[1, . . . , i], p[i]) =⊥then return ⊥
29: if ∃ conflicting transaction inh then return⊥
Now that we know about blocks and hash-linking, we can also explain the term blockchain. The blocks are stored and distributed using hash-linked lists. We know that by changing one element of the list, we break the connection to all successors. The blocks, including the containing transactions are chained together. The order of blocks and the contained transactions cannot be changed without significant computational effort.
7
Discussion
7.1 ScalabilityWe have presented a protocol, that allows weakly identified nodes to reach consensus in a distributed manner. The only communication necessary is to send mined blocks to all participating nodes. Thus, the communication effort is linear in the number of nodes. This allows the protocol to be used on an internet scale and constitutes a major difference to classical Byzantine fault tolerant protocols, that typically requiren2 messages or more. On the other side of the coin stands the scalability of the application, that runs atop the consensus protocol.
We have seen in section 4, that the protocol’s security inherently depends on the puzzle’s hardness, which has to be chosen, such that the expected solving time is much bigger than the maximum network delay. Otherwise, an adversary is able to trick the honest players into extending superseded chains and wasting their solving power on irrelevant puzzles.
This requirement causes serious scalability issues. On the one hand, a small maximum network delay implies, that the blocks are small. Bigger blocks cause bigger messages, cause bigger latency, cause more margin for network layer attacks, that delay messages further. For this reason, the block size is typically bounded to a tolerable size in practical implementations. This bound in size naturally limits the number of recordable events per block. Hence, there is limited transaction throughput.
On the other hand, a small solving rate implies, that the time between found blocks is high. Events or transactions are recorded infrequently. Besides the limited throughput, there is also high latency. The latter is additionally affected by the security parameterl. The latency grows linear in the number of confirmations until a block is considered final. Overall, the presented protocol is scalable in the number of nodes, but not in the number of transactions. Additionally, the long confirmation time makes it unsuitable for some use cases.
There have been multiple attempts to improve on this aspect. Prominent examples are Bitcoin-NG [15] and Hybrid Consensus [27]. Bitcoin-NG was proposed by Eyal et al. [15]. Its main idea is to elect a single leader for some time span called epoch. During the epoch, the leader is responsible for ordering and recording transactions into so-called microblocks. The generation of microblocks happens at a fast rate, thereby increasing both latency and throughput.
Another approach is Hybrid Consensus as proposed by Pass and Shi [27]. It combines classical Byzantine fault tolerance protocols with the new blockchain paradigm. The goal is to benefit from the higher throughput and low latency of classical protocols while maintaining the scalability in the number of participating nodes. Therefore, the protocol is split into two phases. Firstly, a blockchain-like protocol is used to elect a committee. The committee inherits from the chain-quality property, that only a limited amount of its identified members are controlled by the adversary. In a second phase, the committee
executes a conventional Byzantine fault tolerant protocol. The actual application is build atop this latter protocol and thus independent from the previously mentioned scalability issues.