hope you all are well.
I'm researching Hyperledger Fabric and have a question about how integrity of the network works when peers are byzantine.
In the documentation it states that: "State is maintained by peers, but not by orderers and clients" [1]. It also states that "As long as peers are connected for sufficiently long periods of time to the channel (they can disconnect or crash, but will restart and reconnect), they will see an identical series of delivered(seqno, prevhash, blob) messages [from the ordering service.]"[1].
In essence my question is: Does the orderers save a copy of all the blocks that they have delivered to peers? If we assume that they are correct then any correct peer that joins the network should be able to retrieve a correct sequence of delivers so that it can recreate the state correctly. However since the documentation also states that the state is not maintained by the orderers we could have a situation where incorrect blocks will be delivered to the newly connected correct peer from a byzantine peer.
This might not be an issue in practice since one would probably configure a newly connected peer to receive blocks from peers of the same organization and why would peers in the same organization attack each other. I'm just trying to understand how Fabric works and this seems like an attack vector to me.
Thanks!
References:
1
Hyperledger Fabric is not Byzantine Tolerance yet. The orderers use the Raft consensus mechanism that is Crash Fault Tolerant.
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/
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.
We are looking to implement a hyperledger-fabric solution and I'm stumped by this fundamental question. How is a hyperledger solution architected if not all participants are able/willing to host a peer node?
Our users are divided into 2 groups - payers and providers. Most of our providers are willing and have the IT infrastructure required to host a peer node. Many of our payers are/do not.
From the perspective of a payer participant how can I trust the system if I'm not a peer and don't have my own copy of the ledger? What options might we have in setting up a hyperledger environment that allows them to participate?
Apologies if I have missed the point or some documentation that describes this scenario but links to it would be most welcome.
The easiest "trust assumption" is for groups which don't run peers to trust a specific member who is running a peer. For submitting transactions, it really does not matter if you run a node or not ... you would likely care about the endorsement policy in effect to make sure that there is not one all powerful member with a peer, but other than that you submit to multiple peers for endorsement anyway. For querying data, as mentioned you might have affinity / trust for one particular member, you might select a random or majority set of peers and do a "strong read". A query is still an invoke so you can actually query multiple peers in the same call.
In Ethereum, we cannot define/add new responsibilities for miners unless we modify/change miners' code.
Question: In Hyperledger Fabric, can we define/add new responsibilities for/to miners by using system chaincodes? or the system chaincodes are only for certain purposes (e.g. defining policies, validation)?
edit: this edit is done after the 1st answer has been provided.
miner or nodes or peers or orderers
There is no mining or miners in Hyperledger Fabric.
As #Jworthington stated, there are no miners in Hyperlegder. You need to take a step back and understand the core difference between Public Blockchains (Ethereum) and Permissioned Blockchain (Hyperledger, Corda).
To be fair, calling Hyperledger a blockchain is a bit of a misnomer. It is a distributed legder, and does not require the action of miners to reach consensus.
Both platforms work with the concept of nodes, with differing functionality. They are both similar in that nodes host versions of the world state/ legder. In ethereum , you have miner nodes, which are full nodes, with the additional responsibility of validating transactions via Proof of Work. In Hyperlegder, nodes function either as clients (to connect with the Fabric network), peers ( copies of the world state, validate or endorse transactions) and Orderer.
When you write chain code, you craft the rules that dictate the validation of transactions by the orderer. This is installed on peers and instantiated on each of the channels. You install the chain code on peers you want to endorse transactions (using the Lifecycle System Chaincode).
Endorsers simulate and endorse transactions using the Endorsement System Chaincode (ESCC), while committer peers validate transaction using the Validation System Chaincode (VSCC).
Hope this helps.
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.