CODEWITHSUNDEEP
hyperledger-fabricblockchainhyperledger
Calvin Cheng
Calvin Cheng

Reputation: 28

Discrepancy between blockchains of different peers in Hyperledger Fabric 1.4

System: Hyperledger Fabric 1.4.6

Topology: 2 organizations (Org1, Org2) with 2 peers (peer1, peer2) each and Raft ordering service

Endorsement Policy: Any 2 peers

Chaincode interaction method: through Node.js SDK

StateDB: CouchDB

Detailed Steps to re-create the problem:

  1. Org1 successfully creates a record (i.e. record#ABC) by sending proposal to all 4 peers for endorsement via chaincode method stub.putState()
  2. record#ABC is just a simple one layer JSON (key-value pairs)
  3. Visits the CouchDB portal of peer2 of Org2 and deletes the record#ABC directly
  4. Retrieve record#ABC from all 4 peers via chaincode method stub.getState() and 3 peers return same correct result and only peer2 of Org2 returns empty result as expected
  5. Retrieve record#ABC from all 4 peers via chaincode method stub.getHistoryForKey() and all return the same results as expected (To my understanding, this method performs query directly from levelDB instead of CouchDB)
  6. Org1 successfully updates one value of record#ABC by sending proposal to all 4 peers for endorsement via chaincode method stub.putState()
  7. By checking the Node.js app log, peer2 of Org2 returns an error of No such Data as expected. Since it only requires 2 endorsement signatures, it is expected to pass through the validation.
  8. By checking docker log of peer2 of Org2, block#007 is committed but its transaction is marked as invalid by state validator because of MVCC_READ_CONFLICT
  9. Retrieve record#ABC from all 4 peers via chaincode method stub.getState() and only peer2 of Org2 return empty result as expected
  10. Retrieve record#ABC from all 4 peers via chaincode method stub.getHistoryForKey() and 3 peers return the same results of 2 versions of record#ABC while peer2 of Org2 returns only original version of record#ABC without the latest version
  11. Retrieve the latest block (i.e. block#007) containing the updated record#ABC transaction from all peers. All the main content of the blocks are the same.
  12. The blockchain can continue to receive new request to create new record.

Here comes to my questions:

  1. Why the problematic block (block#007) is still committed in peer2 of Org2?
  2. Why the blockchain system can continue to operate without throwing serious error given there is discrepancy between blockchains of different peers? Should it be re-designed to halt the operation until the discrepancy issue is fixed?

Upvotes: 0

Views: 80

Answers (1)

Gari Singh
Gari Singh

Reputation: 12053

  1. Persisting / committing blocks is independent of validating transactions and updating the state. As long as the block is the correct sequence and signed by the correct orderer(s), it will be committed. Fabric than annotates each transaction in the block with metadata indicating the validity of each transaction.

  2. As both Org1 and Org2 have peers which successfully endorse the transaction, the transaction is valid for peers which have not been tampered with. If there were not enough peers available to endorse the transaction, it would be considered invalid by all peers. There is no need to halt the system as transactions are being properly handled with the context of the network trust parameters.

Upvotes: 1

Related Questions