Bushstar
commented
4 weeks ago The team has discussed only allowing blocks in the future before. This is doable and would also reduce the time range that stakers can use to generate new blocks. As seen in the past, reducing this range lowers difficulty and also reduces the number of empty blocks generated. Each new block opens up the entire range of time from the median of the last few blocks to 30 seconds ahead. To limit to future only blocks would reduce this range to the previous block time to 30 seconds ahead of the current time, this would be somewhere between 0 to 30 second.
Will create a PR for discussion, this would be part of the next hard fork if accepted.
kuegi
Summary
On EVM, many protocols rely on block.timestamp to be strictly ascending (it must always be true that block(n).timestamp > block(n-1).timestamp ) On defichain, the native blocks (which define also the EVM timestamp) are not always fulfilling this which leads to problems in protocolls like UniSwapV2
f.e. see the calculation of cumulativePrice in UniswapV2 : https://github.com/Uniswap/v2-core/blob/ee547b17853e71ed4e0101ccfd52e70d5acded58/contracts/UniswapV2Pair.sol#L77-L81
(if swaps happen on blocks with negative time delta, the cumulative assumes that they are MAX_UINT112 apart and increases massively. But next check in any oracle shows a positive (small) delta between last check and current timestamp which messes up any calculation)
This is already affecting live protocolls. Currently seahorse cause the cumulative price in JAV-DFI pool triggered the issue at least once and is completely off now.