think through the various implications block.timestamp and network downtime

[godsflaw]

Context: block.timestamp

Description:

Some use cases of block.timestamp may be sensitive to network uptime. In general, imagine block.timestamp has some value t in block b, and then some value t + (1 day) in block b + 1. For example, the liquidation grace period, and auction price drops may be negatively impacted by a network outage. We tend to take mainnet uptime for granted, but recent events show that those assumptions could have potentially harmful implications. More importantly, when considering deploying Ajna to L2s, it's considerably more likely that a network will experience downtime where no blocks are produced, yet time ticks on. If this type of downtime were to be realized, or worse triggered, then it could have dire implications for auctions where the price is determined as a component of time, and may negatively impact other assumptions in the Ajna Protocol.

It's highly suggested that the Ajna team review all the uses of block.timestamp and think through the risks with regards to ethereum mainnet and other networks suffering downtime. Think through what happens if t in block b is then t + (1 day or more) in block b + 1.

Recommendation:

There has been a push by some to standardize around block.timestamp rather than block.number for simplicity; however, it may be safer to use a hybrid of both for some use cases like price as a component of time. If one were to store the block.number along with block.timestamp in some structures where one needed to compute delta-t, then one could make safer calculations that were anchored to the minimum of average block time * (b2 - b1) and t2 - t1.

Ajna:

Prototech:

[godsflaw]

I think it's worth considering updating this calculation to make it more resilient before deployment of Ajna on L2/L3 networks, as their uptime is highly questionable, but I support not making a change to L1 code this late in development as mainnet has a decent uptime track record. And while I still believe this uptime assumption is perhaps unwarranted given the recent transition to PoS, it's still hard to justify going with a more resilient calculation this late in development given how widespread this assumption is across DeFi, and how stellar ethereum's track record has been.