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.
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.
