Deprecated: Reuse storage slots with ring-buffers

[dantaik]

See https://github.com/taikoxyz/Taiko-Preconf-AVS-copy/discussions/11

Reduce SSTORE from 20K to 5K for lookaheadPosters and blockIdToProposer

[AnshuJalan]

Thank you for the changes! I have raised an alternative PR (#171) with two additional commits on top of yours:

• To follow convention:
  • I refactored and placed constants on top of the mappings they are being used within.
  • Shifted struct declarations to IPreconfTaskManager
• Regarding buffer size, I think we can have a discussion on what values when this system goes to mainnet. For now, this is my rationale behind selecting their values:
  • LOOKAHEAD_BUFFER_SIZE: I decided to bump it up to 128 from 64. If the dispute period (for a lookahead slot) itself is two epochs, having just 2 epochs worth of lookahead in the buffer is not enough. Except the first slot in the first lookahead, no other slot gets to go through the full dispute period.
  • BLOCK_ID_TO_PROPOSER_BUFFER_SIZE: Our system has a dispute period of 2 epochs, so ideally we would not need to store more than 2 epochs worth of blocks in the buffer. Our nodes have a cap of 4 L2 blocks per slot, making it 256 blocks in 2 epochs.
  • LOOKAHEAD_POSTER_BUFFER_SIZE: I did not completely understand the reason behind using PreconfConstants.SECONDS_IN_SLOT * BLOCK_ID_TO_PROPOSER_BUFFER_SIZE as the value in your commit. The rationale I used here is that since we have 4 epochs worth of lookahead at any moment, we may safely have this buffer contain the posters of just those 4 epochs.

[dantaik]

Closed and will continue on https://github.com/NethermindEth/Taiko-Preconf-AVS/pull/171

[dantaik]

LOOKAHEAD_POSTER_BUFFER_SIZE: I did not completely understand the reason behind using PreconfConstants.SECONDS_IN_SLOT * BLOCK_ID_TO_PROPOSER_BUFFER_SIZE as the value in your commit.

This is incorrect in my previous PR. No need to have SECONDS_IN_SLOT in the calculation at all. Good catch.

[dantaik]

Lets switch to discuss in your new PR.