3100
commented
3 years ago Hi @himankgupta31,
Each ledger needs to implement a light client for HLF. Fabric-IBC provides some modules for cosmos/tendermint and HLF.
In our current design, the light client uses an independent policy to verify updates. We named it IBC Policy. This policy is separated from Endorsement Policy and is specified when the client is created.
When the chaincode is updated on the Fabric side, as in the scenario you pointed out, it will be necessary to update the client's ChaincodeInfo, which manages the chaincode version: https://github.com/datachainlab/fabric-ibc/blob/c2eaee7a3314e9b98e3936d4d0d691cbce5f7e5f/x/ibc/light-clients/xx-fabric/types/fabric.pb.go#L215
Please refer to the following for verification of the Header: https://github.com/datachainlab/fabric-ibc/blob/c2eaee7a3314e9b98e3936d4d0d691cbce5f7e5f/x/ibc/light-clients/xx-fabric/types/update.go#L17
There are several reasons for not using the Endorsement Policy directly. For example, depending on the implementation of chaincode, the Endorsement Policy may be applied dynamically at invoke time. Also, it is difficult to synchronize when the endorsement policy changes.
Hello community
I want to know how do you run the Fabric light client on other's Blockchain? Furthermore, in standard IBC protocol, the light client uses Merkle Proof to verify cross-chain block, which is based on the Tendermint consensus algorithm.
According to my understanding of the current code of Fabric-IBC, we want to use Fab_Proof, which is primarily verifying endorsement policy through chain-code. My concern is that chain-code implementation is to keep on changing. How do we update chain-code on the light client, which does not have any access to a full node running on HLF as per IBC protocol?
Please correct me if my understanding is wrong. Thank you very much.