Journal article · 2023
Improving Trust in a (Trans)National Invoicing System: The Performance of Crash vs. Byzantine Fault Tolerance at Scale
Summary
A shared invoicing ledger for businesses and government needs every participant to agree on what happened. Systems can be built to survive nodes that crash (crash fault tolerance) or nodes that lie or misbehave (Byzantine fault tolerance). The second gives more trust, but agreement takes more work.
We sized the problem with real volumes. Denmark exchanges roughly 230 million B2B and B2G invoices a year, and about five related documents travel with each one. That adds up to more than a billion transactions a year and peaks of around 130–135 transactions per second. For the EU plus the UK, the peak rises to 9,000–10,000 per second.
We then tested two Byzantine fault tolerant blockchains (Quorum and Tendermint), a crash fault tolerant one (Hyperledger Fabric) and a plain streaming platform (Apache Kafka) under realistic conditions: 28 nodes spread over five European cloud regions, invoice-sized messages and commodity hardware.
Explainer
Key findings
- The Byzantine fault tolerant blockchains can carry a national system the size of Denmark's, but they fall far short of what an EU-wide system would need.
- On average, Apache Kafka was roughly 300 times faster than Quorum, 440 times faster than Hyperledger Fabric and 650 times faster than Tendermint on the same hardware.
- Hyperledger Fabric performed very differently from Kafka on its own, even though it uses Kafka for ordering.
- Decentralised trust has a measurable performance cost, so designers should ask whether participants who already know each other really need it.
How to cite
Søgaard, J. S., Eklund, P. W., Herskind, L., & Spasovski, J. (2023). Improving Trust in a (Trans)National Invoicing System: The Performance of Crash vs. Byzantine Fault Tolerance at Scale. Applied Sciences, 13(12), 6941. https://doi.org/10.3390/app13126941