Agenda:

  1. Scenario and Scope modified according to the comments. Tong will be working with the wiki admin to lock the document. a markdown document will be produced and contributed to fabric repo.
  2. When send request to an admin, what do we expect to send in the email?
    1. certs, anchor peer endpoint, names, individually or
    2. configtxgen produced json file which has everything in
  3. Once we have expanded networks, assume participaters joined SAP provided orderering system, we do some tx, things to discuss
    1. what chaincode should we try? all operations of the chaincode?
    2. tx rate, light or heavy?
    3. endorsement policy? what kind of policy should we set to these channels? Can we have an agreement on the policy so that all who provides channels can set the policy.
  4. Test progress reporting
  5. UI program, David/Dennis, when can we have the UI app?
  • No labels

5 Comments

  1. sample-cc to use for test.

    light tx, not to produce so many txs


  2. Murali commented that new org admins should use the right version of configtxgen to produce the right json file when create the new request.

  3. the endorsement policy should be set to everyone, not majority.

    1. In my memory, unlike channel policy, the endorsement policy is made by combination of AND, OR and N-of. There is not yet a syntax can support 'ALL' organization. Sure, we can concatenate all CURRENT orgs with AND, but then after a new organization is added, the chaincode level endorsement policy should be updated to include the new org via chaincode upgrade again.

      Such that my suggestion in endorsement policy design is "leave it blank and alternatively make use of key-level endorsement policy"
      https://hyperledger-fabric.readthedocs.io/en/release-1.4/endorsement-policies.html#setting-key-level-endorsement-policies
      pros:

      • not need to set chaincode level endorsement any more
      • another high priority layer covering existing  endorsement policy
      • policy could be adjusted online via invoke transaction

      cons:

      • lazy load of endorsement policy: only transaction writing to specific key will ask for chaincode alignment.
      • Only "AND"  is supported to describe endorsing logic among organizations
  4. chaincode format, suggested source code vs cds. cds seems to be the preferred format.