1. 03 Feb, 2017 1 commit
    • manish's avatar
      Move Blockstorage code under /fabric/common package · 2a16532c
      manish authored
      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>
  2. 01 Feb, 2017 1 commit
  3. 30 Jan, 2017 2 commits
  4. 27 Jan, 2017 2 commits
  5. 26 Jan, 2017 3 commits
  6. 25 Jan, 2017 2 commits
  7. 20 Jan, 2017 4 commits
  8. 19 Jan, 2017 3 commits
  9. 18 Jan, 2017 2 commits
  10. 17 Jan, 2017 8 commits
  11. 16 Jan, 2017 3 commits
    • YACOVM's avatar
      FAB-1683 configtx.Items() doesn't set header type · bc3ee877
      YACOVM authored
      Items() was not setting the type of the chain header properly
      as was configured in the inner fields of the template.
      Since this code works only for configuration items,
      I just set it to HeaderType_CONFIGURATION_ITEM.
      Also changed the template_test to accomodate the change.
      Signed-off-by: default avatarYacov Manevich <yacovm@il.ibm.com>
      Change-Id: I24ea3ada0e3df34fd2fbe0250cafd37f068f23e8
    • Alessandro Sorniotti's avatar
      [FAB-1639] [FAB-1580] Rework validator · ae10d2b6
      Alessandro Sorniotti authored
      This change-set has removed calls to the txvalidator that were issued right
      after the peer (the leader) receives blocks from the orderers. The validator
      is now called to validate messages received from the gossip layer. In order
      to fix an import cycle, we have introduced the ChaincodeProvider interface
      in core/common/ccprovider/ccprovider.go, an implementation and a factory.
      This way, code that needs to use functions from the chaincode package
      without importing it can simply use (and possibly extend) the
      ChaincodeProvider interface and implementation.
      Furthermore, this drop has introduced protocol-level message validation for
      config transactions that was lacking before.
      Change-Id: I5906a6fe3da8410b05b5079dd7f0b9d28d20bb85
      Signed-off-by: default avatarAlessandro Sorniotti <ale.linux@sopit.net>
    • Srinivasan Muralidharan's avatar
      orderer.template has to regenarated · ade72586
      Srinivasan Muralidharan authored
      orderer.template has to be regenerated to include BatchSize
      Change-Id: I401cb88247f481e649394fa44ae572dc280432e9
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
  12. 15 Jan, 2017 1 commit
    • Srinivasan Muralidharan's avatar
      FAB-1547 initial create/join chain support · a93135b1
      Srinivasan Muralidharan authored
      With this change the fabric has basic support for create / join
      chain begun with the implementation of CSCC (configuraton system
      chaincode) in https://jira.hyperledger.org/browse/FAB-1022.
      Some todos remain for follow up CRs
        . docker based commands to channel-setup.md
        . CONFIGURATION_TRANSACTION validation - https://jira.hyperledger.org/browse/FAB-1639
        . further MSP integration (still uses default MSP)
        . absorption of deliver client management into gossip later - https://jira.hyperledger.org/browse/FAB-1580
        . adding specific configuration items to channel create - https://jira.hyperledger.org/browse/FAB-1642
      Steps to test chain create / join below. All commands assume shell
      in "fabric/" directory.
      Vagrant window 1 - start orderer
        cd orderer
        ORDERER_GENERAL_LOGLEVEL=debug ./orderer
      Vagrant window 2 - ask orderer to create a chain
        cd peer
        peer channel create -c myc1
        #on successful creation, a genesis block myc1.block is saved
        #in the same directory
      Vagrant window 3 - start the peer without **TEST_CHAINID**
                         (basically in a "chainless" mode)
        #to start with a clean env do "rm -rf /var/hyperledger/*"
        cd peer
        peer node start --peer-defaultchain=false
        #in "--peer-defaultchain=false" mode the peer has to join
        #chains to create leader and do transactions. It does not
        #have a default chain or ledger (the **TEST_CHAINID** chain)
      Vagrant window 4 - ask peer to join a chain
        cd peer
        peer channel join -b myc1.block
      At this point we can issue transactions
      Vagrant window 2 - deploy a chaincode to myc1
        cd peer
        peer chaincode deploy -C myc1 -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Args":["init","a","100","b","200"]}'
        #note the use of "-C myc1"
        #wait for 10 secs or so
      Vagrant window 2 - query chaincode
        cd peer
        peer chaincode query -C myc1 -n mycc -c '{"Args":["query","a"]}'
      Change-Id: I7d1d04e8a207eb57597a1e6eb8b986e1080e7811
      Signed-off-by: default avatarSrinivasan Muralidharan <muralisr@us.ibm.com>
  13. 13 Jan, 2017 4 commits
  14. 12 Jan, 2017 1 commit
    • Alessandro Sorniotti's avatar
      Integration of MSP into cauthdsl · bf2fd1d6
      Alessandro Sorniotti authored
      This change set introduces a more flexible way of describing the identity
      associated to a policy. So far we had support for serializing the
      certificate associated to the identity. We introduce a new structure that
      supports that and 3 other ways of listing identities: i) the admin of an
      MSP, ii) the CA of an MSP and iii) a valid certificate for an MSP.
      Furthermore, policy evaluation is now performed using the MSP infrastructure:
      cauthdsl receives a policy principal and an Identity instance and then it can
      use the interfaces offered by the MSP to check whether the identity satisfies
      the principal and whether the signature verifies. The semantics of policy
      verification has somewhat changed: an identity (and its signature) can be used
      to satisfy only a single principal. This has the benefit of better dealing
      with the policy "two signatures from org0", but it has the downside that a
      single identity can no longer be used to satisfy two principals (e.g. if
      we need signatures from an identity with attribute A and one with attribute
      B, a single signature from an identity with both attributes would not be
      Change-Id: Id18a5933e341781334080965b5d04dc07d4f1b99
      Signed-off-by: default avatarAlessandro Sorniotti <ale.linux@sopit.net>
  15. 11 Jan, 2017 2 commits
  16. 10 Jan, 2017 1 commit