WIP: Solidity Implementation

[mossid]

No description provided.

[ethanfrey]

Wow, interesting work.

I will cut a v0.2.0 with the current protobuf spec (which you used).

Can you add some commands in the readme I can use to run the test code?
I am happy to add this to the (to be added) CI as well, so I can check it faster

[cwgoes]

bump @mossid @ethanfrey - this is very interesting (glad to review if you like).

[ethanfrey]

Thanks for the bump, I didn't notice this was ready

[ethanfrey]

@mossid Code looks good and good reuse of test cases. I need to dig in deeper, but a few meta-comments (on layout not solidity code)

But first, can you remove WIP if this is ready for review?

[ethanfrey]

I don't like adding the ethereum dependency to go.mod/go.sum for the pure go implementation. It seems to be impossible to separate out release/test dependencies with go mod (golang/go#26913), but maybe you can do what I did for the other one, base your go.mod in confio/ics23/sol and keep the deps separate (they are just for testing, right?)

• Huge go.mod in root now: https://github.com/confio/ics23/pull/12/files#diff-37aff102a57d3d7b797f152915a6dc16
• confio/ics23/go now depends on go-ethereum: https://github.com/confio/ics23/pull/12/files#diff-9998b2a22798a81c1fd814c2d90ad3da

I'm actually not sure about licenses since go-ethereum is GPL, so definitely do not want to import it in Apache license production code. I'm fine with it in the test code for solidity, but the import should be nowhere else.

[ethanfrey]

I can see the solidity code in sol/ics23.sol, and that it is converted to go code for testing in sol/ics23_contract.go, but... where is the step to do that transform?

Can you add a Makefile (or at least a README with the commands)? Nice to help for reproducing. Also if I change a line of solidity, I want to re-run the tests.

[ethanfrey]

Please add a job to .circleci/config.yml to run the tests in the solidity folder. Ideally this also compiles the solidity to the ics23_contract.go file, so we ensure that we really are approving this exact solidity code.

[ethanfrey]

I'll take a deeper code dive likely Monday. It would be great if you could do some of this cleanup first, so I just test the solidity implementation.

I kind of feel that there is better support for testing solidity in javascript. I have used https://github.com/xf00f/web3x before as it was typescript and had some nice compilation steps and all, but I know there is a wide array of tools. Not to say the go-ethereum tests are not valid, just that it might be easier to do the code-test-debug cycle with another framework.

In the end, the only real artifact of this is the *.sol files, not the test harness, so if it is documented and runs on the CI, I am fine with it. Just a suggestion if it is easier.

[mossid]

I don't like adding the ethereum dependency to go.mod/go.sum for the pure go implementation. It seems to be impossible to separate out release/test dependencies with go mod (golang/go#26913), but maybe you can do what I did for the other one, base your go.mod in confio/ics23/sol and keep the deps separate (they are just for testing, right?)

• Huge go.mod in root now: https://github.com/confio/ics23/pull/12/files#diff-37aff102a57d3d7b797f152915a6dc16
• confio/ics23/go now depends on go-ethereum: https://github.com/confio/ics23/pull/12/files#diff-9998b2a22798a81c1fd814c2d90ad3da

I'm actually not sure about licenses since go-ethereum is GPL, so definitely do not want to import it in Apache license production code. I'm fine with it in the test code for solidity, but the import should be nowhere else.

Agreed, the ethereum imported code is used for test contract deployment and hash functions. It certainly can be separated and remove the dependency on root go.mod.

I can see the solidity code in sol/ics23.sol, and that it is converted to go code for testing in sol/ics23_contract.go, but... where is the step to do that transform?

Can you add a Makefile (or at least a README with the commands)? Nice to help for reproducing. Also if I change a line of solidity, I want to re-run the tests.

I used Native Dapps, will add a makefile.

Please add a job to .circleci/config.yml to run the tests in the solidity folder. Ideally this also compiles the solidity to the ics23_contract.go file, so we ensure that we really are approving this exact solidity code.

👍

I'll take a deeper code dive likely Monday. It would be great if you could do some of this cleanup first, so I just test the solidity implementation.

I kind of feel that there is better support for testing solidity in javascript. I have used https://github.com/xf00f/web3x before as it was typescript and had some nice compilation steps and all, but I know there is a wide array of tools. Not to say the go-ethereum tests are not valid, just that it might be easier to do the code-test-debug cycle with another framework.

In the end, the only real artifact of this is the *.sol files, not the test harness, so if it is documented and runs on the CI, I am fine with it. Just a suggestion if it is easier.

I am not that familiar with Javascript, I think we can use the current codebase and switch it to javascript later(I agree that javascript has better support on solidity testing and we should switch to it)

[ethanfrey]

