Hyperledger Fabric CouchDB updates through Fauxton treated as valid updates, but no record in blockchain

Question

I have a Hyperledger Fabric network setup with 3 peers, each with a CouchDB persistence container.

If I go through the Fauxton interface and alter a JSON record, this state change is propagated to all three peers, which are in the same org.

However, there is no record of the state change in the blockchain. No transaction is created for it.

• If it's not a blockchain transaction causing the state change to be propagated to all peers, what mechanism is causing it?

• How in the heck is the state change through Fauxton considered valid with no transaction underlying it?

• What is the expectation for Fauxton in a prod environment?

Edit: To circle back on this: Turns out I was an idiot and had issues with my docker port mappings.

Answer 1

If you change data directly in the peers CouchDB, it will not be propagated to other peers. 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.