In order to check if a proof was already used we need to check in a dictionary inside an ethereum contract if the proof exists already.

Implement this as a function so it can be reused for several tools, in particular for frontend while restoring tx. Relevant comments: aurora-is-near/rainbow-bridge-frontend#235 (comment)

I'm thinking in the following interface:

function proofExists(web3, lockerAddress, proof) {
    // Return true if the proof already exists, false otherwise
}

This PR #45 installed near-api-js from commit to handle borsh in viewMethods

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

It comes from the line code in the file src/rainbown/nep141-erc20/src/bridged-nep141/sendToEthereum/index.ts:334:41)

  const withdrawEvent = deserializeBorsh(
    SCHEMA, WithdrawEvent, Buffer.from(successValue, 'base64')
  ) as { amount: BN, token: Uint8Array, recipient: Uint8Array}

These were used at the very beginning, but the nep141Symbol = n + erc20Symbol standard is not being used and symbol is used everywhere instead.

Moving the discussion here from #4 (review) and #4 (comment)

Dapps may want to connect to different bridges simultaneously and record bridge transfers of different bridges on the same URL.
The current lib design assumes that dapps like https://github.com/near/rainbow-bridge-frontend will be connecting to a single bridge per URL (rinkeby.bridge.near.org for example) and uses process.env to access bridge contract addresses (process.env.ethLockerAddress for example). Transfers recorded in localStorage do not contain information about token connectors, bridges or networks.

While sending tokens from Near to Ethereum, in the second step (unlocking the tokens on Ethereum side) we should use latest height reported by NearOnEthClient to build the proof. Probably the problem right now is that the current height to use is computed once, and stored locally in the browser.

As a reference, in this lines we should be using latest height, and proof accordingly to the selected height. The should be recomputed at some point prior this moment, and my guess is that the best way to do it is to actually compute in the moment the user hit the withdraw transfer, without persisting this info anywhere with the intention of re-using in case of failure.

This solves the following issue. After upgrading the Client on Ethereum, the new contract didn't have any of the old blocks from NEAR, but only blocks after it was deployed. Some users, started the withdraw transaction before the upgrade, but didn't finish it before the contract was upgraded. They are trying to submit the unlocking transaction using a proof of inclusion in a block that can't be used anymore by the client.

I've observed in some cases that a transfer initialization (nep141 burn/ $NEAR lock) can fail with this error as if the urlParam was not set here before checkWithdraw is called and marks the transfer as failed. Instead since the url param should already be set, checkWithdraw should simply ignore this transfer because the redirect has not happened yet.

Deployment costs per byte of code are going to be increased by a factor of ~5 with this change to NEAR protocol: near/nearcore#6397

Probably this will be included with protocol version 53, which would be released on testnet by March 23 and on mainnet by April 20.

To find everyone affected by this change, I listed all the indirect deployments from the past that would fail with the new cost, if all gas attachments stay the same. factory.bridge.near appeared as signer 112 times in that list. I didn't go through all of them but I think it's always due todeploy_bridge_token only having 60Tgas attached. (Example)

A contract with 222kB (current size of bridge_token.wasm) will see its gas cost increased by about 13Tgas.

Your current gas limit of 60Tgas, defined in deploy.ts, is probably just about okay with that. But if you want to be on the safe side, I would increase it. Extra gas is fully refunded anyway.

After ERC20 tokens are bridged to NEAR as NEP141 the metadata needs to be updated. This is also the case when tokens are deployed as ERC20 inside Aurora. This issue tracks the implementation of helper functions to do this safely using a library.

The issue is opened in this library, since the logic for this should be implemented in this repository, and then we should be using it from CLI tool and frontend.

Tasks involved:

• Pull metadata from ERC20 contracts in Ethereum.
• Push metadata to NEP-141 in NEAR. Use this function to update NEP141 metadata
• Push metadata to ERC-20 contracts inside Aurora. Use AdminControlled interface for updating storage inside contracts.

Notice that for pushing information, they can only be done with from some particular accounts (owner accounts). It would be useful to throw a meaningful error in case the account used is not the expected one.

The status of bridge transfers is currently monitored via this checkStatusAll loop which will check the transaction and sync status for every transfer with an in-progress status:

The loop interval is currently fixed by the @near-eth/client user (the frontend) at around 5 secs. This works well for checking the status of a pending transaction being mined. But when checking the sync status of a multi-hour transfer, checking so frequently is a waste of resources (node, Infura...)

Possible solutions:

1. Keep the same checkStatusAll loop but timestamp the last checkSync done on the transfer object and skip future calls until a reasonable interval is reached:

   rainbow-bridge-client/packages/nep141-erc20/src/natural-erc20/sendToNear/index.js

   Line 125 in 152b075

   case LOCK: return checkSync(transfer)

   
   a) Couple minutes interval and same interval for each connector ?
   But Ethereum -> NEAR transfers are faster and show a more precise status with the number of confirmations. (x/30)

   b) Optionally defined at transfer creation ?
   Each transfer can define it's own checkSync interval at transfer creation (with a reasonable default value adapted to the transfer direction so that if doesn't need to be specified by the user of the library)

2. Introduce a new mining status to differentiate checkTransactionStatus from checkSync and run 2 loops separately at different intervals. One loop checking the status of pending transactions while the other checking the sync status of transfers.

I'm currently leaning towards solution 1.b) which gives more freedom to connector libraries and keeps the @near-eth/client more general with the same ConnectorLib interface

cc @mfornet

Aurora and Rainbow bridge connectors currently implement different APIs for creating transfers.

naturalErc20.sendToNear({ erc20Address, amount, sender, recipient })

• This function fetches the symbol and decimals on-chain. But in most cases the caller of the library will already know this metadata as it is used to display token balances to the user. So this metadata could be optional arguments.
• The amount input is a decimal string ("2.3"). It would be safer to accept ethers.BigNumber or a big number string with decimals as a separate argument
• The sender could be optional and default to the connected wallet address.

naturalErc20.sendToAurora({ amount, token })

• token.symbol and token.decimal could be optional and queried on-chain if necessary.
• An optional sender can be added which defaults to the connected wallet.
• An optional recipient can be added which defaults to the sender.

Proposed API:

sendTo...({
    erc20Address: string,
    amount: string | ethers.Bignumber,
    recipient: string, 
    options?: {
        symbol: string,
        decimals: number,
        sender: string,
        recipient: string,
        provider: ethers.providers.Web3Provider,
        connectorAddress: string, // erc20Locker | etherCustodian | auroraEvm | erc20Factory | nativeNearLocker
        connectorAbi: string
    }
})

cc @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="
  }
}'

Based on this info, the indication of the waiting period for the withdrawal transfer may be enhanced.
Blocked by the implementation of Near-One/rainbow-bridge#522

The user's balance is user centric metadata. It should be used outside the getErc20Data.

and getBalance should be exported here:

Similar to aurora-is-near/rainbow-bridge-frontend#216 we can add a CODEOWNERS file for this repo.