-
Notifications
You must be signed in to change notification settings - Fork 260
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
krofax
wants to merge
14
commits into
main
Choose a base branch
from
proposer-address
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
14 commits
Select commit
Hold shift + click to select a range
b34ab9f
updated docs
krofax 0d149e8
Auto-fix: Update breadcrumbs, spelling dictionary and other automated…
krofax 9814b66
update todos
krofax 6f8932d
updated meta tags
krofax 86c89e3
updated breadcrumbs
krofax 72b1ca7
updated headers
krofax 9f1a0d6
updated the steps
krofax 21e0573
Auto-fix: Update breadcrumbs, spelling dictionary and other automated…
krofax ee58178
Update pages/operators/chain-operators/tutorials/proposer-address.mdx
krofax 3d285bc
Update pages/operators/chain-operators/tutorials/proposer-address.mdx
krofax 0bbc653
Update pages/operators/chain-operators/tutorials/proposer-address.mdx
krofax 66af797
Update pages/operators/chain-operators/tutorials/proposer-address.mdx
krofax 769a0a2
Update pages/operators/chain-operators/tutorials/proposer-address.mdx
krofax 8a3b075
Update pages/operators/chain-operators/tutorials/proposer-address.mdx
krofax File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
79 changes: 79 additions & 0 deletions
79
pages/operators/chain-operators/tutorials/proposer-address.mdx
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. | ||
|
||
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. |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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