I have a quite theoretical question about the scheme used in Hyperledger Fabric for the developers.
If a chaincode has been made by malicious node and only endorse some of the malicious nodes. Then, if a client's transaction triggers this code, the malicious nodes could manipulate with their response. Let us assume that all the responses are 1 while it should be 0. Then, if the client somehow accept their responses, it will be send through the rest of the transaction flow and eventually end up in the ledger. Hence, this incorrect result will be in the ledger.
Would this ever happen? Or did I misunderstood some parts?
For a theoretical question, the theoretical answer is no, it wouldn't happen. For a blockchain network, all peers on a channel that are involved in a transaction needs to have the same chaincode.
Also, even though a peer validates a transaction and sends those successful responses to the client. When the client submit these responses for the transaction to be committed, it will be validated by all peers involved in that transaction before being committed. Basically all parties are agreeing that this is correct at once.
If one node has a different value than all the other nodes do, then something is wrong.
You can follow this simplified explanation of the transaction flow here: http://hyperledger-fabric.readthedocs.io/en/latest/txflow.html, you can view especially step number 5.
Related
I'm looking for a transaction rollback. This is necessary if a chaincode transaction modifies the state, but then fails with an error before it is able to return.
I saw this is done for a pull request but I can not understand how does it works
Added support for rolling back a tx if chaincode execution fails
Someone can give me an example how does it works?
EDIT
What I'm looking for is the concept of Transaction in database(unit of work) but in Hyperledger Fabric
Let's suppose that we are going to register a product for a list of clients, if there is a problem with the registration of the product in some customer then the operation is eliminated and the registration is not made to any client
The commit you linked is no longer relevant to current Hyperledger Fabric versions. This functionality was added before v1.0, which restructured the entire framework architecture.
As of v1.0+, transactions are first simulated by endorsers, which create a signed set of state changes resulting from the chaincode. If enough endorsers sign a transaction (according to an endorsement policy), the client can then send the transaction to the ordering service for inclusion in the ledger. A transaction that results in an error in the chaincode would never get to this point, because it would fail to gather the necessary endorsements due to the error. The client must modify the transaction or request a modification of the chaincode for it to work.
Check out the Hyperledger Fabric architecture paper for a more detailed explanation, including a sequence diagram.
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."
I am trying to understand why a verification of endorsed transactions has been positioned at the application layer instead of Hyperledger Fabric 1.0 ledger network.
Let's assume three possible scenarios :
a) Using Oracles to request information needed to perform a function, and that the address to the Oracle is embedded into transaction attribute.
b) Execution of different actions depending on the origin of the transaction (i.e. through the unmarshalled peer or sender identity)
c) Original smart contract code is tampered with through an injection of malicious binary code into the dev-* container
If, let's say, a genuine network participant with malicious intents wants to inject some garbage into the ledger and has an access to the application source code, she/he can tweak around this SDK function in order to force proposed transactions with dissimilar results to be sent straight to Orderers. If I understand right, the network will not detect such a misconduct.
Please correct me if I am wrong and if this issue can somehow be mitigated at the network layer.
The application layer is the one to fulfill the endorsement policy, since the application to invoke the chaincode, therefore to make it valid the application has to go and literally invoke chaincode against all parties involved or related to given transaction.
That being said, it become kind of obvious that once application at any case to invoke and collect endorsements it's make many sense to have the application layer to verify endorsement results and make sure they are correct before submitting to the ordering service.
However if client won't do that check or will try to temper the endorsement results, first of all it won't be able to provide required signatures over tampered data. While moreover there is a VSCC (Validation System Chaincode) which takes care to validate transaction to ensure that endorsement policy satisfied, overwise rejects/invalidates the transaction.
I'd say doing verification on the application side is more like a best practices and the optimization path which aims to spare validation cycles for transaction known not to be consistent once application receives all endorsement results.
I would really like to understand how endorsments work in Hyperledger Fabric in order to help me in designing a solution to a problem.
let's assume I am an endorser and a transaction proposal has just arrived. I would randomly select a participant within my organization, use its identity to perform the validations, checking for replay attacks etc then sign an endorsement with that participant's private key. Assuming I used an admin's credentials, the admin(person) may not be aware that I used its identities to validate and endorse a transaction proposal. Is this example correct?
Initial discussions here makes me feel like the more I look into it, the more confused I become. Could anyone help?
Just to start with, the endorser is the peer that capable to handle incoming invocation, maintain and run the chaincode. The flow works as following, support you have a client (C) and the endorsing peer (P), which runs a chaincode (CC).
Client forms transaction proposal request which includes parameters for chaincode invocation.
In order to get an endorsement for this proposal he sends it the endorsing peer.
Endorsing peer opens a transaction proposal and forwards requests to the required chaincode along the way it passes all parameters.
Chaincode get invoked which produces a RWset (set of keys and values read of changed during the invocation)
Peer collects RWset and forms proposal response and signs it
Client gets the proposal response, signs it as well and send it to the ordering service
Ordering service collects proposal responses and cuts the block which got distributed to the peers in the network.
Upon arrival peers opens a block and validates all transactions, one of the validation is to check whenever transaction conforms the endorsement policy, where basically it checks whenever transaction has enough signatures which satisfies the policy.
Back to your question, please note that at each step everyone uses its own key and certificate to sign, no one randomly selects participants to use they identities for signatures or whatever else.
PS. Note that process above a bit simplified and lack a lot of technical details.
PPS. There is a new course on Coursera which covers pretty well many technical aspects of Hyperledger Fabric architecture and the interaction between different components, I would urge you to consider taking this course.
According to architecture explained (http://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html), ordering service collects transactions (RWSets) into block for distribution to committing peers. Then, committing peer validates endorsement policy and RWsets then apply the transaction to ledger.
To verify the transaction was succeeded, should client application wait until all committing peers returned "Success" event ? Or just need to verify only one "Success" event ?
To verify the transaction was succeeded, should client application
wait until all committing peers returned "Success" event ? Or just
need to verify only one "Success" event ?
Tanaka, that's a very good question!
The short answer is No.
The reason is that in contrast to existing popular blockchains, HLF has a unique transaction lifecycle which does:
A transaction is simulated on some endorser or a few endorsers
It is sent to the ordering service and is cut into some block
The block is sent to peers, and they all execute the same validation code and all validation code for a specific transaction is guaranteed to reach the same conclusion in all peers, because they run it in the same order across all of them.
Therefore, if a transaction is validated on some peer - when other peers will receive the block the transaction resides in - they will too consider it as valid.
However - a very important aspect you should consider is data availability and synchronization.
For example, if you have an application that uses 10 peers and only 1 peer got the event and the rest didn't, and you invoke another transaction on the other peers, it might be that the endorsements that the other peers will compute will be turned into an invalid transaction, because they will simulate on old data (the fact that they didn't get the event yet proves that they have not processed the block for that transaction), so you need to keep that in mind.