Handle large Ropsten reorgs

[Maksym Zavershynskyi]

Background

Unfortunately, Ropsten sometimes undergoes huge re-orgs, specifically between 2020-08-26 9:54:22 PDT and 2020-08-25 16:23:30 PDT it re-orged 16k blocks. When this happens the following things happen:

• Infura websocket interface stops working;
• The bridge has to backtrack significant numbers of blocks;
• EthOnNearClient gets broken because by the default, it assumes that the re-orgs cannot be longer than 500 blocks: https://github.com/near/rainbow-bridge-lib/blob/master/eth-on-near-client/index.js#L140
• If reorgs extends past initialization of NearOnEthClient then this contract gets deleted

Solution

To address this problem we need to do the following;

• Indicate clearly in the documentation that it is not advised to use websockets for Ethereum node URLs;
• Examine our code base and make sure we are not using websocket-specific features, like subscriptions to events;
  _threshold` configurable parameters that can be passed through a command line;
• In the documentation that explains how to setup (will be introduced with #326) explain that for Ropsten finalized_gc_threshold and hashes_gc_threshold should be set to 50k each;
• Compute the amount of NEAR tokens we need to stake for EthOnNearClient to be able to handle finalized_gc_threshold=50k. Make sure we initialize EthOnNearClient with at least this number of tokens using near-client-init-balance parameter
• Make finalized_gc_threshold and `hashes_gc
• Add a parameter to init-near-contracts command that allows to initialize the client using the block from far in the past, because the current block might be easily revertable; link

[Marcelo Fornet]

Add a parameter to init-near-contracts command that allows to initialize the client using the block from far in the past, because the current block might be easily revertable;

If the current block is reverted, then client code is erased, so this doesn't solve the problem of block begin reverted.