1. 26 Oct, 2016 1 commit
  2. 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>
  3. 21 Oct, 2016 1 commit
    • Gregory Haskins's avatar
      Revert "... uses hardcoded hashcode for example02" · e3fe1e09
      Gregory Haskins authored
      This reverts commit 5d9a3eab
      chaincode_example04 calls chaincode_example02 via a hard-coded ID.
      This is intentional to catch change to the ID when NOTHING in
      chaincode_example02 or in its folder changes.  ie, a test for the
      constancy of the hash generation algorithm.
      The patch attempt pass the ID as a parameter to prevent accidental
      changes to chaincode_example02 from causing test failures. While
      well-intented, this subverts the above reasoning behind the
      Also note that chaincode_example05 does take the argument as a
      parameter (so that usage is already covered).
      Change-Id: I8e305efb6fd577bc7d7e3d720d293cfb0e3c191f
      Signed-off-by: default avatarGreg Haskins <gregory.haskins@gmail.com>
  4. 19 Oct, 2016 1 commit
  5. 14 Oct, 2016 1 commit
  6. 03 Oct, 2016 1 commit
  7. 02 Oct, 2016 1 commit
    • Srinivasan Muralidharan's avatar
      FAB-437 bare-minimum, end to end skeleton using solo · d632e74a
      Srinivasan Muralidharan authored
      The main purpose of this checking
        . show commit followed by simulation in action
        . users can get a feel for the flow of the protocol across
          the different legs of the end-end path
        . identify key areas for attention (esp. grep for
      "deploy and "invoke" Chaincode commands from CLI will also
      convert a successful proposal response into a transaction
      and send it to the Orderer (if configured in core.yaml).
      "query" is removed from CLI. Invoke can also return values
      now in ProposalResponse.Response.Payload.
      REST calls should not be affected and should work with
      old ledger.
      See core.yaml for default orderer setup.
      This also introduces a stop-gap "committer" whose only
      task is to commit blocks from the orderer.
      To test :
      1. Terminal 1 - run the "solo" orderer
         cd fabric/orderer
         go build
      2. Terminal 2 - run the peer
         peer node start 1>/tmp/peer.out 2>&1
      3. Terminal 3 - deploy and invoke take usual params
         peer chaincode deploy ... 1>/tmp/out 2>&1
         peer chaincode invoke ... 1>/tmp/out 2>&1
      /tmp/peer.out and /tmp/out will contain tell tale signs
      of the round trip in action.
      Change-Id: Ic1aa31993fc57ce145c39967d4d682fd2dc5704b
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
  8. 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>
  9. 22 Sep, 2016 1 commit
    • Srinivasan Muralidharan's avatar
      skeleton Endorser implemention with a CLI driver · ec50ad17
      Srinivasan Muralidharan authored
      This patch is for https://jira.hyperledger.org/browse/FAB-181
      The patch is around endorser.go which implements the basic
      Endorser service. The "peer deploy ..." and "peer invoke .."
      CLI driver commands have been modified to redirected to use
      endorser.ProcessProposal instead of the original "devops"
      The deploy, invoke (and query) CLI calls are unchanged in
      non-dev mode from user point of view - but for one difference.
      The response is a ProposalResponse.
      In dev mode (ie, when peer is started with --peer-chaincodedev)
      the deploy command would need to set "CORE_CHAINCODE_MODE=dev"
      in the "peer chaincode deploy ..." command. This is because, the
      command now computes the chaincode code just like the SDK as
      opposed to leaving it to be done by devops in the peer. Example
      CORE_CHAINCODE_MODE=dev CORE_LOGGING_LEVEL=debug ./peer chaincode
      deploy -n mycc -c '{"Args":["init","a","100","b","200"]}'
      Change-Id: Ie6e44cef880bfcbeb7619f135566a7dce9dcdbc2
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
  10. 19 Sep, 2016 2 commits
    • Gregory Haskins's avatar
      Use ccenv docker image rather than baseimage · 79b70e41
      Gregory Haskins authored
      We want baseimage to only be used as a mechanism to assist
      the build, not referenced at runtime.  Therefore, we
      convert most instances of "baseimage" to use "ccenv"
      (chaincode environment) since this is what they really want
      Note 1: A few instances (such as the UTXO example) did not have
      an obvious solution so I left those to be sorted out by
      the respective subsystem owners.
      Note 2: The GOLANG chaincode type is currently a little suboptimal
      in that the fabric-ccenv image loads the full fabric.git src
      at build time and then the runtime re-injects it.  In the future
      the build will only inject the golang shim and the runtime will
      only inject the chaincode.  For now, this is somewhat inefficient
      but ultimately still results in correct behavior.
      Change-Id: I7f025bfff147fcca0f29f1656c7f63adc7a17173
      Signed-off-by: default avatarGreg Haskins <gregory.haskins@gmail.com>
    • Gregory Haskins's avatar
      Remove defunct peer.Dockerfile from *test.yaml · fb6f59ba
      Gregory Haskins authored
      This doesn't seem to be used any more, and we want to
      prepare for cleaning up references to baseimage later
      in the series.
      Change-Id: If68586b8b30c2d81a27be37cfd7d002300403d79
      Signed-off-by: default avatarGregory Haskins <gregory.haskins@gmail.com>
  11. 17 Sep, 2016 1 commit
    • Srinivasan Muralidharan's avatar
      chaincode life-cycle system chaincode for a chain · a3687a1f
      Srinivasan Muralidharan authored
      The life-cycle system chaincode (lccc) manages chaincodes for a chain in an
      endorser. The life-cycle is basically the "deploy", "upgrade", "stop"
      and "start" actions. This changeset provides the basic chaincode for
      creating the table of chaincodes and implements just the "deploy" command.
      This work will be developed till the basic endorser functions are fully
      This driver for this chaincode will be checked in the next changeset.
      NOTE - this change also fixes the limitation where only one system chaincode
      can be running at a time.
      This is part of the feature development of FAB-181, FAB-182, FAB-183.
      Change-Id: Iff36fee7c5b9a9ce4658910db73304a6bcd7e3d4
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
  12. 16 Sep, 2016 2 commits
    • Will Lahti's avatar
      FAB-394 Chaincode log level cannot be changed · 777bdac1
      Will Lahti authored
      These changes make sure that the logging.chaincode setting from
      core.yaml is used to set the chaincode logging level every time
      the chaincode container starts. The peer reads in the value and
      passes it to the chaincode via an environment variable as it
      does for similar values.
      Fix Issue FAB-394
      Change-Id: Ic4b7228c57fc673a97dbfafc1b086ad04c41c05c
      Signed-off-by: default avatarWill Lahti <wtlahti@us.ibm.com>
    • 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
      ). 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>
  13. 14 Sep, 2016 1 commit
  14. 13 Sep, 2016 1 commit
  15. 12 Sep, 2016 2 commits
  16. 08 Sep, 2016 3 commits
  17. 07 Sep, 2016 1 commit
  18. 06 Sep, 2016 1 commit
  19. 04 Sep, 2016 1 commit
  20. 01 Sep, 2016 1 commit
  21. 31 Aug, 2016 4 commits
  22. 30 Aug, 2016 1 commit
  23. 26 Aug, 2016 1 commit
  24. 25 Aug, 2016 1 commit
    • Gregory Haskins's avatar
      Add versioning support to our applications · 2eadb11a
      Gregory Haskins authored
      This patch introduces a more robust versioning mechanism, summarized
      as follows:
      1) The top-level makefile defines $PROJECT_VERSION which is intended
         to be consumed throughout (though some places are left for a
         future patch)
      2) The variable is expected to use Semantic Versioning with X.Y.Z for
         releases, and X.Y.Z-SNAPSHOT for intermediate development builds.
      3) We bake the $PROJECT_VERSION into the binaries (peer and membersrvc)
         at compile time and remove the yaml configuration that attempted to
         provide competing versioning.
      4) We tag our docker images (except for baseimage, that will be
         addressed later) with :$(ARCH)-$(PROJECT_VERSION), suitable for
         unambiguous long term hosting on something like dockerhub.
      5) We add support for dynamically parsing yaml-based Dockerfile
         definitions to support variable subsitution.  This allows the yaml
         to set a Dockerfile definition with something like
         "FROM foo:$(ARCH)-$(PROJECT_VERSION)" and the ...
  25. 23 Aug, 2016 1 commit
  26. 22 Aug, 2016 1 commit
  27. 19 Aug, 2016 2 commits
  28. 16 Aug, 2016 1 commit
    • Brad Gorman's avatar
      GitHub Issue #2119 - chaincode unittesting · 23afd056
      Brad Gorman authored
      Replaced ChaincodeStub with ChaincodeStubInterface to allow
      unit testing of chaincode. MockStub added to emulate a real
      chaincode without the storage or network requirements.
      Unit test examples for chaincode_example02 to 05.
      I have another changeset to address tables and certificates.
      Change-Id: I37d6115781436e080a70d5c48c1128ee01fef3ba
      Signed-off-by: default avatarBradley Gorman <bgorman@au1.ibm.com>
  29. 11 Aug, 2016 1 commit
  30. 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>
  31. 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>