Constrained pause design +/- implementation

[kyzooghost]

Description

In aiming for Stage 1 of L2Beat's Stages Framework for Rollups, we aim to remove an unlimited pause mechanism and replace it with short-lived pauses with a cooldown period.

Motivation

Aim for Stage 1 of L2Beat's Stages Framework for Rollups. Guiding principle is:

The only way (other than bugs) for a rollup to indefinitely block an L2→L1 message (e.g. a withdrawal) or push an invalid L2→L1 message (e.g. an invalid withdrawal) is by compromising ≥75% of the Security Council.

In our current system, a malicious minority can indefinitely block an L2->L2 message by enacting an unlimited emergency pause.

Unlimited pauses by non-SC multisigs are not allowed. Projects with unlimited pauses by non-SC multisigs can prevent L1→L2 messages by compromising the Security Council quorum-blocking minority. Short-lived pauses with a cooldown period are allowed.

Please refer to https://forum.l2beat.com/t/stages-update-a-high-level-guiding-principle-for-stage-1/338

Tasks

• Review of the current overall pause system in the Linea smart contracts
• Design of constrained pause
• Presentation & discussion of above design work

Acceptance criteria

Pause implementation should meet the following criteria

• Have limited maximum duration (i.e. pause must have an expiration timestamp)
• Have a cooldown mechanism (i.e. pauses cannot be chained back-to-back, with no intermittent period)
• Should not increase gas cost for the happy path (regular user interaction should just be as is - just single check for isPaused)
• Has a simple implementation

Risks

• Taking too much time

Remember to

• Add the documentation label in case there is an impact on the documentation
• Add priority and team labels
• Add Task for updating the Runbook or adding/updating existing metrics and alerts.