Re: Extremely strange behavior with Fabric - modifying ledger out of band
Something else must be going on, since what you've described is not possible. New blocks with validated transactions drive the CouchDB state database updates, never the other way around. Watch the peer log as you make updates and I expect you'll discovery something else going on.
Summary: we created a simple Fabric network that comes with the IBM Blockchain extension and uses CouchDB and one peer and one orderer. we made some chaincode invocation requests and created some data in the ledger. Then we made changes to CouchDB records from the CouchDB web based UI (Fauxton) which can be accessed at http://localhost:17055/_utils.
Observed: It resulted in new blocks being appended to the ledger! When we re-started the network we could see the block height increased and changes made by Fauxton showed up!
Expected: No new blocks should have been appended to the ledger. Fauxton doesn't even know who I am. It doesn't know my X.509 certificate. Who signed the new blocks? How did the changes get endorsed? How did making changes from Fauxton result in generation of a Fabric transaction? This is truly bizarre.
Our understanding of Fabric was that the ledger data is stored in blocks under /var/hyperledger/production/ledgersData folder and the couchdb docker container would read these blocks and initialize the couchdb database. A user is not prevented from modifying records using Fauxton but that won't change anything under the /var/hyperledger/production/ledgersData folder which stores the actual blocks. So if the network is re-started, it should not show any out-of-band changes. But that simply did not turn out to be true.
Can anyone explain this?
e.g., we start with this:
we click on this record which gives
we change createdBy to david and click on save changes button
when we stop and re-start the network
the record has been permanently modified and its creator is now david! so anyone can make whatever changes they want to the ledger?!