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.
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/
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.
This is a more theoretical question than a practical one, but I was thinking on possible attacks in Hyperledger Fabric.
On a high level, orderers are the block makers, and the whole blockchain is eventually maintained by the peers. The consensus algorithm is executed among the orderers (which might tolerate up to a certain number of byzantine orderers if the consensus is byzantine fault tolerant).
But what happens if some peers are compromised? What would happen if an attacker subverts more than half of the peers in the system? Could it result in a chain fork or reorganization?
It depends on your endorsement policy. For example, if you requires a AND (b OR C) for a certain type of transactions, where b and c are comprised, they can do no harm to a, as a would reject transactions that have not been signed by it. (obviously b and c may commit the transactions but they are malicious in this case and the behavior can be arbitrary)
Keep in mind that Fabric is a permissioned blockchain, and you need to define policies according to your business requirements.
It turns out that in fact all of the peers can be Byzantine (same for the clients as well).
This is precisely stated in the Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains paper, section 3.5 (Trust and Fault Model). The integrity of HLF relies solely on the orderers. This is because even if all peers collude and try to rewrite history in the blockchain, they won't be able to produce signed blocks (as the orderers are the only entities that can make blocks).
The best they can do is to try to delete blocks, but even with the presence of a single honest peer, that peer will show a "longer" history of blocks which will be the accepted one.
I want to know that how much transactions can be take place in one second over hyperledger fabric with Kafka protocol.
I'm creating a network, as such project size is not as much big but if my product will do millions of transactions per second around the globe and want to log those transactions over hyperledger fabric so could it be possible that fabric can manage them all?
If yes than how many nodes should i need to setup first and what should be the server specs to deploy the network.
And if this is not the good idea of using fabric than kindly let me know which blockchain should i use to log the immutable and consortium ledger.
As Hyperledger Fabric is a scalable platform, you may scale it to fit your needs. But as your project will do millions of transactions per second, you can apply more than just adding new nodes to increase TPS(Transactions Per Second). Like,
Using IPFS based chain storage to store bulky data off the chain and have the proof hash on the hyperledger fabric.
Indexing the CouchDB underneath for speed and scalability that suits your need.
Using high throughput network provided by Hyperledger Fabric itself
Increasing the number of endorser channels
Now, for the hardware requirements, there has been an experiment done at IBM with a single node of 4vCPU and 16GB memory with SSDs, the following data has been found-
Using 2 endorsers -> 785 TPS
Using 4 endorsers -> 948 TPS
Using 8 endorsers -> 1265 TPS
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.