Right now all logic is in go, but we want to support light clients in other languages. The two most important are javascript for the browser and C/C++ so we can call it from an abci app in various languages (most languages can call a C api), in order to support IBC from different abci apps. Here is info need to port to another language.
This package just relates to verifying a header. The second part (in basecoin) is proving that a key-value pair belongs to the header via a merkle-proof that matches the root hash stored in the header.
With known validator set
StaticCertifier makes use of the tendermint/types package to verify a header if we have a known, trust validator set. It needs to hash the header and extract the fields (go-wire) as well as verify the signatures (go-crypto). Look at the relavent code
Updating validator sets
If we know a validator set, but it changes by a small fraction, we can securely update to the new validator set without running any transactions, just by assuming that we don't have 2/3 Byzantine actors (which is necessary for all light-client proofs). This is done in DynamicCertifier. It builds on the static certifier and adds a check to update from one validator set to a new one.
There are other files (centered around InquiringCertifier) which involve storing proofs to the file system, querying the tendermint rpc for the info, and dynamically querying for data as needed. These are very useful for light clients on a machine, but for IBC, a client must gather and post the data, so we only need the two above classes.
The proofs
This will only help prove that a header is indeed correct and belongs to the given chain, once a root of trust (eg. genesis file or trusted header) is given. There is another step to verify a merkle proof that matches that header, but it just involved hashing data, which should be simpler than this logic.
If you wish to implement this, please add any comments to this issue to get a dialogue on how best to proceed. One could also try to wrap a go library into a C ABI which is much less work than porting it all, but less performant.
Right now all logic is in go, but we want to support light clients in other languages. The two most important are javascript for the browser and C/C++ so we can call it from an abci app in various languages (most languages can call a C api), in order to support IBC from different abci apps. Here is info need to port to another language.
This package just relates to verifying a header. The second part (in basecoin) is proving that a key-value pair belongs to the header via a merkle-proof that matches the root hash stored in the header.
With known validator set
StaticCertifiermakes use of thetendermint/typespackage to verify a header if we have a known, trust validator set. It needs to hash the header and extract the fields (go-wire) as well as verify the signatures (go-crypto). Look at the relavent codeUpdating validator sets
If we know a validator set, but it changes by a small fraction, we can securely update to the new validator set without running any transactions, just by assuming that we don't have 2/3 Byzantine actors (which is necessary for all light-client proofs). This is done in
DynamicCertifier. It builds on the static certifier and adds a check to update from one validator set to a new one.Please look at the relavent code
Active queries
There are other files (centered around
InquiringCertifier) which involve storing proofs to the file system, querying the tendermint rpc for the info, and dynamically querying for data as needed. These are very useful for light clients on a machine, but for IBC, a client must gather and post the data, so we only need the two above classes.The proofs
This will only help prove that a header is indeed correct and belongs to the given chain, once a root of trust (eg. genesis file or trusted header) is given. There is another step to verify a merkle proof that matches that header, but it just involved hashing data, which should be simpler than this logic.
Please take a look at the corresponding issue in the basecoin repo
TODO
If you wish to implement this, please add any comments to this issue to get a dialogue on how best to proceed. One could also try to wrap a go library into a C ABI which is much less work than porting it all, but less performant.