aurora-is-near / rainbow-bridge-client

Monorepo containing Aurora-maintained libraries for using the Rainbow Bridge
https://github.com/near/rainbow-bridge-client/tree/main/packages/client#readme
MIT License
25 stars 7 forks source link

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

Open mfornet opened 3 years ago

mfornet commented 3 years ago

We need to determine when proofs to transfer assets from Ethereum to NEAR have been already used. (Mentioned by @sept-en in https://github.com/aurora-is-near/rainbow-bridge-client/issues/40#issuecomment-850717612)

This needs to be handled for:

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 commented 3 years ago

Relevant PR exposing used proofs in NEAR contracts:

paouvrard commented 3 years ago

@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 commented 3 years ago

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.