Used proofs in workflows (Ethereum -> NEAR) / (Ethereum -> Aurora)

[mfornet]

We need to determine when proofs to transfer assets from Ethereum to NEAR have been already used. (Mentioned by @sept-en in #40 (comment))

This needs to be handled for:

• ethConnector
• eNEAR
• erc20

We should have a similar function as the one described in #40:

function proofInNearExists(nearProvider, connectorType, address, proof) {
    // Return true if the proof already exists, false otherwise
    // connectorType can be one of ["EthConnector", "eNEAR", "Erc20"]
}

One option that doesn't involve changing contracts, is querying directly the state. This is an example about how to do it:

curl --location --request POST 'https://archival-rpc.testnet.near.org/' \
--header 'Content-Type: application/json' \
--data-raw '{
  "jsonrpc": "2.0",
  "id": "dontcare",
  "method": "query",
  "params": {
    "request_type": "view_state",
    "finality": "final",
    "account_id": "dev-1620133090135-4688553",
    "prefix_base64": "U1RBVEU="
  }
}'

[mfornet]

Relevant PR exposing used proofs in NEAR contracts:

• ethConnector EthConnector: add view function to check whether the proof is used. aurora-engine#120
• eNEAR (Missing)
• erc20 Add is_used_proof() method. Near-One/rainbow-token-connector#62

[paouvrard]

@sept-en
Doing a view call to is_used_proof() produces the following error:
(index):1216 Error: [-32602] Invalid params: Query data size 25730 is too large

I notice that the event relayer is working because it uses changeMethods which broadcasts a tx instead of usingviewMethods to make the query: https://github.com/aurora-is-near/eth-to-near-event-relayer/blob/75efb4303a8e5d8838584bc16a06bf586d6e6e21/src/utils_near.js#L28

So I think the computation of Proof.get_key() could be done offchain and the key can be used as the view argument directly in order to avoid the query data size error.

cc @mfornet

[mfornet]

So I think the computation of Proof.get_key() could be done offchain and the key can be used as the view argument directly in order to avoid the query data size error.

This sounds good to me. We can rename it or even add a different function is_used_proof_from_key

We should make sure to expose this function publicly so other developer can use it in case they need that info.