1. 25 Oct, 2016 3 commits
  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. 23 Oct, 2016 1 commit
  4. 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>
  5. 19 Oct, 2016 1 commit
  6. 14 Oct, 2016 1 commit
  7. 06 Oct, 2016 1 commit
  8. 03 Oct, 2016 2 commits
  9. 02 Oct, 2016 3 commits
    • 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>
    • Christopher Ferris's avatar
      Fix FAB-578 · a96b9edc
      Christopher Ferris authored
      Fix FAB-578 incorrect chaincode signature in REST API
      fix rest_api.json
      Change-Id: If2258b09d89a79cdfa73e6897af737a5286ec436
      Signed-off-by: default avatarChristopher Ferris <chrisfer@us.ibm.com>
    • YACOVM's avatar
      Fix go-logging concurrent map read-write bug · 5f9f6a98
      YACOVM authored
      This bug sometimes fails unit tests because logging are sometimes set up
      in parallel.
      Added a RWLock to op/go-logging/level.go's moduleLeveled struct
      and it RLocks in GetLevel and WLocks at SetLevel
      Change-Id: I78e837879fece869af9a5e573930492d439a6e82
      Signed-off-by: default avatarYacov Manevich <yacovm@il.ibm.com>
  10. 01 Oct, 2016 1 commit
  11. 30 Sep, 2016 1 commit
  12. 29 Sep, 2016 1 commit
  13. 28 Sep, 2016 2 commits
    • 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>
    • manish's avatar
      Sync block index with block storage · 910e496c
      manish authored
      This commit adds the functionality of checkpointing block index progress
      and sync-ing (updating) the index during start of the block storage system
      Change-Id: Ib1a325add455bce47e510ccfc7af052db51117e6
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
  14. 27 Sep, 2016 2 commits
  15. 26 Sep, 2016 1 commit
  16. 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>
  17. 20 Sep, 2016 1 commit
    • manish's avatar
      Disable WAL for block storage DB · 0df6a8d1
      manish authored
      (Rocks) DB WAL adds overheads while using the DB for saving checkpoints
      for block storage. Avoiding writing to WAL translates the write workload
      (appending blocks to the blockfile) into a sequential disk writes.
      This commit changes the way checkpoints are saved - checkpoints are
      written to DB as before, however since WAL is disabled, the checkpoint
      stays in-memory only. The in-memory checkpoint is flushed explicitly to
      disk (via DB flush) at the time of new block file creation. The in-memory
      checkpoint would implicitly also be flushed to memory at the time of DB
      shutdown. However, if a crash takes place, the checkpoint available in the
      DB would be behind the actual block file status. In order to handle this
      crash scenario, this commit also adds code to perform a scan of the block
      file beyond the last saved checkpoint and update the checkpoint.
      Change-Id: Ie88646b225abaa50b595833f5e7ed8d4facae920
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
  18. 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>
  19. 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>
  20. 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>
  21. 15 Sep, 2016 1 commit
  22. 14 Sep, 2016 2 commits
  23. 13 Sep, 2016 2 commits
  24. 12 Sep, 2016 3 commits
  25. 08 Sep, 2016 3 commits