mpc bidirectional

[ppca]

This code now passes the complete successful deposit flow (https://github.com/sig-net/solana-contract-examples/blob/main/contract/tests/sign-respond-erc20.ts#L322).

Next step:
Understand and see how to set up testing all the other cases in https://github.com/sig-net/solana-contract-examples/blob/main/contract/tests/sign-respond-erc20.ts.

I think we could start reviewing.

[ppca]

This is still work in progress, will address comments when it's in more stable shape (things are connected to one another)

[ppca]

This is working on top of Felippe's PR that changes Solana indexer to parse CPI events: #439.

This PR has implemented:

1. the SignRespondTx
2. the SignRespondTxStorage
3. add field SignRequestType to IndexedSignRequest
4. the logic that process SignRespondRequestedEvent on Solana, create an IndexedSignRequest from it and add the IndexedSignRequest to the indexed requests channel. When the block where this SignRespondRequestedEvent is contained gets finalized, this sign request will be sent to sign queue and a signature will be generated
5. the logic that extract the eth tx to be watched from SignRespondRequestedEvent and the corresponding signature
6. the logic that watch the eth txs: with each block coming in from eth, we already process each block by parsing its logs for SignatureRequestedEvent, we now add the logic that look for eth txs that need to be watched among the block receipts, if such tx is found, it means that tx is completed, with a status fail or success.
7. the logic that process a completed eth tx and create an IndexedSignRequest and add to indexed requests channel in eth indexer. When the block that contains this eth tx gets finalized, this sign request will be sent to sign queue and a signature will be generated.

This PR has not implemented:

1. the checkpoint mechanism we discussed on Aug 7
2. the part that we actually call read_respond(). This is because we are planning a change on API from read_respond() on chain signatures contract to some other function on the dex contract. And i'm not clear about that new api and how the dex contract address will be passed in, so leaving that out for now.

[ppca]

Next steps:

1. make deterministic test cases for the util functions like decode_rlp_data
2. understand how to run the end to end bidirectional test with a locally run mpc system

[ChaoticTempest]

did an initial review, will come back to do some more later, but looks promising so far

[ChaoticTempest]

how are we testing this so far? Feels like this can easily regress if we don't have an integration test

[jakmeier]

Great progress!

There are lots of moving parts in this and I believe the first priority is to have something that just about works, without breaking things. We will need to iterate on it to make it more general for different chain to chain directions, more robust against error cases, refactor to make it more testable, add test cases, and potentially optimize async flows for performance. But I think we shouldn't wait too much before merging a first version of this to develop.

[jakmeier]

nit: instead of returning Err(anyhow!()) there is also the convenience macro bail!() that does is slightly more succinctly.

https://docs.rs/anyhow/latest/anyhow/macro.bail.html

This macro is equivalent to return Err(anyhow!($args...))

[volovyks]

@ppca please, address this one

[volovyks]

What is explorer in this context?

[ppca]

i followed the naming from fake mpc. @esaminu might know more detail about it, i'm happy to change it

[volovyks]

@esaminu please, take a look at this question even if we merge this.

[ChaoticTempest]

for the most part, it looks good to me, but let's wait on others to see if they notice anything else

[volovyks]

I've resolved most of our conversations (feel free to reopen), and created a couple of issues for things we should fix or look into in the future. Let's merge this one and iterate.

The base branch was changed.