I would like to leverage Hyperledger Fabric Peers (specifically identities) to communicate data that does not need to be recorded as a world state.
The Private Data Collection seems a step in that direction but everything is ordered and recorded.
Is there a way to send a payload between participants that does not get persisted?
Of course, every parameter sent is recorded in the channel's chain (but not in the world state unless your chaincode specifically does it).
Maybe you can save the payload (encrypted if you need it) in a distributed storage system (IPFS, for instance), share the IPFS hash/index via Fabric and delete from IPFS when it is no longer needed. I don't know if it fits your use case.
Related
I am new in this field and therefore I am still doing studies and researches, I would like to know if JSON files can be imported in Hyperldeger Fabric--if it is better Hyperledeger Fabric or Fabric Composer. more precisely I would like to understand if there is a way to populate the DLT of Hyperledger Fabric automatically.
for now, I have only tried Hyperledger Composer online playground
Fabric don't have any feature to automatically populate the ledger.
You have to develop a solution in order to upoload each Json file and put that on the ledger state.
Any type of data can be inserted on the ledged because it stores byte arrays so its up to you how to serialize.
in case you're asking to making your chaincode or smart contract like talking to the file system and read file or even call some API to collect JSON files,
it could be done but this will break your transaction flow specially during the endorsement process due to during the endorsement process it's expected from each peer to return the same value after executing the transaction against the chaincode to consider the transaction is a valid transaction,
so in case one of the endorsers failed to call the API or failed to read file from file system the transaction will considered to be invalid.
so it's not recommended to do any third party activity in your chaincode or smart contract even if it's possible to do so.
about populating the ledger it can be done it's eventually a database so you can dump it's data, However, if you're trying to backup to recover the ledger in case the whole network down it's impossible due to when you'll reinstall the network the whole config and certificates which were bounded to the transaction will be changed so it has no sense to do it.
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.
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'm aware that read query is a chaincode invocation which reads the ledger current state but does not write to the ledger.
The client app can choose to submit the read-only transaction for ordering, validation, and commit (for auditing purpose)
Question:
Is it possible to read the ledger db without going via the chaincode ?
What prevents someone on channel from directly reading CouchDB (assuming that is the underlying DB used) without using contracts and avoiding recording of reads
Fundamentally, we use an async communication in fabric. The node initiating transaction talks only with the peers synchronously and after that ordering service is initiated which will commit the txn to ledger after all verification check..
Is the following possible ?
node A submits a data to the ledger request for an operation -> which needs to be done by node B.
Is this possible for node A to notify B to check ledger and perform operation and B upon completion notify A to check the updated ledger ?
Is it possible to read the ledger db without going via the chaincode ?
What prevents someone on channel from directly reading CouchDB
(assuming that is the underlying DB used) without using contracts and
avoiding recording of reads
Nothing prevents you from doing it, if you have access to the database itself.
However, the clients usually don't have access to the database and thus the peer (through the chaincode) may enforce selective logic on which clients and what data can be read.
Think of an application server, a servlet container, etc.
The user that browses from the browser doesn't have access to the database the application server uses, right?
A similar thing takes place here.
Fundamentally, we use an async communication in fabric. The node
initiating transaction talks only with the peers synchronously and
after that ordering service is initiated which will commit the txn to
ledger after all verification check..
Strictly speaking, the ordering service does not commit the txn to the ledger, as the ordering service has no ledger. It packages transactions into blocks, then sends the blocks to peers. It is the peers that then validate and commit the block to their own ledgers.
Is this possible for node A to notify B to check ledger and perform
operation and B upon completion notify A to check the updated ledger ?
You need the client SDK to orchestrate all of these. User Chaincodes only run in the context of a client's request.
So, you can have a client perform an operation that submits a transaction, and then the client sends another transaction in which the chaincode checks the current ledger, etc.
What mechanisms exist already for designing a P2P architecture, in which the different nodes do work separately, in order to split a task (say distributed rendering of a 3D image), but unlike torrents, they don't get to see, or hijack the contents of the packets being transmitted? Only the original task requester is entitled to view the? results of the complete task.
Any working implementations on that principle already?
EDIT: Maybe I formulated the question wrongly. The idea is that even when they are able to work on the contents of the separate packets being sent, the separate nodes never get the chance to assemble the whole picture. Only the one requesting the task is supposed to do this.
If you have direct P2P connections (no "promiscuous" or "multicasting" sort of mode), the receiving peers should only "see" the data sent to them, nothing else.
If you have relay servers on the way and you are worried that they can sniff the data, I believe encryption is the way to go.
What we do is that peer A transmits data to peer B in an S/MIME envelope: the content is signed with the Private Key of Peer A and encrypted with the public Key of Peer B.
Only peer B can decrypt the data and is guaranteed that peer A actually sent the data.
This whole process is costly CPU and byte wise and may not be appropriate for your application. It also requires some form of key management infrastructure: peers need to subscribe to a community which issues certificates for instance.
But the basic idea is there: asymetric encryption with a key or shared secret encryption.