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/
Related
I have a problem with understanding why Hyperledger Fabric (HLF) uses blockchain structure.
I know that in Bitcoin blockchain structure ensures big security due to PoW algorithm and longest chain rule, but what are advantages of using a blockchain structure in HLF?
It seems to me that in Hyperledger Fabric, instead of the blockchain structure, there could be one transaction history log and network could work in the same way - I bet I'm wrong, but I haven't been able to find an explanation yet.
I would be grateful for the clarification of this issue.
I think a lot of questions you have in your mind comes from the overlapped definitions of DLT and blockchain.
DLT:
A DLT is simply a decentralized database that is managed by various participants. There is no central authority that acts as an arbitrator or monitor. As a distributed log of records, there is greater transparency – making fraud and manipulation more difficult – and it is more complicated to hack the system.
All of this could well be familiar because it’s written about the features of blockchain as well.
Blockchain:
Blockchain is nothing else but a DLT with a specific set of features. It is also a shared database – a log of records – but in this case shared by means of blocks that, as the name indicates, form a chain. The blocks are closed by a type of cryptographic signature called a ‘hash’; the next block begins with that same ‘hash’, a kind of wax seal. That is how it is verified that the encrypted information has not been manipulated and that it can’t be manipulated.
DLT platforms that are not blockchain provide immutability too, but it's just the way Hyperledger Fabric provides this characteristic which makes it a blockchain framework.
Every blockchain framework, be it the Ethereum, Bitcoin, etc all store the transaction information in blocks, where each block is linked to its predecessor by a hash and provides immutability.
Corda is very much similar to Hyperledger Fabric, but it is said to be both a blockchain and not a blockchain. Architecturally, it's very much similar to Hyperleder Fabric, but with only a key difference which makes Hyperledger Fabric a blockchain framework, and Corda a DLT.
I'll try to answer your question by emphasizing on the point that why Corda is not a blockchain.
Why is Corda a blockchain, and not a blockchain?
A Transaction in Corda is cryptographically linked (chained) to the transactions it depends on. Just like Bitcoin, but the range of concepts that can be expressed is far wider.
Transactions in Corda are processed by having each participant in the transaction execute the same code deterministically to verify the proposed updates to the ledger. Just like Ethereum, but the languages you can use are high-level and productive, like Java, rather than obscure ones like Solidity.
Transactions in Corda are shared only with those who have a need to know. Just like channels in Fabric but designed in from day one and fully integrated into the programming model.
Transactions in Corda are confirmed through a process of consensus forming using one of a range of algorithms, including Byzantine Fault Tolerant algorithms. Just like any other blockchain, but with the unique features that a Corda network can support multiple different consensus pools using different algorithms.
So, for all intents and purposes, Corda is a blockchain. And yet… there’s also an utterly critical difference.
Unlike the platforms mentioned above, Corda does not periodically batch up transactions needing confirmation — into a block — and confirm them in one go. Instead, Corda confirms each transaction in real-time. No need to wait for a bunch of other transactions to come along. No need to wait for a “block interval”. Each transaction is confirmed as we go.
Now coming onto your question why Hyperledger Fabric (HLF) uses blockchain structure? The answer is simply because they chose to.
References:
https://www.bbva.com/en/difference-dlt-blockchain/
https://cointelegraph.com/news/what-is-the-difference-between-blockchain-and-dlt
https://www.corda.net/blog/corda-top-ten-facts-7-both-a-blockchain-and-not-a-blockchain/
To keep the record immutable, Hyperledger Fabric uses blockchain structure. So by using Hyperledger Fabric, you can get an immutable record of all the transactions which is tough to temper with fraudulent activities.
Suppose you buy an valuable asset and you are the current owner of that asset. Now it is very hard for others to temper that records or change your ownership without your permission as Hyperledger Fabric uses blockchain structure to keep the record immutable.
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.
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.