Byzantine Fault Tolerance is a dogma in blockchain

Defence in depth diminishes its necessity in many applications

Byzantine Fault Tolerance (BFT) is a bit of dogma, rather than a fundamental requirement for all blockchains. Let’s review a quadrant chart to articulate differences in consensus and deployment approaches.

Quadrant chart by author

BFT is an absolute requirement in public, unpermissioned blockchain solutions. Highly robust solutions requiring 51% resistance to attacks are required because the consensus mechanism is the only security mechanism. It’s a single-layer of defense, but it is only protecting the blockchain itself.

Casper for Ethereum and other delegation mechanisms are attempting to recreate 51% BFT without anything except the blockchain itself, but with much lower processing overhead. As processing multiplicity along with algorithmic artificial scarcity is what leads both to slow finality and exorbitant electricity use, attempts to find solutions to consensus overhead are well worth exploring.

As soon as we move to permissioned nodes, there is a very strong expectation of security on the nodes and node hardware. Security of a blockchain with every node providing consensus and every node being behind a secure firewall is in theory lower as there are fewer nodes, which might allow a takeover attack, but the lapse of security is made up by the security of the node itself provided by the known organization.

Sovrin aka Hyperledger Indy is of very high utility as an identity provision blockchain, but identity is too important to leave a node to be set up by an anonymous party. You have to apply to be Steward and onboard. Part of onboarding in a permissioned, public model is a requirement to expose the contents of the node to be read, but writing is only done between permissioned nodes.

Hyperledger Fabric is intended to be permissioned and private. Part of onboarding is establishing a secure node behind firewalls and only allowing other known secure nodes behind firewalls to talk to it. Fabric barely has a consensus mechanism compared to unpermissioned Ethereum or Bitcoin, because only trusted parties are allowed into the blockchain. You have a much lower concern about BFT because you are using traditional contractual and business mechanisms for that portion of the requirement, and taking advantage of blockchains inherent synchronization for its utility.

Ethereum in the consortium model uses all of its consensus mining mechanisms, but typically across such a small number of nodes that if the nodes weren’t protected, achieving the takeover of enough nodes to invalidate consensus would be trivial.

Auxledger is a useful case study. The Indian ledger, intended for governmental and enterprise blockchain solutions, is intentionally a permissioned, public blockchain. They have implemented MIT’s Tendermint consensus solution, which only provides 33% BFT, meaning only a third of nodes would have to be co-opted in order for the blockchain to be compromised. But since every node is trusted and known secure through an onboarding process, the security requirement doesn’t rest solely on the blockchain, but also on the expectation of secure and known nodes.

Security is a defense-in-depth play. For enterprise-scale solutions, no security is adequate if only one mechanism is in use. Only in fully decentralized solutions — once again, a bit of ideology, not a fundamental requirement — is very high Byzantine Fault Tolerance required.




The Future is Electric is the house journal of TFIE Strategy Inc, a firm which assists global clients to future proof themselves in our rapidly changing world of business and technical innovation, and geopolitical and climate disruption.

Recommended from Medium

Community update #13 (weeks 18–19)

How Can Blockchain Technology be Applied in Real Life?

Aergo’s AMA (Oct 3, 2018)

Introducing Topaz Testnet

Flow blockchain exhibited at “Tokyo Game Show 2021”!

Pledge Finance Community Trivia Quiz #3

Decentralized Applications: The Blockchain Open-Source Software Gaining Momentum

Interoperability on Manta Network and Moonbeam — Successful XCM Deployment on Testnet

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Michael Barnard

Michael Barnard

Advisor Agora & ELECTRON. Founder distnc & TFIE. Publish on low-carbon transformation and related politics.

More from Medium

What the buoyant second-hand EV market tells us about the future of the automotive industry

IMAGE: Several Teslas parked in a supercharger

Space Blankets Explain Global Warming

Toward a Laborless Future: 3D Printing Converges with AI

Following the LiB Money Trail to Safety & Innovation