feat(lc/starknet): verify signed commitment proofs from starknet

[rnbguy]

closes #229

[rnbguy]

I successfully managed to sign the proof_init

[rnbguy]

Looks like these two are skipped. Probably ibc-go doesn't use them after cosmos/ibc-go#7129

[rnbguy]

Currently, the signature verification fails here. But I don't know how to create the signature at this point without access to ConnectionEnd and ConnectionId at starknet.

[rnbguy]

I can query the stored counteryparty connection end (starknet) at cosmos, cosmos's own connection id to recreate the ConnectionEnd.

[rnbguy]

To generate the proofs -- specifically signatures, I hacked around. This is not ideal.

To generate a signature, I need

• starknet consensus root at cosmos (against which the proof is validated)
• starknet commitment prefix
• ibc path
• ibc value

When I am building the message with CosmosChain, I don't have access to StarknetChain. So I can't fetch the consensus_root (block_hash) for starknet.

For now, I pass the block_hash as a dummy proof in the payload -- as I am building the correct proof at message builder anyway.

@soareschen any idea how to do this properly?

[soareschen]

I think you need to include that in the payload. You can define a custom payload type for Starknet if needed.

[soareschen]

You could also modify the StarknetCommitmentProof type if it is required in all proofs. I think in Cosmos, the root is part of the MerkleProof struct already.

[rnbguy]

I ended up building the bytes that need to be signed at the Starknet (-to-Cosmos) payload builder step. But Starknet doesn't have access to the Cosmos's default signer. So I signed it at Cosmos's message builder step.

But I don't see how I can sign the bytes for packet commitment, ack and receipt.

[rnbguy]

One more question: is the query_packet_receipt supposed to return non_membership_proof too?

ibc-starknet/relayer/crates/starknet-chain-components/src/impls/queries/packet_receipt.rs

Lines 51 to 57 in a3248f9

	async fn query_packet_receipt(
	chain: &Chain,
	channel_id: &ChannelId,
	port_id: &IbcPortId,
	sequence: &IbcSequence,
	height: &u64,
	) -> Result<(Vec<u8>, StarknetCommitmentProof), Chain::Error> {

... for packet_timeout trigger.

[rnbguy]

currently fails because the packet_ack proof from Starknet to Cosmos is not valid, i.e. it is not signed by the cosmos default signer.

[rnbguy]

Actually, I think, the default_message_signer (or something equivalent) should be used on the Starknet side at payload builder steps.

• The public key is part of the Starknet light client. It should be part of Starknet's context.
• We will generate the commitment proofs at payload builder steps directly. The proofs from Starknet should only rely on Starknet's context.

Starknet does have an equivalent to default_message_signer via HasStarknetAccount

ibc-starknet/relayer/crates/starknet-chain-context/src/contexts/chain.rs

Line 192 in c14166f

pub account: SingleOwnerAccount<Arc<JsonRpcClient<HttpTransport>>, LocalWallet>,

But, it uses ecdsa scheme. But we are using secp256k1 in wasm light clients currently.

Probably, we can use relayer_wallet.signing_key to generate a secp256k1 key pair.

ibc-starknet/relayer/crates/starknet-integration-tests/src/contexts/bootstrap.rs

Lines 108 to 111 in a3248f9

	let relayer_wallet = wallets
	.get("relayer")
	.ok_or_else(|| StarknetBootstrap::raise_error("expect relayer wallet to be present"))?
	.clone();