weixin_39687301
weixin_39687301
2020-11-27 06:37

Expiration/Update of Validity Period

The logic to update the validity period is already in place:

The system chaincode validity_period_update.go is automatically deployed during genesis. It was tested following the instructions documented on this page: https://github.com/openblockchain/obc-peer/blob/master/docs/SandboxSetup.md and a unit test is provided in validity_period_test.go

The chaincodeID name (hash) obtained after deploying the system chaincode needs to be specified in the obcca.yaml configuration file.

The chaincode to update the validity period needs to be executed by an authorized party. In order to guarantee this, two extensions to the system need to be added:

The identity of the caller should be available somehow for the chaincode to perform a check. The ability to determine if the chaincode is executed directly or as a part of a nested execution of chaincodes. This is not as important as the first item, but it will be nice to have the check. The authorized party to update the validity period by invoking the system chaincode needs to be registered in the system and requires a login token that for now is hardcoded into the code (similar to the other users from the obcca.yaml configuration file).

Other than these the validity period update is working.

该提问来源于开源项目:hyperledger-archives/fabric

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

7条回答

  • weixin_39706861 weixin_39706861 5月前

    Hi diegomasini,

    Thanks for submitting this pull request!

    Please add a comment with a DCO1.1 Signed-off-by statement in order to allow us to process your pull request.

    dco-bot

    点赞 评论 复制链接分享
  • weixin_39687301 weixin_39687301 5月前

    Signed-off-by: Diego Masini damasini.ibm.com

    点赞 评论 复制链接分享
  • weixin_39966909 weixin_39966909 5月前

    The chaincodeID name (hash) obtained after deploying the system chaincode needs to be specified in the obcca.yaml configuration file.

    Wouldn't this cause chicken and egg problem? obc-ca server needs to be up prior to starting up validator, and validator build and install chaincode...

    for discussion

    点赞 评论 复制链接分享
  • weixin_39966909 weixin_39966909 5月前

    adding you guys for further discussion on this pull request as I feel the process seems clunky. Should we recommend to use CLI to build system cc to get the hash first?

    点赞 评论 复制链接分享
  • weixin_39687301 weixin_39687301 5月前

    you are right, is not the nicest solution, but we couldn't find another way to invoke the chaincode once the chaincodeID hash was introduced to perform the invocation. In the previous pull request (on gitlab) we were using the url and version of the chaincode for the invocation. Is there a different way to invoke it that prevents this chicken and egg problem? It seems that system chaincode needs to be treated specially. For the unit test we started the obc-peer so the chaincode gets deployed at genesis time on the genesis block. Then we copied the chaincodeID hash to the obcca.yaml file and started the obc-ca server. I'm adding to the discussion since he was working on this too.

    点赞 评论 复制链接分享
  • weixin_39757626 weixin_39757626 5月前

    I'm not sure I understand why the chaincode hash cannot be known prior to deployment. It contains no nonce so it would be the same every time as long as the chaincode itself was not changed.

    said the ID is the hash of {source code bytes, function name, parameters, path to code}

    点赞 评论 复制链接分享
  • weixin_39966909 weixin_39966909 5月前

    could you please resolve the merge conflict

    点赞 评论 复制链接分享

相关推荐