search

omni / tokenbridge

Mono repository of Token Bridge (Oracle, Deployment, Monitor). TokenBridge is an interoperability solution between EVM-based networks for assets/data cross chain transfers
http://docs.tokenbridge.net
GNU General Public License v3.0
277 stars 214 forks source link

Fix xDai bridge oracle behavior for transfers that hits daily limit #440

Open akolotov opened 3 years ago

akolotov commented 3 years ago

Consider to address the issue with the current behavior of the xDai bridge oracle for the following situation:

  1. There are four independent oracles for the bridge
  2. The amount of transfers from the Ethereum Mainnet executed during one day is 99'000 Dai, the configured daily limit is 100'000 Dai.
  3. One transfer (T1) appears on the Ethereum Mainnet side for 1'500 Dai. The oracles observe the transfer one after another with the delay 4 seconds.
  4. Another transfer (T2) appears on the Ethereum Mainnet side for 500 Dai.

While T1 is handled and sent by the first oracle, other oracles will experience the issue described in #436. So, they will not update the revisited blocks and will try to handle T2 again and again. At the same time T2 is perfectly fit within the executed limit.

The suggestion is to change the oracle as so it will schedule the transactions which hit the daily limit to be send at 00:00 UTC of the next day. It could be done either through an additional queue in the RMQ DB or by having a separate worker that will work with another block counter that keeps the block number of the first transaction hit the daily limit. It is necessary to investigate first which approach has less drawbacks.

akolotov commented 3 years ago

In fact, the behavior of the oracles could be even more inconsistent. Consider four oracles. Three of them are observing T1 at the same time and send the confirmations to the Home chain. The first mined confirmation is executed properly indicating that the transfer is above the limit. The second and third confirmations are failed since this "incorrect" transfer was already registered in the contract. The fourth oracle will not be able to send the transaction at all by the reasons described above.

So, even if the transaction is scheduled on the fourth oracle and sent later, it will be still impossible to collect enough confirmations since first three oracles will not re-send their transactions without manual intervention.

That's why it makes sense to consider the suggestion above "to change the oracle as so it will schedule the transactions which hit the daily limit ..." as so the oracle measures explicitly the rest of amount available to be sent to the Home chain and if the current transfer is going to hit the limit, to schedule the transaction for another time.

Bearing in mind the examples above, the first oracle (and others) must not send such transaction to the Home side at all but schedule it to deliver later.