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.
Related
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.
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.
What are the fundamental differences between the two? I come from an Ethereum background and am fairly new to Hyperledger Fabric. I've heard people talk about "channels" in the Fabric ecosystem and it sounds quite similar to the concept of sidechains. It'd be awesome if someone could clarify the differences between the 2 (if they exist).
Since Etherium is a token-based blockchain, my understanding of sidechains is that they allow tokens to be transferred between the main ledger and a "child" ledger (the sidechain). Since Hyperledger has neither a native token nor the concept of "child" ledgers, I don't think they are really analogous to channels.
Hyperledger channels allow for private communication between a subset of peers on the network. Only those peers on the channel receive transaction data for the channel. Even if separate channels are not required, a single channel must still be defined, then all peers communicate on this channel. In this way, there is no main ledger in Hyperledger, as each channel effectively acts as a separate ledger.
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.
I am new to Hyperledger Fabric and am starting a new project which is to transfer asset from one person to another. Here are the steps which I think I need to follow to achieve the completion of the project, do tell me if I am wrong or I missed something:
Create an orderer node.
Create a channel.
Create peers and endorser nodes.
Connect each peer and endorser node to channel.
Write chaincode and endorsing policies.
Create transaction to update ledger state.
If I am right, can someone help me with creation of orderer node, or provide me a link which helps. Also wanted to ask that orderer node creation is possible using node SDK.
In Hyperledger Fabric there are 3 types of nodes. Each node is a process running on some machine (perhaps in a container) and communicates with other nodes in the network.
The nodes are:
- Orderer node
- Peer node
- Client node that embeds a client SDK in some language/framework (node.js, golang, java).
You can't create a node on its own. Each node, is correlated with some organization and has its own certificates and private key.
You can take a look at https://github.com/hyperledger/fabric-samples/ (read the https://hyperledger-fabric.readthedocs.io/en/latest/getting_started.html to understand how) and this would allow you to grasp better the core concepts.
After that when you'll be more certain and more knowledgeable, you could also try to deploy your own setup of Fabric on multiple machines.
You can take a look at https://github.com/yacovm/fabricDeployment to how to do so.
There are two aspects to deploying Hyperledger Fabric... the operational aspects (deploying the containers that run the orderer, peer, ca, etc runtime components) and the transactional aspects (creating channels and issuing transaction proposals etc).
Suggest that you look into the tutorials provided. Specifically, I would start with "building your first network". This example gets into the details of how to deploy the network, create a channel and issue transactions.