-1

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.

Alex Totheroh
  • 157
  • 2
  • 11
  • You might want to take a look at this: https://stackoverflow.com/questions/49934312/how-your-data-is-safe-in-hyperledger-fabric-when-one-can-make-changes-to-couchdb – Alexis Côté Jan 29 '19 at 19:25

1 Answers1

8

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.

Dave Enyeart
  • 2,523
  • 14
  • 23
  • 1
    @AlexTotheroh There is nothing in peer code that would enable such propagation. Perhaps you have an issue in your environment, for example could you have two peers pointing to the same CouchDB database? – Dave Enyeart Feb 12 '19 at 01:09
  • 2
    @AlexTotheroh I have also tried it and see no such behavior. Perhaps there is some other environment issue, for example perhaps both your containers are pointing to the same data volume on the host. Or perhaps you have enabled CouchDB level replication. Or perhaps after the manual update in CouchDB there has been a transaction that reads the state on this peer and then submits an update transaction to the network. I can assure you, there is no code in the peer that would automatically propagate a manual database update to other peers. – Dave Enyeart Feb 12 '19 at 20:24
  • Do you know how we can catch which peer try to tampered ? I update the CAR4 from the peer0 from org1 from the CouchDB UI and I watched through the logs from peer0 from org2 and the only information I got is : `2020-02-07 12:22:01.278 UTC [statecouchdb] commitUpdates -> WARN 0b4 CouchDB batch document update encountered an problem. Reason:Document update conflict., Retrying update for document ID:CAR4` – jdc Feb 07 '20 at 12:29
  • Dave Enyeart -> if you have an answer please response to this post -> https://stackoverflow.com/questions/60113796/hyperledger-fabric-how-can-we-catch-the-peer-who-try-to-tamper-data – jdc Feb 07 '20 at 12:51
  • @JohnnyDaCosta, I could not find the post above. Have you figured out which is the peer with invalid data. – Ashishkel Oct 06 '21 at 04:43