Complete the make transfer command

[cmwaters]

The last command in the demo should transfer tokens from simapp to the reth rollup. This requires the following steps:

• Submit MsgTransfer to simapp commencing the process. See feat: submit MsgTransfer #50
• Update the tendermint client on the reth rollup (querying the prover process for the groth16 proof proving the simapps state transition from a previous trusted height to a new one)
• Query the membership proof of the commitment on simapp and attach that proof to the transfer packet that needs to be sent to the reth rollup (I think to the router smart contract)
• Update the groth16 Client on simapp by using the prover process running over the reth node
• Now query the MPT membership proof on the reth node of the acknowledgement commitment and embed it in the acknowledgement packet that needs to be submitted on simapp.
• Query the balances and assert that the tokens have correctly been transferred.

[rootulp]

AFAIK this is blocked on #30 because the clients and channel need to be set up before we try to update the clients and use the connection.

I can explore creating a mock client and channel if #30 isn't ready yet cc: @ninabarbakadze

[cmwaters]

Yes you won't be able to test this flow until #30 is completed but I think you can already write most of the code

[cmwaters]

I think you can get a lot of inspiration from: https://github.com/cosmos/solidity-ibc-eureka/blob/main/e2e/interchaintestv8/ibc_eureka_test.go

[rootulp]

Submit MsgTransfer to simapp commencing the process

Nina already wrote logic for broadcasting + confirming transactions inside #34. May need to generalize it.

Update the tendermint client on the reth rollup (querying the prover process for the groth16 proof proving the simapps state transition from a previous trusted height to a new one)

1. Query the prover GRPC service that Callum just wrote. It is running on port 50051. Need a README or demo on how that works. There is Go client code for this already.
2. Submit a tx on the Reth roll-up to the tendermint light client with the proof. Invoke sp1ics07tendermint's NewContract so that we can call... (needs more research).

Steps 2 - 5 use proofs. It will take a lot of time to generate those proofs. Instead use mock proofs from #40

[rootulp]

For Tendermint chains:

• Multiple messages (UpdateClient, MsgTransfer) get bundled into one tx.

For EVM chains:

• We don't know which order we need to send the txs in.

[rootulp]

Clarification: steps 2 - 5 are responsibilities of the relayer. See #63 for a more detailed breakdown of what each step entails.