I removed anchor peer definition in configtx.yaml file and also I didn't update anchor peers on my channel for any participating orgs. Surprisingly, the network works fine and all transactions are going through.
I made changes in fabric-samples/first-network folder of fabric's official github repo. I understand that anchor peers are used for gossip communication and peer discovery, though having no anchor peer in the network made no visible difference as compared to when we define them. I was hoping to see some errors but none came. How do I gauge difference between both cases ?
You need anchor peers in order to allow cross organizations communication, that's mean to make peers from different organization domain able to get connected. Now, normally in each organization gossip elects peer to serve as a leader to pull blocks from ordering service and gossip them around. Therefore if no anchor peers is configured, most likely you won't see any difference.
Now, the question, why do you need them. Here is two reasons
You need cross organization communication during state transfer or replication of missing blocks in case for example where one org partitioned from the ordering service but can reach out to the other organization.
Second use case if more complex one. You need cross organization communication for private data, as private data distributed off chain, e.g. via gossip. You need to be able to push pieces of private data during endorsement. And pull missing private data during commit.
Hence unless you are not encounter a need of any of these two scenarios you won't feel any difference with or without anchor peers configured.
Related
I want to ask about blockhain Hyperledger Fabric. Is it possible to let Peer nodes to do Orderer node's task which is packing the transaction into new block?
I kind of think the orderer node is kind of a redundant node since for example in Bitcoin network, the packing of the transactions into block and the verification of new transaction is solely done by the full node(miner node).
Can anyone give me justification why there should be orderer's node in the Hyperledger Fabric?
And if I were to build my project on Hyperledger network and forgo orderer node(which means the peer node will do both the verification of transaction and the packing of transaction) is it possible?
Please tell me your thoughts and ideas.
Thank you.
TL;DR
HLF by design is deterministic so the orderer nodes are important. Only they participate in consensus not all peers and the blocks they produce are Final (Not prone to forks).
No you cannot make a peer orderer as well. Your network configuration for HLF must have at least one orderer to work
Hyperledger Fabric (HLF) vs Bitcoin
HLF is a private permissioned blockchain where as Bitcoin is a public permissionless blockchain. You should not expect them to work similarly.
Public blockchains
In public blockchain for example bitcoin everyone is treated equal in other words no one have special privileges you may think well miner are the ones minning block but the important point is anyone can become miner its open game no restriction on who can become miner or who can run a node etc.
Private Blockchain
In private blockchain for example HLF roles are predefined at the time of setting up and starting blockchain. Each role has certain tasks and privileges and restriction. The no of organisations peers, endorser peers, orderers, channels all are predefined and some have special privileges which no other role has like orderer whose is responsible for receiving endorsed transactions from peers and put them into blocks then these blocks are distributed to all peers. These blocks are Final.
But Why?
Private Blockchains (Like HLF) full-fill special use cases for example supply chain, B2B operations In such use cases one may want to harness positives of blockchain like transparency, auditing, provenance but may also want some sort of role based access or restrictions of certain data to certain audience public blockchains like Ethereum and bitcoin does not fit here.
Now coming toward your question
Why is there an orderer node in HLF isn't it redundant ?
No it's not redundant, HLF has deterministic consensus algorithms where as Ethereum and Bitcoin have probabilistic consensus algorithms which means there can be ledger forks. In HLF there are no Ledger forks because fork occur when two equal participants have conflict at a common point. Incase of HLF the participants are not equal as peers cannot participate in consensus process the block order set by orderers is Final. And rightfully so because for the use cases it is designed for does not want forks and want to have special roles and much much more transaction throughput.
Must must Read !
https://hyperledger-fabric.readthedocs.io/en/release-2.2/orderer/ordering_service.html#what-is-ordering
No it is not possible to assign peers orderer's role you must have at least 1 orderer in your HLF network to work.
In Hyperledger Fabric, what is the expected behavior of peer when all orderer nodes are down.
Should peer also down, or stop serving request from client, or continue to serve query request?
In our test, after orderers are stopped, the peer keeps writing "failed to create connection to orderer" log. When we query a key by calling chaincode the value is returned.
Can you help clarify if this is expected behavior. Thank you.
I am working on a distributed hyperledger fabric network. I would recommend the Orderer Raft Consensus https://hyperledger-fabric.readthedocs.io/en/release-2.2/orderer/ordering_service.html#ordering-service-implementations.
I have solved this in such a way that in my case I have three orderers that run independently on different environments.
If I crash all these orderers, the peer containers will continue to run on the other participants of the network. As you said, they cannot make any transactions.
If one of my orderers crashes it is not so bad after the raft consensus, the containers keep running. If another one fails, no transactions can be made. In this case I let the peers continue and check if the orderers are available again.
The behaviour you described I would put down to the fact that the peer requests the value from his ledger, he doesn't need an orderer for that. https://hyperledger.github.io/fabric-chaincode-node/master/api/fabric-shim.ChaincodeStub.html#getState
Have a read of this: https://github.com/hyperledger/fabric/blob/master/docs/source/peers/peers.md This is the best documentation for how the system works I've found and there's more in the docs directory on the repo for orderers, etc.
My understanding is: The peers are there to sign (endorse) transaction proposals. The orderer exists to order, validate, package and distribute transactions to peers. The peers can also distribute their knowledge of validated transactions via the gossip channel.
If all orderers go down, the transactions will not be validated/packaged/distributed so the blockchain will be out of action until the orderers are restored.
When we query a key by calling chaincode the value is returned.
Peers will still remain up and ready to sign/endorse transaction proposals, and querying the blockchain held at the peers will still work. Chaincodes are hosted by the peers. Orderers do not host chaincode.
Also see here https://github.com/hyperledger/fabric/blob/master/docs/source/orderer/ordering_service.md#ordering-service-implementations for the various modes the orderer can be run in: Raft mode, Kafka ordering, Solo ordering.
I think the current observerd behavour is expected and in my view it is just fine.
Let's check the purpose of orderer?
Order the transactions
Cut the block and distribute the block amongst the orgs when the criteria is met ( min txn/size or time).
This also means, orderer is needed when your Fabric network is processing those transactions which intend to write data into the ledger, isnt it? And Query is not a transaction which writes into the ledger. So it doesn't need the orderer. For query, it will pick up the data from the peer's local database.
So I think what could be done is, to send out an alert to the production support when your application detect orderer node down ( with some health check ? ). And your application displays a dimnished capacity/limited operations message while work on bringing up the orderer network, the system can still serve the search queries.
From my view, its just fantastic. But its finally upto you. Cheers!!
Suppose I have started fabric with two peers in a single organization. After running my application/rest-server through composer and submitting transactions. I was able to make changes in the values of Couchdb instance of peer1 by going on the address http://localhost:6984/_utils/#/_all_dbs. Now, the two peers are not in sync with each other - application should throw some error but it isn't. Mostly, because it is getting data just from the first peer i.e. peer1.
So, firstly how can I get data from multiple peers - if I want to get data from peer2 aswell?
Secondly, why it is getting data from state database not from ledger?
Thirdly, data should remain in sync even after committed how can I configure this? if some peer tampered its database it should be notified. I have read consensus part and got that it is for the correct order of transactions and blocks but what if someone tampered with the state database?
If you're able to change the entries in state database for 1 peer, with a strong endorsement policy such as AND, your transactions will fail validation because of difference in the data for the two peers. This is one of the most important pros of decentralized network.
State database and the Ledger are not same thing. this should help you in understanding the differences between the both.
Every participating member of a Hyperledger Fabric network is a known entity per se (since Fabric being a permissioned blockchain). Said that, a change in state database of a single peer will again lead to scenario #1 above, where the Read/Write sets in a transaction won't match for multiple peers (as their state databases contain different values of an asset). This will lead to invalidation of the transactions. Now it just becomes a question of how can the network know about the corrupted peer(and subsequent state db). There can be multiple solutions for the same.
But most importantly, Fabric being a permissioned blockchain network, the state databases must be very strictly access protected and authorized outside of the network too.
the fact that you modified the world db doesn't mean anything. any changes you make to that database are not a representation of the ledger.
The ledger itself, the blocks and the transactions they contain are stored in a physical file. The world state db is simply a collection of the current state for each asset. This is a good design because an application will not care about every state change an item went through, it will only care about the current state. The world state db can easily be recreated whenever there is a need for it.
Now, you should not make any changes directly to to the world state db, because that's useless. Any change needs to go through the proper process, via a proposal submitted by a peer which then goes through the orderer. Only when everything is followed, does a change go onto the ledger and get synced with every peer and the world state db will reflect that.
In terms of where you should get the data, the answer is that it doesn't matter. Each peer will have an exact copy of the ledger so if you get data from peer 1 or 2 is irrelevant, it will be the same thing.
Again, just because you changed the world state, that doesn't mean anything, the ledger is untouched, but your application reports the current state from the world state db, which is now incorrect because of your change.
Does the gossip protocol is used only to spread the committed blocks via all peers on the "order" stage? Does it work on the “execute” stage, when the endorsing peers execute and sign the transactions?
The gossip component is the peer's communication layer, and it contributes to the block dissemination via having peers distribute blocks among themselves instead of having all of them pull them directly from the orderer nodes.
It works roughly like this:
When the orderer cuts a new block, it appends it to its local file system.
In every organization, there is usually a peer that is selected among the peers in its organization (for that channel) to pull blocks from the orderer, and forward them to other peers in its organziation. The other peers also forward the blocks even further to other peers, etc. etc. and this all happens via a "gossip" style protocol.
I recommend that you read the gossip section in the documentation.
I am wondering that how your data is safe when an admin can change the latest state in Couchdb using Fauxton or cURL provided by Couchdb directly.
According to my understanding Hyperledger Fabric provides immutable data feature and is best for fraud prevention(Blockchain feature).
The issue is :- I can easily change the data in couchdb and when I query from my chaincode it shows the changed data. But when I query ledger by using GetHistoryForKey() it does not shows that change I made to couchdb. Is there any way I can prevent such fraud? Because user will see the latest state always i.e data from couchdb not from ledger
Any answer would be appreciated.
Thanks
You should not expose the CouchDB port beyond the peer's network to avoid the data getting tampered. Only the peer's administrator should be able to access CouchDB, and the administrator has no incentive to tamper their own data. Let me explain further...
The Hyperledger Fabric state database is similar to the bitcoin unspent transaction database, in that if a peer administrator tampers with their own peer’s database, the peer will not be able to convince other peers that transactions coming from it are valid. In both cases, the database can be viewed as a cache of current blockchain state. And in both cases, if the database becomes corrupt or tampered, it can be rebuilt on the peer from the blockchain. In the case of bitcoin, this is done with the -reindex flag. In the case of Fabric, this is done by dropping the state database and restarting the peer.
In Fabric, peers from different orgs as specified in the endorsement policy must return the same chaincode execution results for transactions to be validated. If ledger state data had been altered or corrupted (in CouchDB or LevelDB file system) on a peer, then the chaincode execution results would be inconsistent across endorsing peers, the 'bad’ peer/org will be found out, and the application client should throw out the results from the bad peer/org before submitting the transaction for ordering/commit. If a client application tries to submit a transaction with inconsistent endorsement results regardless, this will be detected on all the peers at validation time and the transaction will be invalidated.
You must secure your couchdb from modification by processes other than the peer, just as you must generally protect your filesystem or memory.
If you make your filesystem world writable, other users could overwrite ledger contents. Similarly, if you do not put access control on couchdb writes, then you lose the immutability properties.
In Hyperledger Fabric v1.2, each peer has its own CouchDB. So even if you change the data directly from CouchDB of one peer. The endorsement would fail. If the endorsement fails, your data will not be written neither in world state nor in the current state.
That's the beauty of a decentralized distributed system. Even if you or someone else changes the state of your database/ledger it will not match with the state of others in the network, neither will it match the transaction block hash rendering any transactions invalid by the endorsers unless you can restore the actual agreed upon state of the ledger from the network participants or the orderer.
To take advantage of the immutability of ledger you must query the ledger. Querying the database does not utilize the power of blockchain and hence must be protected in fashion similar to how access to any other database is protected.
You need to understand 2 things here
Although the data of a couchdb of a peer maybe tampered, you should setup your endorsement policy in such a way that it must be endorsed by all the peers.
You cannot expose your couchdb to be altered, I recommend to see Cilium
As explained by others - endorsements/consensus is the key. Despite the fact that ledger state of an endorsing peer can be modified externally - in that event all transactions endorsed by that peer would get discarded, because other endorsing peers would be sending correct transactions (assuming other's world state was also not tampered with) and consensus would play the key role here to help select the correct transaction.
Worst case scenario all transactions would fail.
Hyperledger fabric's world state (Ledger state) can be regenerated from the blockchain (Transactions Log) anytime. And, in the event of peer failure this regeneration happens automatically. With some careful configuration, one can build a self-healing network where a peer at fault would automatically rise from ashes (pun intended).
The key point to consider here is the Gossip Data dissemination protocol which can be considered as the mystical healer. All peers within the network continuously connect, and exchange data with other peers within the network.
To quote the documentation -
Peers affected by delays, network partitions, or other causes resulting in missed blocks will eventually be synced up to the current ledger state by contacting peers in possession of these missing blocks.
and ...
Any peer with data that is out of sync with the rest of the channel identifies the missing blocks and syncs itself by copying the correct data.
That's why it is always recommended to have more and more of endorsing peers within the network and organizations. The bigger the network - harder it would be beat with malicious intent.
I hope, I could be of some help. Ref Link: https://hyperledger-fabric.readthedocs.io/en/release-1.4/gossip.html
Even though this is plausible, the endorsement policy is the general means by which you protect yourself (the system) from the effects of such an act.
"a state reconciliation process synchronizes world state across peers on each channel. Each peer continually pulls blocks from other peers on the channel, in order to repair its own state if discrepancies are identified."