Add xdai upgrade scripts for chai support

[patitonar]

Closes #377

This PR adds the scripts that can be used in the upgrade of xdai bridge to 4.0.0 release.

The following steps can be performed in order to upgrade the bridge:

1. Deploy the new implementation contract for Foreign bridge.
2. Disable transfers from home to foreign. Set HOME_DAILY_LIMIT=0 .env var and run setHomeDailyLimit script
3. Wait until all in-progress transfers from home to foreign are processed.
4. Upgrade oracles.
5. Upgrade Foreign contract with the new implementation. Set NEW_IMPLEMENTATION_ETH_BRIDGE .env var and run chaiUpgrade:upgradeBridgeOnForeign script
6. Initialize Chai and receiver. Set CHAI_INTEREST_RECEIVER .env var and run chaiUpgrade:initializeChai script
7. Enable transfers from home to foreign again. Set HOME_DAILY_LIMIT >= 100000000000000000000001 (maxPerTx current value is '100000000000000000000000') .env var and run script: setHomeDailyLimit

Stopping the bridge operation from home to foreign is needed in order to ensure processing the transfers correctly since the way how the signatures are executed changes in this new release.

Testing the upgrade is still in-progress. I'll test the upgrade following the mentioned steps and add a comment with the results.

[akolotov]

I don't think it makes sense to keep old upgrade scripts. Let's substitute them by new ones. It will simplify the logic a bit.
If one wants to execute previous upgrade they could use the previous release tags/docker images. What do you think?

[akolotov]

Stopping the bridge operation from home to foreign is needed in order to ensure processing the transfers correctly since the way how the signatures are executed changes in this new release.

Instead of stopping the bridge by changing the limit (extra steps to be coordinated with validators) does it make sense to just roll back the block for watcher-erc-native-collected-signatures? The block must have the timestamp which is less or equal to the timestamp of the block where the foreign bridge implementation contract upgrade was confirmed.

[patitonar]

I don't think it makes sense to keep old upgrade scripts. Let's substitute them by new ones. It will simplify the logic a bit.
If one wants to execute previous upgrade they could use the previous release tags/docker images. What do you think?

Yes, I think it is a good idea. I'll remove it

Instead of stopping the bridge by changing the limit (extra steps to be coordinated with validators) does it make sense to just roll back the block for watcher-erc-native-collected-signatures? The block must have the timestamp which is less or equal to the timestamp of the block where the foreign bridge implementation contract upgrade was confirmed.

Yes, we can avoid stopping the bridge. Actually, when processing the collected-signatures event with the old oracle version and if the new implementation contract is in place, when estimating the gas it will fail with Unknown error and it will continue re-trying listening to the same range of blocks. So when the new oracle version is used, it will correctly process the event. The same situation will be if first the oracle is updated and the new old implementation is still being used, it will fail at processing the event and will keep re-trying listening in that range of blocks until the contract is upgraded and the event is correctly processed. As you mention, in any case, we can rollback the watcher-erc-native-collected-signatures block number

[akolotov]

Great! As soon as you finish with preparing new implementation for testing the upgrade please let me know.

[patitonar]

I pushed the changes mentioned. The mcdMigration scripts were removed and also the script to set the daily limit since it is not needed. Also cleaned up the .env.example to only include the variables needed for this upgrade.

The following steps can be performed to upgrade the bridge:

1. Deploy the new implementation contract for Foreign bridge.
2. Upgrade oracles. After this step Transfers from home to foreign won't be completed.
3. Upgrade Foreign contract with the new implementation. Set NEW_IMPLEMENTATION_ETH_BRIDGE .env var and run upgradeBridgeOnForeign script. After this step pending transfers and new ones should be completed and work correctly.
4. Initialize Chai and receiver. Set CHAI_INTEREST_RECEIVER .env var and run initializeChai script

I'll be testing this and add a comment with the results.

[patitonar]

I tested the upgrade procedure in Sokol-Kovan and it worked correctly, no issues were found. However, I found one issue while testing the Chai integration features.

HomeBridge: 0xAEa775BC17BE99B2cd032CE2303b164BC2dC0dDD

ForeignBridge: 0xEF3D53Df20aCbB7b742C85d0F8Ca24F480AbE606

Multisig as foreign owner to test the upgrade scripts: 0x6829Df9a24D46f8C2fa22b9c59f9cf30FF49206a

Chai: 0x623f148dabd40dd221807c5e98235bc40e54a106 (Used the deployed Chai token mentioned here)

Here is the test performed:

0. Started with the current implementation of contract and oracle
1. Sent some transactions on both sides
2. Deployed the new implementation contract in foreign.
3. Upgrade oracle.
4. Sent a transaction from Foreign to home and worked correctly. Sent a transaction from Home to Foreign and it failed at finishing processing it as expected because of how signatures are submitted.
5. Upgrade Foreign contract with new implementation using the script upgradeBridgeOnForeign. First one validator as leader role and the other two as confirm. Here I set NEW_IMPLEMENTATION_ETH_BRIDGE=0x494e7C6679aE85DA86fBaC738ea76E3dC95411Df
6. Checked that the pending transfer from Home to Foreign was completed correctly.
7. Sent transactions in both directions.
8. Initialized Chai and receiver using the script initializeChai. First one validator as leader role and the other two as confirm. Here I set CHAI_INTEREST_RECEIVER=0xf4BEF13F9f4f2B203FAF0C3cBbaAbe1afE056955.
9. Sent some transactions on both sides. Dai tokens were converted to Chai.
10. Waited some time to generate interest.
11. Called payInterest() method. Here is the Tx.
12. Tested running and processing transactions from an oracle instance deployed with the ansible deployment script.

In the step 11, when paying interests by calling payInterest() method, the generated interests in Dai are minted to the bridge contract and then the bridge transfers it to the InterestReceiver.
The Dai minted generated a Transfer event (from ZERO address to the bridge contract) that the bridge oracle transfer watcher tries to process to convert it to xdai. I think this is not the expected behavior. Instead, the bridge oracle should ignore this transfer, similar as it does for Transfer events generated by the token swap from Sai to Dai.

One possible fix for this, following how we handle these situations before, could be:

• Emit our own specific event when interest are paid in _payInterest method (similar to TokensSwapped event).
• Use this event to detect that the transfer comes from a transaction that paid interests (similar to https://github.com/poanetwork/tokenbridge/blob/346fa1e732d9fac3c393b09a6477f9dc19cd2fe7/oracle/src/events/processTransfers/index.js#L65-L70)
• The monitor should also be updated to ignore these type of events (similar to https://github.com/poanetwork/tokenbridge/blob/ef0a7346509ad0b953be261dfe43319f6a4605ad/monitor/utils/events.js#L140-L146)

[k1rill-fedoseev]

Is it necessary to emit a special event in such a case?
Seems like we can just skip Transfer events originated from address(0) in the oracle instead.

[akolotov]

The fix for found issue is being prepared here: #380