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.
Related
I would like to know what is the best practice or preferred method to design a fabric network in 2.x versions? Shall we have orderers in the same organization as peers or should we need to have a separate org for orderers? Or should we have two different orgs for peers and orderers for each participating orgs? Can anyone shed some light and point me to resources?
It all depends on the real-world problem you are trying to solve.
The only requirement for production networks is that you have an ordering service with Raft Consensus.
At least 3 ordering nodes, because if it was only 1 node, it can go down and the network would not be able to cut new blocks, and if it is an even number of nodes (i.e. 2 nodes or 4 nodes) Raft would have a hard time electing a leader. In production, 5 ordering nodes are recommended.
Now that you have decided on the number of ordering nodes for the ordering service, you have to decide which organizations should contribute an ordering node to the service. This is where you specific use-case comes at play. For example, a regulatory body contributes 2 ordering nodes, and the other 3 ordering nodes are owned by separate businesses that the regulatory body oversees.
As for the peer nodes, any organization can have as many as required, even if they have ordering nodes. For example, a regulatory body may have 1 peer node and 2 ordering nodes on the same channel.
To sum it up, organizations can have as many peers as needed. For the ordering service, you have to select the organizations that will contribute ordering nodes to the ordering service. This selection process is dependent on your specific use-case.
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.
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
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.