1. 03 Feb, 2017 1 commit
    • manish's avatar
      Move Blockstorage code under /fabric/common package · 2a16532c
      manish authored
      https://jira.hyperledger.org/browse/FAB-2022
      
      
      
      This changes introduced by this CR
      - Moves the block storage code from package
      core/ledger/blkstorage to common/ledger/blkstorage
      
      - Splits the ledger_interface.go so as to move common interfaces
      and data type to common/ledger package
      
      - Moves some of the util functions to common/ledger package
      
      - Moves core/ledger/ordererledger package to orderer/ledger/fsledger
      orderer folks can futher rename/refactor this as seems suitable to them
      
      Change-Id: I759e16f00dc2ec9bb62196121083cf48eae76948
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      2a16532c
  2. 24 Jan, 2017 1 commit
    • manish's avatar
      Detect phantom items during validation · 16372176
      manish authored
      https://jira.hyperledger.org/browse/FAB-1668
      
      
      
      Phantom reads problem:
      -----------------------------
      If a transaction executes a key range query (say key_1 - key_n) leveldb
      serves all the keys in the given range in sorted order of keys.
      Between simulation and validation of a transaction, some other transaction
      may insert one or more keys in this range. Now, this change cannot
      be detected by merely checking the versions of the keys present in
      the read-set of the transaction.
      (though, this check can detect updates and deletes).
      
      A serializable isolation level does not permit phantom reads.
      
      Situations where the phantom reads may not be acceptable:
      -----------------------------
       - A chaincode may take a decision based on aggregates of the results of
      the range query such as min/max/avg/sum etc. This would be affected
      if a new entry gets added to the range query results.
      
       - A chaincode may want to change all the marbles
      owned by a specific user to blue in a tran `t1`. The chaincode may do so
      by performing a range query to get all the marbles for the user and
      change their color to blue. Now, if a new white marble get added to
      the user's assets by an another transaction `t2`,
      `t1` should be marked as invalid.
      
      Solution in this change-set:
      -----------------------------
      For solving this, we can capture the details of the range query
      (the query and it's results) during the simulation time and
      re-execute the query during validation time and compare the results.
      If the results (keys and versions) are still the same,
      we can safely commit the transaction.
      
      This changes set introduces
       - Structures for capturing the range query details in rwset
       - Detection of phantom items (insertion/deletion)
         that affect the results of the range query during validation
       - Mark the transactions that are affected by the phantom items
         as invalid to ensure serializability in the presence of range queries
      
      Change-Id: I909841a0234c37795ad7a4ffcca8a9ebd9c9f994
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      16372176
  3. 26 Jul, 2016 1 commit