Proof calculation is not consistent against different browsers & wallets, which leads to failing `deposit` transactions

alexauroradev commented 3 years ago

For example this transaction was tried to be finalised with this failing transaction (obtained from the FE) and this CLI transaction (CLI guide). Also the transfer was recovered in the FE and it was an attempt to finalise it, which failed with the Event cannot be reused for depositing..

Perhaps similar issue was encountered in this tx.

Hypothesis is the proof calculation in some environments is not working the same way as in others

mfornet commented 3 years ago

We can implement a proof verifier in javascript, that will work for unit-tests, and that can be used before hand to check the validity of the generated proof! The goal is to detect where the divergence happens, because ultimately we should be computing proofs properly.

paouvrard commented 3 years ago

The current proof verifier uses import Tree from 'merkle-patricia-tree' as a dependency: For example:

After commenting out the line above: the dapp could load properly on FF and Safari. So this dependency is also the root cause of this issue: https://github.com/near/rainbow-bridge-frontend/issues/128 where the dapp cannot load on FF and Safari. So let's not use it for implementing a new verifier.

paouvrard commented 3 years ago

The error in proof calculation is due to an invalid result returned by the WalletConnect rpc provider when calling getTransactionReceipt. Here is an example receipt:

blockHash: "0xa0460b2b0f48600a3e40b5c97aa50bddd7989ed30a4b36aab86b8fd756fd1d9a"
blockNumber: 9955674
contractAddress: null
cumulativeGasUsed: 36623
from: "0xc7cc0cbc712ba155e7b5ff02772a1277d6d8cab0"
gasUsed: 36623
logs: (2) [{…}, {…}]
logsBloom: "0x00000000000000000000000000000000000000000000000000000000000010000000000100000000000000000000000000000000000000000080000000000000000000000000000000000008000000000000000000200020000000000000000000000000000020000000000000000000000400000000000000000011000000000000080000000040000000000000000000000000000000000000000000000000000000000000000080000010000000002000000000000000000000004000000800000002002000000000000000000000400000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000"
status: false
to: "0xb48e6441524f261e141bc766a7ebd54b19ca7465"
transactionHash: "0x8d1329d2cd171f43d2bdff8d2865a4afda275430c3c18210cf12f48fe6182499"
transactionIndex: 0
type: "0x0"

This ropsten transaction is success but the status is false when it should be true, which explains the byte difference in the submitted receipt_data. If this failed mint() is retried with metamask as the connected ethereum account, the mint transaction will succeed due to the receipt status now being correct. cc @mfornet @vgrichina

paouvrard commented 3 years ago

curl https://ropsten.infura.io/v3/infura_id \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params": ["0x8d1329d2cd171f43d2bdff8d2865a4afda275430c3c18210cf12f48fe6182499"],"id":3}'

returns

{"jsonrpc":"2.0","id":3,"result":{"blockHash":"0xa0460b2b0f48600a3e40b5c97aa50bddd7989ed30a4b36aab86b8fd756fd1d9a","blockNumber":"0x97e95a","contractAddress":null,"cumulativeGasUsed":"0x8f0f","from":"0xc7cc0cbc712ba155e7b5ff02772a1277d6d8cab0","gasUsed":"0x8f0f","logs":[{"address":"0x722dd3f80bac40c951b51bdd28dd19d435762180","blockHash":"0xa0460b2b0f48600a3e40b5c97aa50bddd7989ed30a4b36aab86b8fd756fd1d9a","blockNumber":"0x97e95a","data":"0x000000000000000000000000000000000000000000000000016345785d8a0000","logIndex":"0x0","removed":false,"topics":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef","0x000000000000000000000000c7cc0cbc712ba155e7b5ff02772a1277d6d8cab0","0x000000000000000000000000b48e6441524f261e141bc766a7ebd54b19ca7465"],"transactionHash":"0x8d1329d2cd171f43d2bdff8d2865a4afda275430c3c18210cf12f48fe6182499","transactionIndex":"0x0"},{"address":"0xb48e6441524f261e141bc766a7ebd54b19ca7465","blockHash":"0xa0460b2b0f48600a3e40b5c97aa50bddd7989ed30a4b36aab86b8fd756fd1d9a","blockNumber":"0x97e95a","data":"0x000000000000000000000000000000000000000000000000016345785d8a0000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000116f70615f636f6465372e746573746e6574000000000000000000000000000000","logIndex":"0x1","removed":false,"topics":["0xdd85dc56b5b4da387bf69c28ec19b1d66e793e0d51b567882fa31dc50bbd32c5","0x000000000000000000000000722dd3f80bac40c951b51bdd28dd19d435762180","0x000000000000000000000000c7cc0cbc712ba155e7b5ff02772a1277d6d8cab0"],"transactionHash":"0x8d1329d2cd171f43d2bdff8d2865a4afda275430c3c18210cf12f48fe6182499","transactionIndex":"0x0"}],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000010000000000100000000000000000000000000000000000000000080000000000000000000000000000000000008000000000000000000200020000000000000000000000000000020000000000000000000000400000000000000000011000000000000080000000040000000000000000000000000000000000000000000000000000000000000000080000010000000002000000000000000000000004000000800000002002000000000000000000000400000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":"0xb48e6441524f261e141bc766a7ebd54b19ca7465","transactionHash":"0x8d1329d2cd171f43d2bdff8d2865a4afda275430c3c18210cf12f48fe6182499","transactionIndex":"0x0","type":"0x0"}}

Where status is true (0x1) which can also be verified from the Browser devtools network tab.

So it looks like the walletconnect provider library which formats the rpc result has a bug causing status to be false when console logging the formatted receipt object

aurora-is-near / rainbow-bridge-client

Proof calculation is not consistent against different browsers & wallets, which leads to failing `deposit` transactions #12