Fix the two remaining UX/usability issues of TORU

Context

TL;DR: We have a MR that is almost ready that —I believe— solve the remaining issues of the TORU design. I also believe that we should move forward to merge it, despite the feature freeze.

Earlier this week, we successfully merged the MR implementing storage burn for Transaction Rollup. Despite the merklisation of inboxes, this remained necessary because in the worse case, a rollup could be use to allocate several gigabytes of storage to store commitments. The storage burn provides an incentive not to do that, and was designed to prevent an attacker to force a legitimate rollup operator to pay for a storage they don’t need.

That being said, it remains, to my opinion, a significant drawback for TORU, because it can be very expensive. I have estimated that it would require the same order of magnitude than a roll to have a legitimate transaction rollup with an activity similar to mainnet. Besides, considering the trouble we have with the garbage collection in the layer-1 context, having ways to not allocate too much is a big win for the layer-1.

And finally, we still had the issue of the deadline for withdrawals remained, which in terms of UX can potentially be disastrous. I explained here and at the protocall that I had a solution in mind to fix this, and that it could be implemented in K. This remains true, but I do think that the issues that we are talking about are harmful for the marketing of the project… though I also admit I am no expert in this field, far from it.

Anyway, because the changes were not that significant in term of code, we have actually decided to implement them. And the good news is, the branch is almost ready. I suspect that we can have it pass the TORU test-suite easily by next protocall. As I said, the changes are not that important.

I strongly suggest that we actually try to have this MR in J, because to my opinion, it really improves the implementation of TORU, without creating new edge cases or similar. Mostly because the edge cases are in the TORU state machine. (edited)

So to summarize the changes.

The end goal is to (1) reduce the withdraw deadline (or at least, give more flexibility to deal with it), and (2) reduce the impact of commitments on the layer-1 context by merklising them. The proposal is beneficial for the context all the time. It is beneficial for the context + the history of the chain if about 1/10 of messages implies withdrawals on average.

Manually testing the MR

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR