Search code examples
blockchainhyperledgerfault-toleranceconsensushyperledger-sawtooth

What is the benefit of non fault tolerance blockchain network


I'm learning about the different Hyperledger based blockchain-frameworks and currently I'm reading about Sawtooth even though the question is not particularly related with Sawtooth.

Given that PoET is as good consensus algorithm as any, what I can't get my head around is what is the benefit of having a blockchain network which is not fault tolerance.

Not only for financial operations but for anything of value, even if there is not a targeted attack, if we have a node which is not working correctly, and this node "wins the lottery" and is the node to insert the next block, what is the mechanism (before or after this) to prevent the system from proceeding with a wrong state?

And if indeed Not a fault tolerant means exactly this, there could be a faulty behavior and it won't be detected, what is the purpose of using such a system even if it's fast and scalable and so on if there is good chance to end up with an incorrect data at the end?

I'm not trying to imply that those network are useless, on the contrary, I'm trying to get a grasp on the ideas behind blockchain and the different variations there are, and because I'm sure there is a good reason for Sawtooth to exist I would like to find out where my logic fails.


Solution

  • Question talks about Fault Tolerance in general. However the description in the question is oriented in a way to talk about Byzantine Fault Tolerance.

    Broadly we can classify Byzantine Fault Tolerance and Crash Fault Tolerance. Byzantine behavior is the unexpected scenario arising because of the node, unpredictable result from the node, it could be intentional (malicious act from a node) or unintentional (machine's memory corruption/hardware issues). Crash fault tolerance is the high availability of the system, though there can be random node failures in the network.

    There's a general misconception that a Blockchain system should always be Byzantine Fault Tolerant. There can be multiple use cases for the Blockchain system. Choosing what to achieve through Blockchain is thus use case specific.

    For example, in most public networks where there's incentive involved for creating a block in the network and there's no established trust or no means of establishing trust among the participants. A consensus algorithm which provides the Byzantine Fault Tolerance may be opt over there.

    Another use case for the Blockchain is its immutability property, i.e. when a data/state is added to the Blockchain it becomes highly computationally difficult to modify it. In case of private Blockchain consortium, participants may optionally prove their identity to the other nodes upon request through some other means and immutability property could be of interest to them. It may not matter who wins the election or who creates a block. To give you an instance, in case of Hyperledger Sawtooth with Raft as a consensus engine, leader gets a chance to create a block always. Raft provides Crash Fault Tolerance in the network as long as majority (50%+1) of the nodes are alive.

    Hyperledger Sawtooth PoET when run on SGX is Byzantine Fault Tolerant and gives all the nodes a fair random chance to construct the block. In case if PoET is run in Simulator mode then it only gives the latter capability. The protection for Byzantine behavior is coming from the Trusted Execution Environment (TEE) like Intel SGX.

    Note: Blockchain systems are designed so that participants get chance to validate blocks created by the winning node. They add the block to their ledger only after validation. In case of consortium a node will be caught if tries to manipulate and because there can be other means of identifying who is the participant, Byzantine behavior can be caught.

    A Blockchain is a distributed design solution, by virtue of its design it provides at the least Crash Fault Tolerance for the system as a whole. Since the same copy of data is replicated across the nodes (at least more than one node), the data is not lost even if there's a failure of one or two nodes in the network. High availability is guaranteed.

    I hope these points helped you to move next in your exploration.