Skip to content

Managing the proposer address #1573

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 14 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions pages/operators/chain-operators/tutorials.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -36,6 +36,8 @@ This section provides information on adding attributes to the derivation functio

<Card title="Running a Local Development Environment" href="/operators/chain-operators/tutorials/chain-dev-net" />

<Card title="Managing the proposer address" href="/operators/chain-operators/tutorials/proposer-address" />

<Card title="Integrating a new da layer with alt Da" href="/operators/chain-operators/tutorials/integrating-da-layer" />

<Card title="Modifying predeployed contracts" href="/operators/chain-operators/tutorials/modifying-predeploys" />
Expand Down
1 change: 1 addition & 0 deletions pages/operators/chain-operators/tutorials/_meta.json
Original file line number Diff line number Diff line change
Expand Up @@ -4,5 +4,6 @@
"adding-precompiles": "Adding a precompile",
"modifying-predeploys": "Modifying predeployed contracts",
"integrating-da-layer": "Integrating a new DA layer",
"proposer-address": "Managing the proposer address",
"chain-dev-net": "Running a local network environment"
}
79 changes: 79 additions & 0 deletions pages/operators/chain-operators/tutorials/proposer-address.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,79 @@
---
title: Managing the proposer address
lang: en-US
description: Learn how to update the proposer address for chains using permissioned fault proofs.
content_type: tutorial
topic: proposer-management
personas:
- chain-operator
- protocol-developer
categories:
- chain-operation
- chain-management
- proxy
- fault-proofs
is_imported_content: 'false'
---

# Managing the proposer address

This guide explains how to update the proposer address, within the dispute game smart contracts, for chains using permissioned fault proofs.
The [proposer](https://docs.optimism.io/operators/chain-operators/architecture#permissioned-components) is responsible for submitting L2 outputs to L1, which is a critical component of the OP Stack.
You will need the [L1ProxyAdmin](/superchain/privileged-roles#l1-proxy-admin) account, before you begin.

The proposer role is defined in the [`PermissionedDisputeGame.sol`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/dispute/PermissionedDisputeGame.sol) contract for chains running permissioned fault proofs.
When you need to change the proposer address, you must update the implementation for `gametype 1` in the `DisputeGameFactory.sol` contract.

## Steps to update the proposer address

1. **Identify the current configuration**

First, confirm that your chain is using permissioned fault proofs by checking the `DisputeGameFactory` contract on your L1. You can verify the current implementation by querying the `gameImpls` mapping with the permissioned cannon game type. This will return the current implementation contract for permissioned fault proof games.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer a more detailed approach here, is there anywhere i can get that @ZakAyesh ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of things:

1). We should let them know that permissioned game type is game type "1". They can find this information within this contract: https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/dispute/lib/Types.sol#L56

2), We could include example code how to do that in viem, we could link to the "read contract" to a chain we know is running permissioned fault proofs and have them view it that way, or we could even write Solidity code that reads this value and link to it in remix


See the [DisputeGameFactory contract](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/dispute/DisputeGameFactory.sol) for the `gameImpls` function details.

2. **Prepare the new implementation**

You'll need to deploy a new implementation of the `PermissionedDisputeGame.sol` contract with the updated proposer address. When deploying:

* The constructor requires multiple parameters including the _new_ proposer address
* Use the same parameters as your existing implementation, except for the new proposer address
* Ensure all inherited contracts are properly initialized
* Test deployment on a testnet first

For constructor parameters, refer to the [PermissionedDisputeGame contract](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/dispute/PermissionedDisputeGame.sol).

3. **Update the implementation in the DisputeGameFactory**

Using the L1ProxyAdmin account, call the `setImplementation()` function to update the permissioned game type:

* `_gameType`: Use `GameType.PERMISSIONED_CANNON` (value: 1) for permissioned fault proof games
* `_impl`: The address of your new implementation with the updated proposer

Only the owner of the DisputeGameFactory contract (typically the ProxyAdmin) can call this function. See the [DisputeGameFactory contract source](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/dispute/DisputeGameFactory.sol) for the function signature.

4. **Verify the update**

After updating the implementation, verify the change was successful by:

a. Checking the implementation address is updated in the `gameImpls` mapping

b. Creating a new dispute game to confirm the proposer address:

b. Creating a new dispute game to confirm the proposer address:
1. Call `create()` on the DisputeGameFactory with the permissioned cannon game type.
2. Query the `PROPOSER()` function on the newly created game.
3. Verify it matches the new address.

* This operation should be planned carefully as the proposer is a critical component of your rollup.
* Ensure the new proposer address is valid and properly controlled before making the change.
* Consider testing the procedure on a testnet before applying to production environments.
* The `L1ProxyAdmin` is a highly privileged role - ensure proper access controls are in place.
* All existing dispute games will continue to use the old proposer address, but newly created games will use the updated proposer.
* The proposer must have sufficient ETH balance to post bonds and pay for gas when creating new dispute games.

## Next steps

* After updating the proposer address, you may need to configure the new proposer node. See the [proposer configuration](/operators/chain-operators/configuration/proposer) for details.

* Read the [protocol configurability specifications](https://specs.optimism.io/protocol/configurability.html#proposer-address) for more in-depth details.
Loading