Context

Let’s get our number straights before J.

The current values are fine wrt. the layer-1 safety, but they probably could be refined a bit to be better.

tx_rollup_origination_size could be lowered (e.g. divided by 10) without any issue
tx_rollup_hard_size_limit_per_inbox is probably the main culprit here. It was set to 100,000 bytes as mostly a placeholder, and the nice thing is that it means that one mainnet, a transaction rollup cannot use more than a fifth of a Tezos block. I think it’s okay to say “on this first version of TORU, we have a conservative constrains on mainnet that could be lifted in the next amendment.” It fits well with the narrative “TORU is experimental.” In the same time, bumping it to e.g., 250,000 for instance is probably safe.
tx_rollup_finality_period is wrongfully set to 60,000 (because it was set when the block time was expected to be 20s). So we really need to make a MR this afternoon to fix that, to set it to 40,000. But I am wondering if we could decrease it a bit (let’s say, to a week). Just as a way to reduce even more the pressure of TORU on the context (but without changing the order of magnitude)

Manually testing the MR

CI shall prevail.

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