1. 17 May, 2019 1 commit
  2. 14 May, 2019 1 commit
  3. 09 May, 2019 1 commit
  4. 30 Apr, 2019 1 commit
  5. 29 Nov, 2018 1 commit
    • manish's avatar
      FAB-12803 Add transaction level metrics · 13952e9e
      manish authored
      
      
      This CR introduces a counter metric that is incremented
      with each transaction processed. The labels attaches to
      the this counter include channel_name, transaction_type,
      chaincode_name, and validation_code.
      
      Change-Id: Id30bf318be29ec3c4e99c64d14383fa62f136aef
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      13952e9e
  6. 16 Nov, 2018 1 commit
    • senthil's avatar
      recon: commit only validTx's pvtData in pvtStore · 7105f8bb
      senthil authored
      
      
      Currently, gossip constructs pvtData only for validTx
      as per VSCC. Hence, we are not storing all pvtData of
      a block.
      
      In the ledger, currently, we are storing pvtData of
      invalidTx (i.e., failed MVCC checks) too. To be
      consistent, this CR can stores the pvtData of only
      validTx (as per MVCC check).
      
      FAB-11805 #done
      
      Change-Id: Ic4b228cade0456bc1ddc4ab80595e9e82d7aaa25
      Signed-off-by: default avatarsenthil <cendhu@gmail.com>
      7105f8bb
  7. 30 Oct, 2018 1 commit
  8. 29 Oct, 2018 1 commit
  9. 25 Oct, 2018 1 commit
  10. 17 Oct, 2018 2 commits
  11. 01 Oct, 2018 1 commit
    • manish's avatar
      Missingdata-recon: Handle coll eligibility change · f37beaa9
      manish authored
      
      
      This CR handles the event when a peer becomes eligible
      for receiving data for an existing collection. All the
      missing data entries for the collection that were previously
       marked as 'ineligible' are converted to 'eligible' in a
      background goroutine so that the query results for reporting
      missing data also include these entries for previous blocks
      
      FAB-11437 #done
      
      Change-Id: I145a079b69e8bf02b4c97da23fbf08d7ce2ae268
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      f37beaa9
  12. 28 Sep, 2018 1 commit
  13. 24 Sep, 2018 1 commit
  14. 22 Sep, 2018 3 commits
  15. 21 Sep, 2018 1 commit
    • manish's avatar
      Fix perf issue by key-endorsement to regular chaincode · 945138e9
      manish authored
      
      
      Key-level endorsement needs to access the metadata for each
      of the keys in the write-set. Even the chaincodes that do not
      use this feature will end up paying this additional penality.
      Especially, in an environment that uses  couchdb, the performance
      regression will be visible for the existing chaincodes.
      
      The major reason is that the metadata is accessed one at a time
      during validation and commit path whereas, couchdb is better
      used if the data can be loaded in bulk.
      
      Ideally, the data required by key-level endorsement for the entire
      block should be loaded in a single bulk load call. Which would
      benefit even the chaincodes that leverage this feature. However,
      this would need some refactoring that can be taken up in a future
      release.
      
      This CR introduces a fix which would save the regular chaincodes
      (that do not use key-level endorsement feature) from paying
      the avobe mentioned penality. In this fix, we track the chaincodes
      that do not use metadata and for such chaincodes, the GetStateMetadata
      call simply returns nil without going to the underlying db.
      
      Even when we start using the bulk-load for key-level endorsement,
      this fix will still be relevant in the sense that the bulkload call
      will be avoided for regular chaincodes
      
      FAB-11700 #done
      
      Change-Id: Icfc654b7d27f727f1811a5a300400e92b6e8be9d
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      945138e9
  16. 17 Sep, 2018 1 commit
    • manish's avatar
      Add check for verifying block.Header.PreviousHash field · 161e7608
      manish authored
      
      
      In the current code, before adding a block to the ledger,
      ledger verifies the correct sequence number of the block
      just to double check that gossip is delivering the right
      sequence of blocks. In addition, before block is delivered
      to ledger, the signatures of the ordering service node(s)
      are verified that fulfills the requirement of the trust model.
      
      Though the above checks are sufficient for keeping an unintended
      block from getting committed to ledger. Still, it may not be a
      bad idea to add an additional check that verifies that the field
      `block.Header.PreviousHash` present in the block matches with
      the hash of the last committed block.
      
      This check is a simple bytes comparison and hence does not
      cause any observable performance penalty and may help in
      detecting a rare scenario if there is any bug in the
      ordering service.
      
      FAB-12033 #done
      
      Change-Id: I8d42bc4969d390a2c0f3aad0f7ff884f273c2ba9
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      161e7608
  17. 11 Sep, 2018 1 commit
  18. 07 Sep, 2018 1 commit
    • Chris Elder's avatar
      [FAB-9840] CouchDB safe pagination - statecouchdb · ca152f26
      Chris Elder authored
      
      
      Currently, CouchDB queries are limited to configurable max number of
      results/docs, based on peer queryLimit config option (default 10000).
      The shim/peer supports pagination but CouchDB query iterators do not.
      
      This change will allow additional controls to prevent a large accidental or
      malicious query from causing performance issues with CouchDB.
      
      Changes to core.yaml:
      
      Changed queryLimit to 1000.  This is part of repurposing this parameter.
      QueryLimit is now to be used as a per query limit to CouchDB instead of the
      limit for the query from the shim.
      
      Added totalLimit parameter.  This parameter will be used to cap the maximum
      number of records returned by the query from the shim.
      
      Changes to couchdb:
      
      Added changes to range query to find the next start key (if exists) for the
      specified range.  The next start key is returned with the query results.
      
      Added changes to rich query to find the next bookmark for the query.  The
      bookmark is returned with the query results.
      
      Changes to statedb interface:
      
      Add 2 new methods to allow parameters to be passed to the range and rich
      query methods.
      
      GetStateRangeScanIteratorWithMetadata(namespace string, startKey string,
      endKey string, metadata map[string]interface{})
      (ResultsIterator, error)
      
      ExecuteQueryWithMetadata(namespace, query string, metadata map[string]interface{})
      (ResultsIterator, error)
      
      Changes to statecouchdb (range query):
      
      Add concept of  limit as a query parameter.  If limit is set, then queries
      are executed and returned using limit.  A nextStartKey is also
      returned which will allow the nextStartKey to passed as a parameter to the next
      query.  This implements an "explicit" paging.
      
      If no limit is specified, then the query scanner will use the nextStartKey
      internally to page through the results, using the queryLimit to control the
      query size to CouchDB. This implements an "implicit" paging.
      
      Changes to statecouchdb (rich query):
      
      Add concept of  limit as a query parameter.  If limit is set, then queries
      are executed and returned using limit to control size.  A bookmark is also
      returned which will allow the bookmark to passed as a parameter to the next
      query.  This implements an "explicit" paging.
      
      If no  limit is specified, then the query scanner will use the bookmark
      internally to page through the results, using the queryLimit to control the
      query size to CouchDB.  This implements an "implicit" paging.
      
      Change-Id: I2b2e70b3302120291bd2243d90e6c6402b70e399
      Signed-off-by: default avatarChris Elder <chris.elder@us.ibm.com>
      ca152f26
  19. 24 Aug, 2018 2 commits
    • Matthew Sykes's avatar
      [FAB-11684] serialization in ram ledger simpleList · 4616c214
      Matthew Sykes authored
      
      
      Change-Id: I79355d46daa9d2495edc1779dc3aed816cd6a284
      Signed-off-by: default avatarMatthew Sykes <sykesmat@us.ibm.com>
      4616c214
    • Matthew Sykes's avatar
      [FAB-9131] wire zap based fabric logger · 97215fa6
      Matthew Sykes authored
      
      
      Replace go-logging with a zap based implementation. The implementation
      is mostly compatible with the legacy format but differs in a two key
      ways:
      
      1. CRITICAL and NOTICE log levels no longer exist. Calls to Critical get
         mapped to error and NOTICE gets mapped to INFO. The methods
         associated with these levels will be removed in a future CR.
      2. The log level constants are now sourced from the zap/zapcore packages.
         These values are incompatible wit the go-logging constants. Please be
         sure to use the appropriate constant when necessary.
      
      The existing go-logging package is still used by the chaincode shim to
      reduce the risk of negatively impacting legacy chaincode.
      
      Change-Id: Iaf5fac807244883a8285892ccd350c5256959782
      Signed-off-by: default avatarMatthew Sykes <sykesmat@us.ibm.com>
      97215fa6
  20. 15 Aug, 2018 1 commit
    • Will Lahti's avatar
      FAB-7382 Remove ReadyChan() from Deliver ledgers · a9e8cd71
      Will Lahti authored
      
      
      This CR reworks the ledger interfaces and implementations
      used by the Deliver service to remove the ReadyChan() function,
      which has not been used since FAB-7273 was merged. The
      chainSupport struct for the peer is also updated to only
      include the ledger. The file ledger is now returned when
      Reader() is called by the deliver service.
      
      FAB-7382 #done
      
      Change-Id: I6d08f30b9093ec3120cdeee749aa51afe54e2cdc
      Signed-off-by: default avatarWill Lahti <wtlahti@us.ibm.com>
      a9e8cd71
  21. 17 Jul, 2018 1 commit
  22. 16 Jul, 2018 1 commit
    • Jason Yellick's avatar
      FAB-10292 Update protobuf to v1.1.0 · 03104e71
      Jason Yellick authored
      
      
      Protobuf was slated to be updated already, but there is a long list of
      incompatibilities with the current source tree.
      
      Thi CR updates protobuf to v1.1.0, and addresses those
      incompatibilities.  Most of the changes are quite rote and fall into one
      of three buckets.
      
      1. Code which uses non-keyed field initialization.  (ie, initializing a
      struct like MyStruct{value1, value2, value3}).  The newer generated
      protos produces structs which have additional non-field members.
      Structs should always be initialized with named fields, regardless of
      whether they are protos or not.
      
      2. Code which assumes that reflect.DeepEqual between two protos with the
      same fields will return true.  This has never been the case, especially
      when considering protos with slice or map fields, but with proto v1.1.0
      with the addition of caching and other members to the proto structs, it
      is even less true.  The correct call is proto.Equal.
      
      3. Code which assumes that proto fails on bad inputs -- the proto spec
      has always stated that failure _may_ occur, not that it must.  Certain
      code would attempt to determine proto message type based on failure to
      unmarshal, which was unsafe in v1.0.0, but is even more likely to cause
      problems in v1.1.0.
      
      4. On average, half of gossip identity digests aren't valid UTF8 strings,
         and proto v1.1.0 now enforces UTF8 validity checks for string fields.
         Therefore, the field was converted to bytes.
      
      Change-Id: I74cc037903137705dbe3f4e27e34d1307596db3b
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
      03104e71
  23. 07 Jul, 2018 1 commit
    • Jason Yellick's avatar
      FAB-11094 Fix deadlock in block iterator · 375995ea
      Jason Yellick authored
      
      
      The deliver service used to not close ledger iterators until after a
      block had been committed.  With FAB-10799, the Deliver service more
      proactively cleans up ledger resources.  This leads to a more likely
      contention between the block iterator's Close() function and the Next()
      function.
      
      These two code paths acquire the same two mutexes, but in different
      orders.  The Next() path always acquires the itr.mgr.cpInfoCond.L first,
      then the itr.closeMarkerLock, while the Close() path inverts this order.
      If both Next() and Close() are invoked at the same time by goroutines,
      this can result in a deadlock where both mutexes lock and never unlock.
      
      This further prevents all blocks from committing and begins to leak
      memory resources.
      
      Change-Id: I99180fec2639a62cdf1cd9a6ce8b33f91ce498b9
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      375995ea
  24. 02 Jul, 2018 1 commit
  25. 08 Jun, 2018 1 commit
    • manish's avatar
      [FAB-8557] Fix overwriting txid in block index · f6c97e0f
      manish authored
      
      
      This CR fixes the current behavior of block store index.
      In the current implemetation, the indexes that maintain
      different pieces of information by txid are overwritten
      by a duplicate txid (if any). This CR reverses this behavior
      and keeps the first appearance of txid in the index. The future
      duplicate txids will not overwrite it.
      
      Though, either of these behaviors (keeping the first tx or
      keeping the last tx) are not fully justified, primarily because
      the problem itself is a paradox - in the sense that the ids
      (that are supposed to be unique by definition) are duplicated.
      However, the justification of moving from the current behavior
      to the proposed behavior is that, its easy for someone to replay
      the transaction or simply use an existing txid in a bogus transaction
      just to exploit the current behavior of overwriting the block storage
      index and preventing the legitimate user to query about the status
      of their transactions.
      
      Change-Id: I3b81ae61c756ef78253b58a94644778716fb0e16
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      f6c97e0f
  26. 04 Jun, 2018 1 commit
  27. 24 May, 2018 1 commit
  28. 21 May, 2018 1 commit
    • Chris Elder's avatar
      [FAB-7779] CouchDB indexes for private data · 9a3b1811
      Chris Elder authored
      
      
      Any couchdb indexes defined for a chaincode will be deployed in
      the chaincode state database.  Indexes for collections of private
      data should be applied in the chaincode's collection state database
      rather than in the chaincode state database.
      
      Added support for HandleChaincodeDeploy event to common_storage_db.  This
      will now process the event from chain code deploy.  The move was necessary
      for handling the private data namespace mapping.
      
      Added new function to statecouchdb for processing index creation.
      
      Added new interface to statedb for IndexCapable.  This allows the
      common_storage_db to detect that the state database will accept index
      creation events.
      
      Updated index validation to allow for indexes under collections directories.
      
      Change-Id: Icfda923c584d953ce5886023f7411bbddb59d595
      Signed-off-by: default avatarChris Elder <chris.elder@us.ibm.com>
      9a3b1811
  29. 01 May, 2018 1 commit
    • Alessandro Sorniotti's avatar
      [FAB-6381] Secure defaults for txsFilter · 53de0781
      Alessandro Sorniotti authored
      
      
      The aim of this change set is to apply the well-established "Secure by
      default" security principle to the way the validator validates transactions
      in a block.
      
      The current code behaves as follows: create an array of validation codes, set
      by default to "all transactions are valid"; then perform validation which may
      mark transactions as invalid. Furthermore, in other parts of the code, if no
      array of validation codes is yet persent in the block, a new one is
      indiscriminately created (again, marking all transactions as valid). This
      approach is a security anti-pattern because it opens up to attacks where an
      adversary may force the code through a path where the default "tx is valid"
      validation code is maintained even for invalid txes.
      
      This change set ensures that validation code arrays are created and set to a
      new value (TxValidationCode_NOT_VALIDATED) which ensures that a transaction
      that hasn't been validated cannot be mistaken for a valid one.
      
      Change-Id: I5dbb18dd77af3cd14b168042ae660e4e27bf29dd
      Signed-off-by: default avatarAlessandro Sorniotti <ale.linux@sopit.net>
      53de0781
  30. 17 Apr, 2018 1 commit
  31. 16 Apr, 2018 1 commit
  32. 03 Apr, 2018 1 commit
  33. 01 Mar, 2018 1 commit
  34. 07 Dec, 2017 2 commits
    • Will Lahti's avatar
      [FAB-7273] Update deliver to facilitate usage on peer · c39d69bd
      Will Lahti authored
      
      
      This CR updates the deliver functionality to facilitate its usage on
      a peer as well as an orderer.
      
      This required:
      - modifying the signal logic for when a new block is available due to
       the difference in addition of blocks to the ledger between the orderer
       and the peer. The signal logic is now handled using the iterator
       itself, which signals when it finds a new block
      - adding a policy variable to the deliver handler to ensure the peer
      and orderer each can control access to deliver
      
      Change-Id: Iebb6c25a8c5ac32d65f909eb0519f26bfde0dc31
      Signed-off-by: default avatarWill Lahti <wtlahti@us.ibm.com>
      c39d69bd
    • Will Lahti's avatar
      [FAB-7048] Move deliver from orderer to fabric/common · 0dfe4f35
      Will Lahti authored
      
      
      This CR moves deliver from the orderer to fabric/common. This is being
      done to support the future implementation of deliver on the peer.
      
      Change-Id: If077f2c05b5a10fdeb4e6ac315111495304e4c5e
      Signed-off-by: default avatarWill Lahti <wtlahti@us.ibm.com>
      0dfe4f35
  35. 04 Dec, 2017 1 commit