A permissioned Blockchain is a closed ecosystem where every participant is defined. This type of Blockchain allows us to create organizations or consortia of organizations to efficiently exchange information and a transaction history.
This time we will be analyzing the number of transactions per second that different Ethereum network clients can execute with different consensus algorithms.
Since distributed systems act independently when processing information (executing transactions) and updating state, there must be an indisputable agreement on the resulting states across the nodes. The process of reaching agreement between the states of the distributed nodes is called "Consensus"
Proof of Authority (PoA)
These are a family of consensus algorithms for permissioned networks whose importance stems from performance gains over classic BFT algorithms; this is because the messages exchanged are lighter. PoA was originally described as part of the Ethereum ecosystem for private networks and implemented in its clients Geth (Clique) and Parity (Aura).
These algorithms rely on a set of trusted nodes N called authorities. Each authority is identified by a unique id and the majority of them are assumed to be honest, that is, at least *N/2 +1.*The authorities reach consensus to order the transactions performed by the _clients._ These algorithms rely on a rotation scheme, a widely used approach to fairly distribute the responsibility of creating new blocks among the authorities.
The implementations of the Clique and Aura algorithms work differently: even though both have a first round where a new block is proposed by the current leader, Aura requires one more round of acceptance of a new block, while Clique does not.
Differences between Aura and Clique
Clique
Clique is an algorithm implemented in Geth, the Ethereum client written in Golang. This algorithm operates in epochs identified by a preset sequence in the blocks that have been accepted.
An example of a block in Clique would be:
>eth.getBlock(8);{ difficulty: '2',extraData: '0xd88301080a846765746888676f312e31302e32856c696e7578000000000000002dc51ef1f370d69954631ff07eaee75c1a01ebf2d87c6d8f88bdc709da1375425057e66ff6502110085c9d67b24d131709549451bea56889bb3fbd20611524bc01',gasLimit: 7500000,gasUsed: 0,hash: '0x55e7750bc3ee8762fe02602ab95dc510326eb2d1481e75e448823d582e949b7d',logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',miner: '0x0000000000000000000000000000000000000000',mixHash: '0x0000000000000000000000000000000000000000000000000000000000000000',nonce: '0x0000000000000000',number: 8,parentHash: '0x303edf0cfcb3f236c700b353c40a203c542214efbbd58b4eca454d8c6e39e415',receiptsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',sha3Uncles: '0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347',size: 606,stateRoot: '0x32064cb7f950941bc90d4180086dfb3c80cd85735fba994283bc0443a76aa4ac',timestamp: 1540831630,totalDifficulty: '17',transactions: [],transactionsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',uncles: [] }
In our internal tests we obtained the following statistics on the number of transactions per second that can be achieved; the tests were performed with 4 validator nodes and 2 client nodes.
To simulate real network behavior, a small piece of software was developed that could create a specific number of threads and send transactions to the 2 client nodes, resulting in a maximum of 134 transactions per second with at least 7 concurrent threads performing operations.
Transactions per second with Clique using multiple threads
Aura
Aura (authority round) is an algorithm implemented in Parity, the Ethereum client written in RUST. This algorithm assumes the network is synchronous and that all authorities synchronize within the same UNIX time t.
An example of a block in Aura would be:
> eth.getBlock(64);{ author: '0xad385c92a482c4926e650aa355ba66dc504f9f6f',difficulty: '340282366920938463463374607431768211446',extraData: '0xde830202008f5061726974792d457468657265756d86312e32382e30826c69',gasLimit: 9393937,gasUsed: 0,hash: '0x1915f964f61d9bd2debeec22c805ea4b5c8471b4453b65fa16d29ed14bd0c09e',logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',miner: '0xAd385c92a482C4926E650Aa355Ba66Dc504f9F6f',number: 64,parentHash: '0xb57b358a24ac7f87c0e2f5698755c2a961d2fa3f273b79325b58bfa4106b3122',receiptsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',sealFields:[ '0x845bd789c1','0xb8417415941a5671767ad29c67ea6d6464a743d9f6a79f0cdc009fb17d1503b2c2a50dfef77d5fdb966cbabb2fe2016fd49972fbc925bc9a218dc4ac9a31056c878f00' ],sha3Uncles: '0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347',signature: '7415941a5671767ad29c67ea6d6464a743d9f6a79f0cdc009fb17d1503b2c2a50dfef77d5fdb966cbabb2fe2016fd49972fbc925bc9a218dc4ac9a31056c878f00',size: 585,stateRoot: '0x877eb4dadd1eaf4dabd8ec51ebeff13dc3ca5338d91b8770ad67694fc4f6aae2',step: '1540852161',timestamp: 1540852161,totalDifficulty: '21778071482940061661655974875631624812031',transactions: [],transactionsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',uncles: [] }
In our internal tests we obtained the following statistics on the number of transactions per second that can be achieved; the tests were performed with 4 validator nodes and 2 client nodes.
To simulate real network behavior, a small piece of software was developed that could create a specific number of threads and send transactions to the 2 client nodes, resulting in a maximum of 37 transactions per second with at least 10 concurrent threads performing operations.
Transactions per second with Aura using multiple threads
Istanbul Byzantine Fault Tolerance (IBFT)
IBFT, an algorithm implemented in Quorum, is a modification of the practical Byzantine fault tolerance algorithm. In IBFT each block requires multiple rounds of voting by the set of validators to reach mutual agreement, which is recorded as a collection of signatures in the block's contents. A validator never assumes the "block proposer" is correct and honest. Instead, it verifies the proposed block just like other consensus algorithms that operate in an untrusted environment.
An example of a block in IBFT would be:
>quroum.getBlock(4043570);{ difficulty: '0x1',extraData: '0xd783010702846765746887676f312e392e35856c696e75780000000000000000f90179f869940211711f81d923f5e7f6037a48569951457aacbf9460749d2abbd6217521f02e3a786431be632303d094976c9455ad158eeb07b5599f7d9cbfd4ef4f80ca94b87dc349944cc47474775dde627a8a171fc9453294cd2de20ccf75025402ccab76f67c6b1556fe754ab84156e581e2c053d23be58a3734250ce37a48315978e3856e3a6f7a27f0f0a83469714681de57019f19785439d7523fbdbecfee5fdcb273f342648bb0e36c829f9800f8c9b8418205272aacde8061efe06a1d960a7a95c0eae87b7c69b9edce92928dc34938a80106fc8252cc356ce98e07acbaa72bfa7879b4c61dbeae45dd9b0f2aa206cfc800b8416c69045e237f83fd21215d66f13c215d3fa552819216cfa4d95960637ea9ac58665472be3f2a43c7279150357ab4c72bf4af85f6dea6eb7ba261609025f09a6701b841a1501c37163a894fe0fbb99921021cc5a1e3b60ae0f03f33ecce13b80a249df2055951758b149d3a32d2481c081f493574a53c79155158d78e7dd35e7728cda800',gasLimit: '0xffffffffffffffff',gasUsed: '0x0',hash: '0xc8e94b4ddd0a17ee5a053478b1837dc6a2f19e124d6e6c3601967e2ccf0792d7',logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',miner: '0x0000000000000000000000000000000000000000',mixHash: '0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365',nonce: '0x0000000000000000',number: '0x3db332',parentHash: '0x38d931d074689613e39fe5d3f6a388d0c5ef9a5ec09a86a3cb13f05d4a3f567a',receiptsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',sha3Uncles: '0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347',size: '0x3a2',stateRoot: '0xf7f86b47e3e0b2e790a0f60039ec2b2af66d311aab6c9343d93040b4599878cc',timestamp: '0x5bd87a6b',totalDifficulty: '0x3db333',transactions: [],transactionsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',uncles: [] }
In our internal tests we obtained the following statistics on the number of transactions per second that can be achieved; the tests were performed with 4 validator nodes and 2 client nodes.
To simulate real network behavior, a small piece of software was developed that could create a specific number of threads and send transactions to the 2 client nodes, resulting in a maximum of 281 transactions per second and an average of 200 with at least 10 concurrent threads performing operations.
Transactions per second with IBFT using multiple threads
Raft
Raft is an algorithm implemented in Quorum; it is a well-known consensus algorithm developed by researchers at Stanford University, and it has been implemented in different distributed computing frameworks such as Kubernetes, Docker Swarm, etc.
Raft, unlike BFT, assumes the leader always acts honestly; all followers blindly replicate the blocks proposed by the leader without asking questions. If the leader node disappears, the network will automatically elect a new one after a set period of time and keep running.
An example of a block in Raft would be:
> quorum_raft.getBlock(7);
{ difficulty: '0x20000',extraData: '0x',gasLimit: '0xdf9e16e9',gasUsed: '0x5208',hash: '0x908f41b9d76cd097299163a674d03bc87c35662d1c1c68a4c9c00214bea6efca',logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',miner: '0x0000000000000000000000000000000000000000',mixHash: '0x0000000000000000000000000000000000000000000000000000000000000000',nonce: '0x0000000000000000',number: '0x7',parentHash: '0x943c3406c5c48a8d34321ba17d95959c64e8b87bf404c09c0f59dfde10aee482',receiptsRoot: '0x056b23fbba480696b65fe5a59b8f2148a1299103c4f57df839233af2cf4ca2d2',sha3Uncles: '0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347',size: '0x269',stateRoot: '0x79979cf33ad85dfdd6a63c3d364078b2ee95ad029c7284ca4e1a5bf17b024ee7',timestamp: '0x156047ff0485a040',totalDifficulty: '0xe0000',transactions:[ '0x984bfd066f2d7b9d2d5056477da3e0213d99904930db1484e0c5bd9eea3d317a' ],transactionsRoot: '0x85abd103660f4b2634a1c9d7657ef2ba4e2c41012c74cdc2bbfa43485c2babea',uncles: [] }BlockInfo {Block: '0x7',Block_Tx: 1,LastBlock: 1,TPS_Last_TwoBlock: 1,TPS_Media: 0.6666666666666666,TotalTransactions: 2 }
In our internal tests we obtained the following statistics on the number of transactions per second that can be achieved.
To simulate real network behavior, a small piece of software was developed that could create a specific number of threads and send transactions to the 2 client nodes, resulting in a maximum of 141 transactions per second with at least 10 concurrent threads performing operations.
Transactions per second with Raft using multiple threads
Conclusions
After studying the most widely used clients and consensus algorithms for creating permissioned networks on Ethereum, we can conclude that the winner in terms of transactions per second is Quorum with the IBFT consensus algorithm; however, this project receives few updates and the list of issues with its client grows every day.
References
-
Miguel Castro and Barbara Liskov. Practical Byzantine Fault Tolerance.
-
Stefano De Angelis, Leonardo Aniello. PBFT vs Proof-of-Authority: Applying the CAP Theorem to Permissioned Blockchain.
-
BitFury Group and J. Garzik. Public versus private blockchains.
-
Raft. https://raft.github.io/