Proposal Preview: DeputyPauseModule (Superchain Pause Improvements)

Technical Proposals 📃
1

Executive Summary

OP Labs is planning to submit a proposal that introduces a new Safe Module called the DeputyPauseModule to be installed into the Optimism Foundation Safe to simplify the process of quickly responding to security incidents via the Superchain-wide pause mechanism.

Please note that this is a Proposal Preview and is not an actual proposal. It is meant to allow the Collective to provide feedback and ask questions before an official proposal is published.

Impacted Stakeholders & Expected Outcomes

  • Optimism Foundation: Simplified process for triggering Superchain-wide pause quickly in case of an emergency.

Definitions

  • Guardian — The Ethereum account that is given the ability to carry out certain safety-net actions. The Guardian is expected to use these capabilities when a bug in the system could threaten the safety of the native bridge. For the Superchain, the Guardian is the Security Council Safe. The Security Council Safe has permitted the Optimism Foundation Safe to act as the Guardian through a Safe Module that the Security Council Safe can revoke at any time.
  • Phase 0 Security Council Account — The 2/2 Safe composed of the Security Council Safe and the Optimism Foundation Safe.
  • DeputyGuardianModule — The Safe Module installed by the Security Council that allows the Optimism Foundation Safe to act as the Guardian.

Motivation

Why are we submitting this proposal?

The Optimism Foundation in its role as the “Deputy Guardian” has the mandate to respond quickly to potential incidents. We are submitting this proposal because we believe that the proposed changes make significant improvements to the process of triggering the Superchain-wide “pause” functionality without changing any existing security properties.

Why should the Collective adopt this proposal?

This proposal simplifies the process by which the Optimism Foundation can quickly trigger the Superchain-wide pause in case of an emergency. Specifically, we are proposing that the Optimism Foundation install a new module called the DeputyPauseModule that allows a dedicated private key to create signatures that authorize the Superchain-wide pause.

This new module means that the Optimism Foundation no longer needs to maintain “pre-signed” pause transactions for fast incident response capabilities, which significantly reduces the overhead of certain upgrades that force the Optimism Foundation Safe to re-sign these transactions.

Conflicts of interest

We do not believe there are any actual or expected conflicts of interest with this proposal. Our goal with this proposal is to meaningfully improve the ability for the Optimism Foundation to quickly respond to potential security incidents in its role as the Deputy Guardian. We believe this proposal is in the general best interest of the Collective.

Technical Details

Summary

DeputyPauseModule

  • The DeputyPauseModule is a new Safe Module that we are proposing to install into the Optimism Foundation Safe. The DeputyPauseModule allows the Optimism Foundation to assign a “Pause Deputy” private key that can be used to create signatures that authorize the use of the Superchain-wide pause.
  • The DeputyPauseModule allows the Pause Deputy private key to cause the Optimism Foundation Safe to execute a call to the DeputyGuardianModule account ONLY for the purpose of executing the pause function. The Pause Deputy has no other capabilities.

Supporting Documentation

Audit Reports and Findings

Radiant Labs

  • Report
  • Low/informational findings only, all addressed

MiloTruck (independent)

  • Report
  • Low/informational findings only, all addressed

Impact Summary

  • Adopting this proposal will significantly improve the Optimism Foundation’s ability to quickly respond to incidents while simultaneously eliminating a major source of overhead during the upgrade process (re-signing many pre-signed pause transactions).
  • The Optimism Foundation Safe is expected to rotate the Pause Deputy private key on a regular basis (approximately every 3 months).
  • Usage of a private key in place of the existing “pre-signed” pause transactions does not change the existing security model. In either case, the Optimism Foundation retains access to secret material that can quickly trigger the Superchain-wide pause in case of an emergency.

IMPORTANT

  • We intend to propose that the Collective give the Optimism Foundation Safe the authority to freely rotate the Pause Deputy as necessary.
  • We intend to propose that the Collective give the Optimism Foundation Safe the authority to freely change the reference to the DeputyGuardianModule held inside of the DeputyPauseModule in the case that the Security Council replaces the DeputyGuardianModule.
  • We intend to propose that the Collective permit the Optimism Foundation Safe to selectively share access to the Pause Deputy signing key with organizations outside of the Optimism Foundation (e.g., OP Labs) as the Optimism Foundation deems necessary.
  • We intend to propose that the Collective permit the Optimism Foundation Safe to execute the pause function on Ethereum Mainnet as part of a mock incident/training session to verify the proper operation of the contract.
1 Like
2

In principle, having fast pause mechanisms for the security of the Superchain makes sense. That said, we have a few questions about the implications of this proposal as it stands:

  • How does this proposal impact L2Beat’s Stage framework in meeting the Stage 1 requirements and progressing to Stage 2?
  • Based on that, in what scenario could this pause mechanism safely become unnecessary?
3

These are great questions.

Generally speaking it’s worth noting that this pause mechanism already exists, we’re just reducing the operational overhead of using it.

We’ve confirmed with L2Beat that this proposal does not have any impact on Stage 1 requirements.

OP Labs is separately working on a proposal that will further simplify the incident response process to place more control in the hands of the Security Council. This separate proposal will ensure that the OP Stack is fully compliant with the updated Stage 1 requirements that will go into effect later this year.

Although the current Stage 2 definition isn’t solidified, we’re generally being cognizant of what we think Stage 2 requirements will ultimately be. We believe the best approach for now is to minimize our incident response options to simplify the protocol as a whole. We currently don’t have reason to believe that any of these changes would jeopardize Stage 2 status.

The current thinking on this subject is that in a Stage 2 system, multiple independent proof systems would effectively act like an automated pause. If the proof systems disagree then there’s clearly some bug in the system that must be resolved. We believe it would be appropriate for the system to automatically pause itself whenever such a disagreement is detected.

That said, it may still be valuable for this more manual pause to exist even into Stage 2. There’s not much clarity yet as to what final Stage 2 requirements will look like, so we’ll continue to reassess as this becomes more clear!

3 Likes