Conversation
| | `setLocalEjectionThreshold` | Minimum stake after slashing before ejection | Cap of X% per time window. | | ||
| | `updateStakingQueueConfig` | How validators enter the active set | Individual fields: cap of X% per time window. `normalFlushSizeMin` MUST be enforced to be greater than 0 (minimum flush size of 1). | | ||
|
|
||
| > **Note**: The exact constraint values (the "X%" bounds and time windows) are to be determined. The intent is that no governance action or sequence of actions can, for example, set the proving cost per mana to an extreme value, making it impossible to include transactions. |
There was a problem hiding this comment.
The AZIP should specify a value for X
|
|
||
| ### Stage-2 Requirements | ||
|
|
||
| L2Beat's classification framework requires that users have roughly 30 days to react and still get an exit transaction included before a governance-triggered rollup change takes effect. If inclusion and exit can pessimistically take up to 20 days, a 60-day timelock still leaves ~40 days of real reaction time — well above the threshold. |
There was a problem hiding this comment.
our Stages Framework indeed requires >=30d to exit for users. but an immutable escape hatch would make the window infinite.
i am listing the 2 high-level paths to stage 2 for an Aztec rollup that we spoke about on the call:
- immutable escape hatch (with all its consequences like hardening
Rollup.setRewardConfig(booster, rewardDistributor, ...)and potential other functions that can mute the hatch) ---> infinite exit window - 60d delay on the critical functions (including the hatch) ----> 60d - timeNeededToExit >= 30d exit window
writing this just as a recap and to show the core of the two paths that should not be overlooked when potentially remixing them or implementing them in practice
There was a problem hiding this comment.
60d delay on the critical functions
"critical functions" here would also include Rollup.setRewardConfig etc right?
There was a problem hiding this comment.
yes governance is assumed to be fully malicious for the exit window. if it has any way of muting the hatch (even through hypothetical illicit minting of the bond asset AZTEC or this real path of setting reverting reward handler contracts) the hatch is not immutable and the time needed to exit would have to be subtracted from the gov execution delay, which esp. with AZIP-1, would be Stage 0.
There was a problem hiding this comment.
ah sorry you are quoting 2: answer is similar, since even gov is assumed malicious, anything with a shorter delay is assumed malicious too, and if it can impact L2->L1 messaging it will be used for the exit window calc. Rollup.setRewardConfig directly impacts L2->L1 messaging in that it can fully block it.
There was a problem hiding this comment.
a wild recent example is the L2 fee config incident on scroll. for us it is especially problematic since we have probably missed this permission during our stage 1 review. it directly violates the stage 1 principle
edit: we just had a discussion about this and it is mostly fine because these fee settings do not affect forced transactions from L1
There was a problem hiding this comment.
Thanks for more context here @sekuba . Do you think that if we allow RewardDistributor to be updatable with shorter than a >40 day notice, we need to wrap calls to claim in try/catch?
There was a problem hiding this comment.
gm, i haven't looked that deep, but if try/catch around claim liberates submitEpochRootProof() from malicious RewardConfigs, this is the way!
about the specific >40d: we currently ignore the escape hatch and use the 20d max time needed to exit from the public mempool path. if you go <40d upgrade delay that would be <30 exit window so no stage 2. but then you would argue that you can use the escape hatch. and we would argue you cannot use it in 3d since it is 1:1 (resources) sybillable by any attacker. we would have to find a compromise, like the 20d max on T99 inclusion probability for the public mempool path. maybe that compromise would fall <10d and you would preserve the 30d exit window for stage 2. but if there is any way to make the escape hatch truly immutable, e.g. by ignoring feeconfigs or making those configs robust / gated, i would prefer that path because it does not require calculating the 'practical' time needed to exit in this very unpractical path (huge bond, last resort emergency) that is the escape hatch.
malicious RewardConfigs or other configs must not block L2 -> L1 messages (on any path of your choice, probably the easiest via the escape hatch)
There was a problem hiding this comment.
my point is the escape hatch owes to its name that it is immutable, always.
the mempool path for inclusion can be mutable, and we already try to simulate practical delays for it. but 'simulating' use and delay of an absolute last resort CR gadget like the hatch would be super arbitrary imo, and all hatches we ever knew were usually immutable or close to immutable with deterministic delays
3 participants
Summary