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. 30 Jan, 2017 1 commit
    • Binh Q. Nguyen's avatar
      [FAB-1790, FAB-1791] Chaincode calling chaincode · 1bd5b2bb
      Binh Q. Nguyen authored
      
      
      This changeset enables chaincode calling chaincode on the same channel
      or different channel read-only. The called chaincode operates in the
      same transaction context of the caller chaincode. See the chaincode
      API for details.
      
      Change shim.InvokeChaincode API to accept a channel.
      
      Fix up the chaincode_example04 so that the current unit tests can
      exercise both query and invoke.
      
      Also update a number of files for better logging, including removing
      repeating log in loop and info log in heavy transaction path.
      
      Change-Id: I9b67b91311482d7c47cf66a0849c2f29594621f5
      Signed-off-by: default avatarBinh Q. Nguyen <binhn@us.ibm.com>
      1bd5b2bb
  3. 29 Jan, 2017 1 commit
    • denyeart's avatar
      [FAB-1917] Fix chaincode query API · 44e78500
      denyeart authored
      Address review comments from:
      https://gerrit.hyperledger.org/r/#/c/4767/
      
      
      
      Updates to logging and comments per Murali's feedback.
      
      Rename ExecuteQuery() to GetQueryResult() per Binh's feedback.
      The rename is only made at the top level chaincode function
      The name change will be propagated to all the underlying
      helper functions and messages as part of a larger refactor that
      Murali has planned for post-alpha.
      
      Fix handler.go result type (KV should be QueryRecord).
      
      Tested that chaincode calls to GetQueryResult() work end-to-end.
      
      Change-Id: I9cda95bab237e03880243be0b15110d119f033e8
      Signed-off-by: default avatardenyeart <enyeart@us.ibm.com>
      44e78500
  4. 26 Jan, 2017 2 commits
  5. 16 Jan, 2017 1 commit
  6. 11 Jan, 2017 1 commit
    • Jason Yellick's avatar
      Move core/util to common/util · 289b1a29
      Jason Yellick authored
      
      
      As a matter of policy, the only imports a package should have outside of
      its base dir are protos/ vendor/ and common/.  The core/util package was
      referenced all over the code, so moving it to common seems like the best
      option.
      
      Change-Id: Ic7d797be6a1b44634480a361ae7469b794685762
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      289b1a29
  7. 29 Dec, 2016 1 commit
    • Srinivasan Muralidharan's avatar
      fab-1475 make CC fmk allow concurrent invokes · 5bdca867
      Srinivasan Muralidharan authored
      https://jira.hyperledger.org/browse/FAB-1475
      
      
      
      Summary
      =======
      With pre-consensus simulation, multiple chains and relaxation by the ledger
      to simulate versions of chaincode state concurrently, we can now allow
      chaincode framework to execute invokes concurrently. This CR enables this.
      
      This CR enables concurrency basically by removing the FSM states that
      enforced serialization (so basically all the FSM changes in chaincode/hander.go
      and chaincode/shim/handler.go).
      
      The CR also has a "Chaincode Checker" program which has the potential for
      much bigger things
         . the tooling test their chaincodes for consistency
         . the tooling for stressing the fabric
      
      The concurrency enablement was tested with the "ccchecker".
      
      Details
      =======
      The submit will basically have 4 things
        . changes to 3 chaincode framework files handler.go files
          to enable concurrency
        . concurrency_test.go to run 100 concurrent invokes followed
          by 100 concurrent queries
        . a complete "ccchecker" example framework for testing and validating
          chaincodes
        . exports some functions under fabric/peer/chaincode CLI for use by
          the above ccchecker example framework
      
      "ccchecker" comes with a sample "newkeyperinvoke" chaincode that should
      NEVER fail ledger consistency checks. To test simply follow these steps
        . vagrant window 1 - start orderer
          ./orderer
      
        . vagrant window 2 - start peer
          peer node start
      
        . vagrant window 3 - bring up chaincode for test
          cd peer
      
          //deploy the chaincode used by ccchecker out of the box
          peer chaincode deploy -n mycc -p github.com/hyperledger/fabric/examples/ccchecker/chaincodes/newkeyperinvoke -c '{"Args":[""]}'
          //wait for commit say for about 10 secs and then issue a query to bring the CC up
          peer chaincode query -n mycc -c '{"Args":["get","a"]}'
      
          //verify the chaincode is up
          docker ps
      
        . vagrant window 4 - run test
          cd examples/ccchecker
          go build
          ./ccchecker
      
      The above reads from ccchecker.json and executes tests concurrently.
      
      Change-Id: I5267b19f03ed10003eb28facf87693525f0dcd1a
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
      5bdca867
  8. 21 Dec, 2016 1 commit
    • Srinivasan Muralidharan's avatar
      FAB-1318 - complete upgrade from endorser side · 269379a0
      Srinivasan Muralidharan authored
      https://jira.hyperledger.org/browse/FAB-1318
      
      This completes the work begun with https://gerrit.hyperledger.org/r/#/c/2973
      https://gerrit.hyperledger.org/r/#/c/2945/
      
      .
      
      The command
          peer chaincode upgrade -n mycc -p <upgrade chaincode path> -c '{"Args":[<args to upgrade chaincode>]}'
      
      will upgrade exisisting chaincode "mycc" if one exists.
      
      There is still work left on the committer side to comb block
      for transactions colliding with an upgrade. Upgrade will override those
      colliding transactions for that <chain, chaincode>. This will be in
      a future CR when ledger and committer support for this work
      is available.
      
      A chaincode is uniquely identified by (chain name, chaincode name).
      When upgrading a chaincode, many versions of the chaincode may be
      running (typically 2, the "current" and the "upgrade" but one can
      imagine multiple upgrades of the same chaincode in progress. Even
      if only one will succeed...).
      
      When upgrading, LCCC bumps up the version number for that chaincode.
      This version is used to dissambiguate different versions of the
      chaincode in a chain, just as chain id dissambiguated the chaincode among
      different chains.
      
      Chaincode framework will panic if version is not specified or not found.
      
      Change-Id: Ie0e11cf4ed1263f91c8399021ea65a3e877e08ba
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
      269379a0
  9. 15 Dec, 2016 1 commit
    • Srinivasan Muralidharan's avatar
      FAB-1378 beginnings of a join command · 85b47e60
      Srinivasan Muralidharan authored
      https://jira.hyperledger.org/browse/FAB-1378
      
      
      
      "peer node start" works as before and creates the default chain.
      
      "peer node start --peer-defaultchain=false" however starts without
      a chain. It just creates the gossip service and starts up the
      peer server in a chainless, ledgerless mode. The peer is read to
      accept join calls.
      
      "peer node join -b <path to genesis block file>" calls CSCC with
      the genesis block.
      
      kvledgers is removed and the peer package is used for ledger access.
      
      CSCC is under construction but this CR allows the work to be driven
      via CLI (and later from SDK).
      
      Change-Id: Id581c1f04b8788f54be467f593d74ea6b1efe713
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
      85b47e60
  10. 12 Dec, 2016 1 commit
  11. 03 Dec, 2016 1 commit
    • Srinivasan Muralidharan's avatar
      FAB-1256 remove anchor of DefaultChain from peer · 718924ca
      Srinivasan Muralidharan authored
      https://jira.hyperledger.org/browse/FAB-1256
      
      
      
      DefaultChain was the chain that was holding together
      the flows through the fabric and was a place holder for
      full fledged chains implementation. We now remove that
         . force chainID to be passed through the system, top down
         . use the chainID as the ledgername (note the panic
           in GetLedger)
      
      Pending "join" support, the system still require a single
      ledger to be created but that is now created by specifying
      the chain at the top level (unit tests, CLI in "peer node start",
      etc).
      
      Once "join" is added, this scaffolding can be removed from CLI
      (the chaincode unit tests will likely continue to use it) when
      the complete chain initialization will be "peer join" configuration
      driven
      
      Change-Id: Ie3b64db4b9030a4cb695fb3e1075822b55a129d1
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
      718924ca
  12. 29 Nov, 2016 1 commit
  13. 28 Nov, 2016 1 commit
  14. 27 Nov, 2016 1 commit
    • Srinivasan Muralidharan's avatar
      FAB-1198-rm old pb.Transaction, pb.Block · 61affa05
      Srinivasan Muralidharan authored
      NOTE - Removing of old proto.Transaction is the cause for
      the large change set. It affects chaincode framework and
      all users of the framework such as endorser, system chaincodes,
      unit tests etc.
      
      Transaction2 is renamed to Transaction.
      Response2 is renamed to Response.
      Message2 is renamed to Message.
      
      The changes are fully described in
          https://jira.hyperledger.org/browse/FAB-1198
      
      
      
      Summary
      =======
         . Remove old Transaction and rename Transaction2
         . Cleanup of Chaincode protobuf message
         . Add TxID for SDK and higher layers to optionally
           set (currently errors if not set)
      
      ChaincodeMessage removes QUERY and QUERY_CHAINCODE enums.
      
      Shim interface does not enforce Query or QueryChaincode.
      
      chaincode_example02 and 05 implement Query function via
      the Invoke implementation.
      
      The "noop" system chaincode is removed
         . it was using Transaction which is not an endorser
           artifact any longer
         . there are many system chaincodes to that thoroughly
           test sys chaincode functions
      
      Change-Id: Ib77b7e5a6756eac47e888309816076580ae505e7
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
      61affa05
  15. 11 Nov, 2016 1 commit
  16. 28 Oct, 2016 1 commit
  17. 26 Oct, 2016 1 commit
  18. 24 Oct, 2016 1 commit
    • Srinivasan Muralidharan's avatar
      FAB-631 WIP - pared down peer for next arch work · 9eb99b3f
      Srinivasan Muralidharan authored
      
      
      Following skeletal end to end flow work, this submit
      takes the next steps for Endorser/Committer
        . converts chaincode and endorser to ledgernext
        . removes consensus package
        . chaincode unit tests use ledgernext
        . panics if ledger.GetLedger is called so we
          can catch codepaths that still use that. These
          are mainly core/api and core/peer
        . removes unit tests from core/api and core/ledger
          (to avoid GetLedger calls there)
        . created a minimal core/peernext. core/peer is
          still there for comparison but is not used
      
      Change-Id: I2627e0000e960e1aa66d27ff5ec60a38c4bb7eea
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
      9eb99b3f
  19. 03 Oct, 2016 1 commit
  20. 28 Sep, 2016 1 commit
    • Srinivasan Muralidharan's avatar
      FAB-466 integrate ledgernext with chaincode framework · 909b517a
      Srinivasan Muralidharan authored
      
      
      The ledgernext and kvledger packages provide APIs to simulate
      transactions by collecting read-write sets from invokes of
      chaincodes. This change set integrates this for the Endorser
      flows.  The main purpose of this code is to enable read write
      sets to be propagated so end to end flow ending in a commit to
      the ledger can be tested.
      
      The chaincode unit tests continue to use the old ledger. This
      allows us to (1) incrementally integrate ledger and (2) show
      that the two packages can coexist from a build and runtime
      point of view.
      
      It is worth noting that the file kv_ledgers.go hosts a temporary
      container for ledgers. This simple approach is expected to be
      revised when (sub)ledgers are implemented.
      
      Change-Id: I6e0bf4b9795b83d2ae869244b212c02ef9b5214a
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
      909b517a
  21. 16 Sep, 2016 1 commit
    • Angelo De Caro's avatar
      C2C invocation for confidential contracts. · 5f9b3ea0
      Angelo De Caro authored
      This PR addresses chaincode to chaincode invocation for confidential contracts
      (https://jira.hyperledger.org/browse/FAB-67
      
      ). In order to achieve the goal
      the chaincode handler has been modified to contruct proper ephemeral
      transactions and security contexts.
      
      Let us consider the following scenario to describe the modification
      apported by this PR. Let us say that we have two chaincodes: A and B
      where A invokes B at some point of its computation.
      When a user invoke a chaincode A, using transaction tx,
      the certificate that the user has put in tx is passed to B when A
      invokes it. In this way, for example, chaincode B can perfom
      attribute-based access control. In addition,
      each chaincode can access it is own encrypted state and modify
      it in a proper way without affecting other chaincodes' state.
      
      This PR has been tested by adding a unit test in exectransaction_test.go.
      The unit tests, verify that C2C invocation can be perfomed when
      security is enabled.
      
      What will come next:
      1. Chaincode to chaincode query.
      2. Additional fields transfered to the invoked chaincode to
      support access control based on signature.
      
      Change-Id: I649d1953ac76e8af32d917a089a454fc0bba9fc1
      Signed-off-by: default avatarAngelo De Caro <adc@zurich.ibm.com>
      5f9b3ea0
  22. 10 Aug, 2016 1 commit
    • Gabor Hosszu's avatar
      Use repeated bytes instead of repeated string for chaincode call args · fd498d2f
      Gabor Hosszu authored
      
      
      This allows applications to easily pass arbitrary blobs without having
      to serialize them to strings.  At the same time, we also consolidate
      the function argument to be part of the repeated bytes args.
      
      For convenience and to simplify porting of existing chaincode to the
      new argument format, we introduce helper functions in the shim which
      cast between ([][]byte) and (string, []string).
      
      Change-Id: I67562523a208727157c4767e86e1ef437e997f13
      Signed-off-by: default avatarGabor Hosszu <gabor@digitalasset.com>
      fd498d2f
  23. 08 Aug, 2016 1 commit
    • Gabor Hosszu's avatar
      Use SHA256 TXID instead of UUID · c950903f
      Gabor Hosszu authored
      
      
      This squashed changeset does the following:
       - It renames UUID to TXID in the code (Go/Java), in tests,
         in proto files, in all chaincode related files
       - It uses all the arguments of the chaincode to
         generate the TXID
      
      Change-Id: Iae6f1fb45c12c2652d9ad18451e75ea1f91fe9a3
      Signed-off-by: default avatarGabor Hosszu <gabor@digitalasset.com>
      c950903f
  24. 26 Jul, 2016 1 commit