[Exchange.sol] make bucket updates from Oracle data more predictable

Currently there is no easy way to tell if gold and stable token buckets will or will not get updated in next block.

When you call getBuyAndSellBuckets it might think that there won’t be a bucket update from oracle data because it can’t know what the now timestamp will be in next block.

This can lead to a confusion when getBuyAndSellBuckets returns incorrect buckets compared to what will actually be used in the next block.

It would be great if these updates can be made more predictable. Instead of updating buckets in the same block when calling ‘updateBucketsIfNecessary’, it could first just mark the buckets for updating for next block. This would simplify getBuyAndSellBuckets because it would only need to check that marker, instead of running the whole shouldUpdateBuckets logic, and this would also remove the dependency on now timestamp in that code path.

This type of change would make it predictable to know what the starting [gold, stable] buckets will be in next block, instead of current setup where there is no way to know if oracle update will or will not be applied in next block.

[zviadm]

Thinking about this some more, my initial thought might have been incorrect and the “re-enabling” event probably doesn’t increase risk that significantly. While it would be nice if oracle updates were more predictable, there are other risk factors (like someone else making a huge single trade when “on-chain” price is significantly off), that it probably wouldn’t change overall risk of slippage significantly anyways.

[zviadm]

@tkporter fyi, this issue is even more relevant now that Oracle circuit breaker has triggered twice. The “re-enabling” of oracles, after they have been down, is basically a completely unpredictable event right now that puts arbitrageurs at a risk. Re-enabling oracles event can cause a large unpredictable change in exchange rate within a block, and there is no way to predict or observe that it is about to happen. So it creates a large risk for one sided arbitrage trades to happen because of it.

In general, safer arbitrage ==> more efficient protocol, so if changes can be made that makes arbitrage safer it will only help protocol be more efficient overall.