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.
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.
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.
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.
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.