docs: Extractor-based foreign chain transaction validation design update

[netrome]

closes #1926

This PR extends the foreign chain transaction verification design with extractor-based requests, enabling more fine-grained observations (e.g. receipts, logs, events) to be signed by the MPC network.

[karim-en]

It is cool to have topics, but maybe this will complicate the request a little bit. It will be much easier for us to adopt the contract to post the message as raw data.

More info about the difference between topics and data:
https://medium.com/@andrey_obruchkov/understanding-events-the-evms-built-in-log-system-2c94e448acbd

[karim-en]

The emitter event is the most import part, we have to verify that the event has been emited by our contract address

[karim-en]

Btw, for EVMs we already know how generate proof for event based on the block hash, so if we are in rush then we are ok to have just the block hash extractor.

[netrome]

Wonderful. I've updated the list of initial extractors in d547048 as per our discussions. Let me know if this matches your needs.

[netrome]

It's just the BlockHash extractor for the EVM and Bitcoin, and the two Solana extractors.

[karim-en]

The minimal requirement for Solana is to verify the cpi events.
But we have to take into account that the RPC response is tricky, here is an example
We want to get the data in this instruction, but you can see that the emitter address is programIdIndex: 12, it is the 12th account, so we have to use the accounts array to get the real address

          {
              "accounts": [
                2,
                3,
                10,
                5,
                0,
                7,
                15,
                9,
                18,
                14,
                12
              ],
              "data": "ErVLopvJcPTFcfg8wd8xfj9MSrKGWTANBwwQQDex865F7DtBNnYLnodbhzFb8Y4Xxd79w228czP8pupG3RDaiCFtAhkW4ZsKmGSsVmgU9Vr5ira5aZztvYvNtYPCKAoujSXQWFTW5VK22W4QDPTuz3UuLoKM1591fxj9yo6oEemF9SYcpfSAf9aZqjDmSMZ8Wri2mT7kY5hYGy8Tm9UXJ9NRkcvkC1sU24FxJtoCGPBh8Ji9ZNGYCHqkqYUDSeUPdZJNwMAmsaFmcHPnSkWVMzGBcYg",
              "programIdIndex": 12,
              "stackHeight": 2
            },

        "accountKeys": [
          "9WL2A89YBr6X47ABKYNzPentWiBA3H8tpaiuf5CaYHx6",
          "BFasrjBGJmBsjj9rp1QJiXJsqi34yP4Y1dr2bomKezhD",
          "2yVjuQwpsvdsrywzsJJVs9Ueh4zayyo5DYJbBNc3DDpn",
          "4NKTVpUKP3Qn7nZtnZbuddr1CC8JYjqFhtEGDTsz4MKj",
          "6tckHFBpiJ8YgYN8FUskvtvTpXQZ55g5LHeo1kvELoDQ",
          "79nePUUxtfJSdrkbririgL5YMaoEh5g4HNQaar2EuJ7",
          "8DeAMZyCsXfGysyGyfdpL35KhBAaBQm9rqJUGYhK6dJG",
          "9bFNrXNb2WTx8fMHXCheaZqkLZ3YCCaiqTftHxeintHy",
          "A7bdiYdS5GjqGFtxf17ppRHtDKPkkRqbKtR27dxvQXaS",
          "11111111111111111111111111111111",
          "2iANpDh96GgithLPTVMZjZFtnbrYBUCLqnEvaytbwTQq",
          "dahPEoZGXfyV58JqqH85okdHmpN8U2q8owgPUXSCPxe",
          "EtZMZM22ViKMo4r5y4Anovs3wKQ2owUmDpjygnMMcdEX",
          "FvULawNPGBbuwYus74ECaQoV1oH9Tk6XPN7VPN51NYds",
          "HQS31aApX3DDkuXgSpV9XyDUNtFgQ31pUn5BNWHG2PSp",
          "SysvarC1ock11111111111111111111111111111111",
          "SysvarRent111111111111111111111111111111111",
          "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA",
          "worm2ZoG2kUd4vFXhvjh93UUH596ayRfgQ2MgjNMTth"
        ],
        

[bowenwang1996]

But that is just an implementation of the extractor right? Since the implementation would be defined in the MPC code, it is fine if we need to index an array

[netrome]

Yes, we synced on this in the meeting. We'll add two extractors for Solana: SolanaProgramIdIndex and SolanaDataHash. They will extract the "programIdIndex" and a hash of the "data" field above. @karim-en confirmed this should be sufficient.

Note: if we need more information later, it will be easy to add extractors.

[netrome]

Updated the extractors in d547048

[netrome]

We just had a meeting on this. We're aligned that this design makes sense, and initially it seems we only need three extractors:

• BlockHash for Bitcoin + EVM chains. (Might want to add these as specific extractors per chain, but that's not important right now).
• SolanaProgramIdIndex and SolanaDataHash for Solana. These are a bit more complicated but should be fairly isolated.

I'll update the design doc, @DSharifi will account for this in his DTO PR and we'll take it from there.

[DSharifi]

Added some questions, but looks mostly good to me

[DSharifi]

Should this be a Set instead of Vec? I assume we don't want duplicate extractors

[netrome]

Sure. Order will matter here though so I'm not sure if we want to use a Set. Even a BTreeSet with well-defined ordering feels like it may risk reordering something the users pass if they use another language and just pass some sequence to the method. Therefore it feels safer to just take a vec and return the same ordering. The caller pays for the gas anyway so deduplication feels like their concern. Duplication is not a problem on our side.

[netrome]

I did not change this now for this reason. We're not tied to exactly the structures in this design doc, let's just make sure to update it as we move forward if we change anything.

[gilcu3]

Thank you!