Hyperledger Fabric is fragile with CouchDb on a single node?

Question

I am developing an application using Hyperledger Fabric and I have built the Node.js client that exposes the API to make calls to the blockchain, which is up with the startFabric.sh script.

I am using CouchDB and all of the dockers that we need. I have only 1 peer, so 1 node in my network. This is a very simple one.

I thought that having a Blockchain with Hyperledger makes my data persistent. But I modified data inside CouchDB and if I query the ledger I get the modified data. How is it possible? This is not a Blockchain.

Can anyone explain?

Here is what I did in order to let you better understand the problem. I have created my Entity invoking the API, the result from the blockchain is that the transaction has been submitted: https://i.imgur.com/0gjtCAw.png

And in fact, if I use the query API to get this entity, I receive this: https://i.imgur.com/T70xiWU.png

But we can check it also on the blockchain since I have the docker in log mode: https://i.imgur.com/duQdbL5.png So, until here, everything seems fine.

Now I open CouchDb and I see that my data are stored here: https://i.imgur.com/dQTF6Lj.png

I open the entity Try2 and I modify the Owner and Location parameters, then I save: https://i.imgur.com/VfZY3yi.png

This should not be possible inside a blockchain. I am modifying data and no new transaction have been done, so how this is possible?

If I query the blockchain now, I get my modified data: https://i.imgur.com/OK72vx6.png

Am I missing some point or this should not be possible to do inside a blockchain?

Answer 1

You are having just one peer and thus your endorsement policy would be such that if this peer endorses a transaction, that transaction would be valid.

However, in realtime use-cases, there are multiple peers owned by different organizations. And the endorsement policies are such that the majority or all the endorsing peers have to endorse the transaction for the transaction to be deemed valid.

For example, consider a consortium of 3 organizations, Org1, Org2, and Org3. Each of them has one endorsing peer, namely, Org1Peer1, Org2Peer1, and Org3Peer1. And the endorsing policy is set such that a transaction is valid only if all these peers endorse the transaction. Here, assume that you're the admin of Org1.

Now, for any valid transaction to be committed to the ledger, it has to pass through broadly 4 stages:

1. Endorsing
2. Inspecting the endorsement responses and proposing the transaction
3. Ordering
4. Validation and Commit

For your question, we need to look at stage 1 and 2. In Endorsing stage, all the endorsing peers, Org1Peer1, Org2Peer1, and Org3Peer1, has to simulate the transaction and create a Read-Write set. Here, endorsing peer utilizes the values stored in the State Database (for example, CouchDB) for creating this set. Broadly, read set contains the state value of an asset before the simulation and write set contains the state value of an asset after the simulation.

Further, all these endorsing peers send their read-write set to the client from where the transaction is initiated. Here, the read-write set sent by all the endorsing peers is inspected and compared. Now, since the endorsing policy required all the peers had to endorse the transaction, the read-write set of all the peers has to be exactly the same. Meaning, all the endorsing peer should be having same values in state database before simulation and should result in the same state values after simulation. If the read-write set differs, the proposal is not generated and the transaction is rejected.

Thus, if you, being an admin of Org1, updated values in the state database, then, during the endorsing phase, your peer Org1Peer1 will generate different Read-Write sets from that of Org2Peer1 and Org3Peer1. And the transaction proposal will not be submitted to the Ordering service (stage 3).

Note, the client can choose not to inspect the responses (read-write set) and yet forward the transaction proposal. This proposal would, however, be inspected at the Validation and Commit stage. Here, the transaction will be marked invalid since the read-write set differs and will be committed to the ledger.

You can get more clarity by reading about Transaction Flow.

Answer 2

When you make a Query transaction, the Peer will get the latest state of the argument, which is located in World State. This part makes the availability of the network better.

By default, the system uses LevelDB for World State and CouchDB is an option (more info).

For that reason, when you modify the value at CouchDB on a single peer, only the World State is modified, not the Ledger. This will not break the chain!

You can read more about the Ledger concept of Hyperledger Fabric here.

Hope this can help!