Consider discarding items rewrittable storage

[kleros]

Consider discarding items rewrittable storage

[greenlucid]

I decided against this

[greenlucid]

Revisiting this. There are upsides I missed:

• Incremental ids means there is no need to pass itemSlot as calldata. That makes it cheaper. acting on this incremental id costs ~5k extra L2 gas. this should be cheaper than the L1 gas from the calldata.
  • i did a small experiment, and for short term, the difference in L1 size is negligible. but it shall become larger as more lists are created.
• If only one item can ever live in an slot, there is no need to capture the block number when it's created. The evidence group id could simply be the itemSlot. this removes a function and simplifies things.
• code simplification (remove itemSlot emits, remove firstFreeSlot... etc)

another cool thing about this is, some lists would be able to keep the entire history of the item, without the current issue of

1. item gets created
2. item is challenged and removed
3. correct version of the item gets uploaded (thus, losing its reference to the previous one)

with this structure, instead, a list policy can enforce that the item has to be reclaimed. then, the history of the item (evidence thread + editions) wont be lost. this makes special sense for wiki use case.
reclaiming is not a feature yet, but it could be added.

[greenlucid]

Additionally, it could make sense to also stop making Dispute structs rewrittable. If so, then they should be set to zero to trigger refunds. But, this is not as important.
Should also be considered that allowing refunds to this will result in cheaper overflow attack for Disputes, whereas, in the rewrittable Dispute system, the number expresses the amount of Disputes that can be open simultaneously. (Of course, an attacker can create Disputes that will never finish, but still, it is fundamentally different)