@mossid The comment sounds good. Did you have time to work on this? (I know you've been busy with DevCon and IBC work)

[mossid]

Working on this PR for future ibc-eth integration

[ethanfrey]

Working on this PR for future ibc-eth integration

@mossid I think the types changed since you worked on this. They are quite stable now. You may want to restart with proper types?

[lightyear15]

Is it possible to resume this PR?
I will be happy to take over and dive into the implementation to help this landing and get merged

[ethanfrey]

@lightyear15 question: what EVM are you targeting?

It would be interesting for the proof verification to happen in solidity (it just needs hashes, not sig verification). However, for this really to make sense in IBC world, the same chain would have to provide valid Merkle proofs that the other side could parse.

ICS23 doesn't support the Patricia Merkle Trie of Ethereum 1.0 as a choice, as that was so under-specified and variable (the last hash may be a leaf node, may be an inner node with 2 leafs...). Al relevant code to handle that was GPL, and even copying that GPL code into a demo repo, I had a very hard time making a proof verifier...

If you are looking at some Ethereum 2.0 implementation using SMT or such, that should be possible to represent with ics23 (I have not tried, but I looked at the spec when implementing ics23)

[lightyear15]

Thanks @ethanfrey for the prompt response.
I am targeting an ethereum-based evm and it would come really in hand to have an ics23 proof verification library for solidity, so that my smart contract can prove tendermint commitments.

Regarding ICS23 and Patricia Merkle Trie for Eth1.0, I already realised how infeasibile seems to be converting a Patricia Merkle proof into a ICS23-compliant ProofSpec.

However, I would argue that looking at the current implementation of cosmos/ibc-go module, this is not necessary.
I understand that both specifications and code require any client to provide an ics23.ProofSpecs structure to verify counterparty's committments.

Nevertheless, from my observation, no code uses that method in the ClientState interface. As a matter of fact, specification document for ICS06-solomachine does not mention anything about ICS23-compliant commitment proof and code shows that the function is simply ignored.
The real deal about verifying states and committments on the counterparty networks are provided by the functions listed in here and in here ( and followings).

In my hypothetical use case, where I am adding new client type into the cosmos/ibc-go module, the client can ignore the getProofSpecs function, the same way ics06-solomachine does, and then implement the verify_XYZ functions, tailored around Patricia Merkle Trie proofs.

Am I completely off the track?
Am I just exploiting an inconsistency on the ICS documents / code which I shouldn't?

[ethanfrey]

Solo machines are based on trusting one signature. I mean, kind of like a poor bridge (unless you use threshold crypto to shard that signature). You should not use that design for blockchain-blockchain.

We could add some custom Ethereum Patricia Trie verification functions in all 3 languages (after spec'ing it out well) and then make a new release with a version bump. This version bump would need to be tied to a breaking change in the ibc implementation (eg ibc-go 3). Then one could use that.

[ethanfrey]

I would check with the IBC team from IG maybe they have some ideas I haven't thought about

[lightyear15]

Thanks @ethanfrey,
I mentioned ICS06-solomachine not because I am following that design for my project but because it was the quickest way to show you that the GetProofSpecs function in the ClientState interface is basically irrelevant.

It was easier that way rather than asking you to git clone the repo and grep for GetProofSpecs function just to show you that the function is never called anywhere.

Thanks again,
I will get in contact with the IBC team then.

[lightyear15]

Hi @ethanfrey ,
regardless of the ics23 and Patricia Merkle Trie issue
Do you see any issue in me picking up this PR and carry on the work? I would love to have an ics23 proof verification implementation in solidity.
Besides the rebase and conflict resolution, do you see any missing work?

[ethanfrey]

I have not reviewed this code, but if you want to take this over (or start from scratch using this as a reference), I am happy for the contribution.

If there are some CI tests for Solidity, that would be great

[AdityaSripal]

Hello @lightyear15 , thank you for the detailed writeup. As you say, we do not currently use GetProofSpecs interface externally.

We do use the ProofSpecs in ValidateSelfClient during the connection handshake: https://github.com/cosmos/ibc-go/blob/main/modules/core/02-client/keeper/keeper.go#L301

We discussed keeping the interface public so that we can use it when we relax the ValidateSelfClient function to also accept WASM tendermint clients. However, this would still require casting to a specific client type to perform our other checks so keeping ProofSpecs in the interface is not so useful.

We are planning to greatly reduce the interface for ClientState and put all responsibility on individual client implementations.
This is discussed in the WASM spec PR. That discussion kept GetProofSpecs as part of the interface as mentioned above, but given the necessity of casting to particular client types, it is going to be removed as well.
cosmos/ibc#571 (comment)

For now, you can ignore the GetProofSpecs method and use your own verification method for Patricia tries as you say. Note this will require you to implement your own proof verification functions rather than using the generic merkle proof verifier provided in ics23.

[ethanfrey]

Closing in favour of #58