Crash fault tolerance (CFT) is one level of resiliency, where the system can still correctly reach consensus if components fail. While Byzantine fault tolerance (BFT), which says the orderer can do its job even in the presence of malicious actors. Below are my questions
CFT is more useful for single enterprise. Presently Hyperleger Fabric uses Kafka which is CFT. Even in the case of multiple organization we are using Kafka in Hyperledger Fabric network. Does it mean still we are using CFT?
In CFT, How system can still correctly reach consensus if components fail? For example network is down, or malcious node present in system etc
Can CFT work even in presence of malicious actor?
How Hyperledger Fabric implements BFT? When will they release it?
What is the main difference between CFT & BFT?
CFT is more useful for single enterprise. Presently Hyperleger Fabric uses Kafka which is CFT. Even in the case of multiple organization we are using Kafka in Hyperledger Fabric network. Does it mean still we are using CFT?
Yes it's still CFT, Crash Fault Tolerant model guaranties to withstand system failures, such as crashes, network partitioning. Having N nodes in your consensus system CFT capable to withstand up to N/2 such crashes. Fact that you might distribute it across organizations or different clouds won't change this assumption.
In CFT, How system can still correctly reach consensus if components fail? For example network is down, or malcious node present in system etc
In CFT model there is quorum of N/2 + 1 nodes which has to agree on certain value, therefore as long as you have N/2 + 1 nodes available, which means you have a quorum you will be able to reach agreement, since majority agrees on it. And NO it cannot guarantee anything in presence of malicious actors.
Can CFT work even in presence of malicious actor?
Nope.
How Hyperledger Fabric implements BFT? When will they release it?
There is a plan to implement BFT protocol and integrate in into Fabric, however exact days currently under carefully design and planning. I guess it will be reveled at one of the bi-weekly maintainers meetings.
What is the main difference between CFT & BFT?
The key difference is in the assumptions and threat/failure model, CFT can withstand up to N/2 system failures, while no guarantees on adversary nodes. BFT provides with guarantees to withstand and correctly reach consensus in presence of N/3 failures of any kind including Byzantine. You can think of it as two phase commit versus three phase commit.
Related
I don't know if this question make sense, I know Raft is consensus algorithm and use etcd to distributed the data, and i know etcd in Raft Ordering Service have a similar job with zookeeper in Kafka Ordering Service, but what I don't understand is, what kind of consensus used in Kafka ordering service?
Right now ordering service can use Raft or Kafka (deprecated), but Raft is a consensus algorithm yet Kafka is not. Or actually both of them just part of the consensus ordering phase? then does that mean now Fabric uses consensus algorithm to be part of consensus??? then what kind of consensus used in Fabric? I've read somewhere Fabric is not PBFT yet.
Let's talk about it as ordering and consensus and bring in Kafka and Raft.
In a distributed system, where messages are going to multiple nodes, the said nodes need a way to know which message came first, which was second, etc. Think of it as transactions on your bank account. If you have $20 in your account and someone pays you $30 so your account goes to $50, and you pay me $50 and your account goes to $0, its a valid sequence. But if your bank messes the order and you start with $20 and the transfer to me for $50 comes next, that check is going to bounce.
So that sequence (also known as order) is important, and in Fabric this is done by The Order Node.
For redundancy, to mitigate malicious intent, for decentralization and other reasons, you may not want just one node providing order. But, if you have n ordering nodes, how do you make sure they come up with one order of messages and not n variations of that order? You get a consensus among those nodes on the order of those messages.
As one of the responders posted - you can achieve that consensus with RAFT or Kafka. Both are Crash Fault Tolerant (CFT) consensus algorithms, which means theoretically as long as majority of the ordering nodes are good, (2 out of 3, or 3 out of 5, etc) you are in good shape.
You are correct and RAFT does use etcd, but I think that's an implementation detail and not tied to the consensus conceptually. Etcd is an open source key-value store used to hold and manage information that distributed systems need to keep running. Its used by RAFT in Fabric, but it's also used by other projects like I think kubernetes uses it to manage all the configuration and metadata, etc
I am not aware of a Byzantine Fault tolerant library (where 2/3rd or fewer ordering nodes can be faulty I think and the system would still function) being available for Hyperledger Fabric yet, although there have been and continue to be discussions on it and the Fabric documentation states that RAFT CFT is a stepping stone to a BFT consensus library for Fabric in the future.
I would also reiterate reviewing the link to The Ordering Service Docs that was posted by another poster as good material to review for more information.
I also really like this introduction to RAFT video, it's not related to Fabric, but does an excellent job of explaining RAFT in general, if you are interested.
In its entirety, a consensus in the blockchain is a mechanism that ensures all copies of a distributed ledger are the same.
Hyperledger Fabric achieves consensus by relying on a backend service (known as the ordering service) that intermediates the messages between senders and receivers. This backend service will ensure that all receivers will see messages in the same order – it follows that if all receivers see messages in the same order(prior to version 1.4, used Kafka, and later RAFT), they will perform the same actions/commits, etc. and the consensus is achieved.
Hyperledger Fabric uses Crash Fault Tolerance(CFT) to achieve consensus for single as well as multiple org systems. Crash Fault Tolerant model guaranties to withstand system failures, such as crashes, network partitioning. Having N nodes in your consensus system CFT capable to withstand up to N/2 such crashes.
For more information, you can read this article which does a good job on explaining consensus in Hyperledger Fabric.
I am not an expert on the subject , but I will try to respond to your questions.
Apache ZooKeeper (used in Kafka) , does not use a consensus algorithm , it is a centralized service that save configuration and expose endpoints (https://zookeeper.apache.org/) , so Zookeeper is used as a central communication point and it use Zab to propagate state update. If you want more info , go here : https://kafka.apache.org/intro
Now Fabric use etcd to maintain the state of the world state , etcd use Raft wich is Leader/Follower type consensus algorithm.
So Raft is the consensus used in HyperLedger Fabric as 2.x , but as it is a Leader/Follower type algorithm , it is not Byzantine Fault Tolerant (at is core , modification can be made to make it PBFT).
I recommend you read the Hyperledger documentation which is very complete , and probably explain better than me: https://hyperledger-fabric.readthedocs.io/en/release-2.2/orderer/ordering_service.html
Also , the RAFT documentation if you want to understand how the algorithm work : https://raft.github.io/
Both, Hyperledger Fabric and BichainDB offer the possibility to have a private, permissioned blockchain database. With their concepts they try to address the main disadvantages of public blockchains like lack of privacy and lack of performance (low throughput etc).
What are the main differences between the two technologies?
If you try out example application of both frameworks, you will quickly notice that BigchainDB is easier to start with. Hyperledger Fabric involves a lot of more knowledge to master it.
Fabric knows different kinds of nodes (peers, peers additionally being endorser nodes, orderer) and thereby allows a very flexible setup, depending on the consortium design and organisations themselves. BigchainDB has one kind of node that can be deployed. Also every involved organisation gets one node of course.
Fabric has richer capabilities to model assets and all kinds of transactions. One transaction kind can always be implemented by a custom processor function doing whatever is needed to query or modify the state of the ledger. BigchainDB only knows CREATE and TRANSFER transactions on every defined asset. You can create something (that may be also divisable, e.g. amounts of tokens) and can transfer them completely or partly.
Both seem to have pretty low level APIs. Fabric has more APIs and config models that need to be mastered. But Fabric is being complemented by frameworks such as Composer (with all its nice libraries involved, like playground and rest-server) that really improve the programming model. As far as I know there is nothing like that for BigchainDB, also because it is pretty simple from the start.
Consensus: BigchainDB uses Tendermint which is Byzantine Fault Tolerant. Fabric does PBFT which is Practically Byzantine Fault Tolerance, based on the idea of Miguel Castro.
In general I would say that Fabric is intended to be used for complex business use cases. BigchainDB is simpler and nice for assets that can be divided (financal stuff like coins/tokens maybe).
Is there any limit of creating number of nodes while configuring hyperledger fabric?
I have gone through the below answer but I'm not clear what he is explaining.
Limit of number of nodes in Hyperledger
When I say number of nodes, it could be number of stakeholders(marked as organizations) or peers or endorser nodes.
The answer on that post is now incorrect. Fabric does not currently used Byzantine Fault Tolerance, it only has Crash Tolerance through Kafka ordering. Byzantine Fault Tolerance is estimated to come around Fabric 1.4.
With Kafka, there is not a limit on the number of nodes. There is a performance hit as you introduce nodes, Hyperledger Sawtooth is known to be better for node scalability
There is no limit to creating the number of nodes in fabric ( that's the idea behind distributed system) but be aware that as and when you start adding more and more nodes, you may see the performance being adversely hit when you do the transactions.
As per my recent conversations with the teams which have implemented Hyperledger Fabric on version 1.1 it seems the performance is okay for upto 16 to 18 nodes. It seems to be a trade off due to the faster finality demonstrated by Hyperledger Fabric.
In Hyperledger Fabric, nodes can be of type orderers, endrosing peers or clients.
If we are talking about how many Byzantine nodes, then the precise answer is as follows: a) There is no limit on Byzantine peers and clients. If there are too many of them, a client just won't be able to get his transaction endorsed. However the integrity of the system is not endangered. b) Since the consensus algorithm is run between the orderers, then the limit depends on that specific algorithm used. Remember Hyperledger Fabric supports pluggable consensus, meaning that the consensus algorithm is not necessarily hardcoded. In its current implementation, Hypeledger Fabric runs "Kafka" which is NOT Byzantine-Fault tolerant. This means that even one Byzantine orderer can compromise the whole system! However, there are plans for BFT-Smart which is Byzantine-Fault tolerant and supports up to 33% faulty nodes, as the above answer says.
If we are talking about the total number of nodes, then the precise answer is as follows: a) There is (theoretically) no limit on the number of clients-peers. b) The practical limit of orderers again depends on the consensus. For BFT, this translates up to practically 10 (maybe 20) orderers.
I am looking for information on how many peer nodes , ordering nodes and CA servers are required to handle 1 million transactions per minute. Which deployment strategy is helpful. Docker Swarm or Kubernetes - which one is ideal to use to provide scaling and extensibility.
The scaling of Hyperledger fabric depends on the chosen consensus method. The consensus methods that support Byzantine Fault Tolerance can handle transactions <1000 per seconds for <20 nodes. For more number of transactions or more number of nodes, other non-BFT consensus methods can be chosen. However, these other consensus methods cannot guarantee the correctness of transactions as guaranteed by the former.
I'm currently working on a POC using hyperledger fabric + composer. I am somewhat confused when it gets to the consensus mechanism between orderers. From what i understand reading the documentation, hyperledger currently only supports SOLO and KAFKA. My understanding of SOLO is that the network only exists out of a single ordering node and no network consensus is reached between orderers (only 1 exists).
But this doesn't make sense to me; my gut tells me it must be possible to add multiple orderers without the use of KAFA / Zookeeper and that hyperledger has another mechanism to reach consensus between these two. The documentation regarding this is somewhat spotty and all over the place if i try to google it so i'm hoping someone can shed some light on the matter.
If no consensus mechanism exists between orderes besides a centralised one then what is the point of a distributed ledger platform?
The primary usage of SOLO ordering is for development mode, where you would like to test functionality without a need to span complex distributed consensus solutions. Moreover, note that consensus is a pluggable mechanism and could be replaced with anything you'd like, for example there is a recent proposal to use SmartBFT as an additional ordering service. Very similar to this you can add consensus mechanism of your own.
Currently if you need to distributed and highly available solutions for consensus there is a KAFKA based ordering service.
The Raft-based consensus protocol was added in Hyperledger Fabric v1.4.1, which simplifies deployment and adds decentralization to OSNs. It removes the additional dependency of Kafka/ZooKeeper needed to run a fault-tolerant network.