-
Notifications
You must be signed in to change notification settings - Fork 319
[mainnet]: Increase Gas Limit to 31.25Mgas/s #495
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,15 @@ | ||
| OP_COMMIT=594bc933a38425f745b46399a3619bcdeb74965d | ||
| BASE_CONTRACTS_COMMIT=dcd8c98aa881e0ae4ebf872e0d91692a7bf94000 | ||
|
|
||
| L1_SYSTEM_CONFIG_ADDRESS=0x73a79Fab69143498Ed3712e519A88a918e1f4072 | ||
| SYSTEM_CONFIG_OWNER=0x14536667Cd30e52C0b458BaACcB9faDA7046E056 | ||
|
|
||
| OLD_GAS_LIMIT=200000000 | ||
| NEW_GAS_LIMIT=250000000 | ||
|
|
||
| FROM_GAS_LIMIT=200000000 | ||
| TO_GAS_LIMIT=250000000 | ||
leopoldjoy marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| SENDER=0x24c3ae1aedb8142d32bb6d3b988f5910f272d53b | ||
|
|
||
| RECORD_STATE_DIFF=true | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,50 @@ | ||
| include ../../Makefile | ||
| include ../.env | ||
| include .env | ||
|
|
||
| ifndef LEDGER_ACCOUNT | ||
| override LEDGER_ACCOUNT = 0 | ||
| endif | ||
|
|
||
| ifndef ROLLBACK_NONCE_OFFSET | ||
| override ROLLBACK_NONCE_OFFSET = 1 | ||
| endif | ||
|
|
||
| SCRIPT_NAME = lib/base-contracts/script/deploy/l1/SetGasLimit.sol | ||
|
|
||
| RPC_URL = $(L1_RPC_URL) | ||
|
|
||
| .PHONY: gen-validation | ||
| gen-validation: checkout-signer-tool run-script | ||
|
|
||
| .PHONY: run-script | ||
| run-script: | ||
| cd $(SIGNER_TOOL_PATH); \ | ||
| npm ci; \ | ||
| bun run scripts/genValidationFile.ts --rpc-url $(L1_RPC_URL) \ | ||
| --workdir .. --forge-cmd 'forge script --rpc-url $(L1_RPC_URL) \ | ||
| $(SCRIPT_NAME) --sig "sign(address[])" [] --sender $(SENDER)' --out ../validations/base-signer.json; | ||
|
|
||
| .PHONY: execute-upgrade | ||
| execute-upgrade: | ||
| FROM_GAS_LIMIT=$(OLD_GAS_LIMIT) \ | ||
| TO_GAS_LIMIT=$(NEW_GAS_LIMIT) \ | ||
| forge script --rpc-url $(L1_RPC_URL) lib/base-contracts/script/deploy/l1/SetGasLimit.sol \ | ||
| --sig "run(bytes)" $(SIGNATURES) --ledger --hd-paths "m/44'/60'/$(LEDGER_ACCOUNT)'/0/0" --broadcast | ||
|
|
||
| .PHONY: sign-rollback | ||
| sign-rollback: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can generate the validation file for the rollback case too as I mentioned here. |
||
| FROM_GAS_LIMIT=$(NEW_GAS_LIMIT) \ | ||
| TO_GAS_LIMIT=$(OLD_GAS_LIMIT) \ | ||
| SAFE_NONCE=$(shell expr $$(cast call $(SYSTEM_CONFIG_OWNER) "nonce()" --rpc-url $(L1_RPC_URL) | cast to-dec) + $(ROLLBACK_NONCE_OFFSET)) \ | ||
| $(GOPATH)/bin/eip712sign --ledger --hd-paths "m/44'/60'/$(LEDGER_ACCOUNT)'/0/0" -- \ | ||
| forge script --rpc-url $(L1_RPC_URL) lib/base-contracts/script/deploy/l1/SetGasLimit.sol \ | ||
| --sig "sign(address[])" [] | ||
|
|
||
| .PHONY: execute-rollback | ||
| execute-rollback: | ||
| FROM_GAS_LIMIT=$(NEW_GAS_LIMIT) \ | ||
| TO_GAS_LIMIT=$(OLD_GAS_LIMIT) \ | ||
| SAFE_NONCE=$(shell expr $$(cast call $(SYSTEM_CONFIG_OWNER) "nonce()" --rpc-url $(L1_RPC_URL) | cast to-dec) + $(ROLLBACK_NONCE_OFFSET)) \ | ||
| forge script --rpc-url $(L1_RPC_URL) lib/base-contracts/script/deploy/l1/SetGasLimit.sol \ | ||
| --sig "run(bytes)" $(SIGNATURES) --ledger --hd-paths "m/44'/60'/$(LEDGER_ACCOUNT)'/0/0" --broadcast | ||
jjtny1 marked this conversation as resolved.
Show resolved
Hide resolved
|
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,289 @@ | ||
| # Update Gas Limit in L1 `SystemConfig` | ||
|
|
||
| Status: [EXECUTED](https://etherscan.io/tx/0xfbf7dad2372bd9596cccf28f89eb4811c1d4f613638acf2c08e0399379db0e6b) | ||
|
|
||
| ## Objective | ||
|
|
||
| We are updating the gas limit to improve TPS and reduce gas fees. | ||
|
|
||
| This runbook invokes the following script which allows our signers to sign the same call with two different sets of parameters for our Incident Multisig, defined in the [base-org/contracts](https://github.com/base-org/contracts) repository: | ||
|
|
||
| `SetGasLimit` -- This script will update the gas limit to our new limit of TODO gas if invoked as part of the "upgrade" process, or revert to the old limit of TODO gas if invoked as part of the "rollback" process. | ||
|
|
||
| The values we are sending are statically defined in the `.env`. | ||
|
|
||
| > [!IMPORTANT] We have two transactions to sign. Please follow | ||
| > the flow for both "Approving the Update transaction" and | ||
| > "Approving the Rollback transaction". Hopefully we only need | ||
| > the former, but will have the latter available if needed. | ||
|
|
||
| ## Approving the Upgrade transaction | ||
|
|
||
| ### 1. Update repo and move to the appropriate folder: | ||
|
|
||
| ``` | ||
| cd contract-deployments | ||
| git pull | ||
| cd mainnet/2025-11-05-increase-gas-limit | ||
| make deps | ||
| ``` | ||
|
|
||
| ### 2. Setup Ledger | ||
|
|
||
| Your Ledger needs to be connected and unlocked. The Ethereum | ||
| application needs to be opened on Ledger with the message "Application | ||
| is ready". | ||
|
|
||
| ### 3. Simulate and validate the transaction | ||
|
|
||
| Make sure your ledger is still unlocked and run the following. | ||
|
|
||
| ```shell | ||
| make sign-upgrade | ||
| ``` | ||
|
|
||
| Once you run the `make sign...` command successfully, you will see a "Simulation link" from the output. | ||
|
|
||
| Paste this URL in your browser. A prompt may ask you to choose a | ||
| project, any project will do. You can create one if necessary. | ||
|
|
||
| Click "Simulate Transaction". | ||
|
|
||
| We will be performing 3 validations and then we'll extract the domain hash and | ||
| message hash to approve on your Ledger then verify completion: | ||
|
|
||
| 1. Validate integrity of the simulation. | ||
| 2. Validate correctness of the state diff. | ||
| 3. Validate and extract domain hash and message hash to approve. | ||
|
|
||
| #### 3.1. Validate integrity of the simulation. | ||
|
|
||
| Make sure you are on the "Summary" tab of the tenderly simulation, to | ||
| validate integrity of the simulation, we need to check the following: | ||
|
|
||
| 1. "Network": Check the network is Ethereum Mainnet. | ||
| 2. "Timestamp": Check the simulation is performed on a block with a | ||
| recent timestamp (i.e. close to when you run the script). | ||
| 3. "Sender": Check the address shown is your signer account. If not, | ||
| you will need to determine which “number” it is in the list of | ||
| addresses on your ledger. | ||
| 4. "Success" with a green check mark | ||
|
|
||
| #### 3.2. Validate correctness of the state diff. | ||
|
|
||
| Now click on the "State" tab. Verify that: | ||
|
|
||
| 1. Verify that the nonce is incremented for the Incident Multisig under the "GnosisSafeProxy" at address `0x14536667Cd30e52C0b458BaACcB9faDA7046E056`. We should see the nonce increment from TODO to TODO: | ||
|
|
||
| ``` | ||
| Key: 0x0000000000000000000000000000000000000000000000000000000000000005 | ||
| Before: TODO | ||
| After: TODO | ||
| ``` | ||
|
|
||
| 2. Verify that gas limit value is appropriately updated under "Proxy" at address `0x73a79fab69143498ed3712e519a88a918e1f4072`. We should see that the gas limit has been changed from TODO to TODO: | ||
|
|
||
| ``` | ||
| Key: 0x0000000000000000000000000000000000000000000000000000000000000068 | ||
| Before: TODO | ||
| After: TODO | ||
| ``` | ||
|
|
||
| #### 3.3. Extract the domain hash and the message hash to approve. | ||
|
|
||
| Now that we have verified the transaction performs the right | ||
| operation, we need to extract the domain hash and the message hash to | ||
| approve. | ||
|
|
||
| Go back to the "Summary" tab, and find the | ||
| `Safe.checkSignatures` call. This call's `data` parameter | ||
| contains both the domain hash and the message hash that will show up | ||
| in your Ledger. | ||
|
|
||
| Here is an example screenshot. Note that the value will be | ||
| different for each signer: | ||
|
|
||
|  | ||
|
|
||
| It will be a concatenation of `0x1901`, the domain hash, and the | ||
| message hash: `0x1901[domain hash][message hash]`. | ||
|
|
||
| Note down this value. You will need to compare it with the ones | ||
| displayed on the Ledger screen at signing. | ||
|
|
||
| ### 4. Approve the signature on your ledger | ||
|
|
||
| Once the validations are done, it's time to actually sign the | ||
| transaction. Make sure your ledger is still unlocked and run the | ||
| following: | ||
|
|
||
| ```shell | ||
| make sign-upgrade | ||
| ``` | ||
|
|
||
| > [!IMPORTANT] This is the most security critical part of the | ||
| > playbook: make sure the domain hash and message hash in the | ||
| > following two places match: | ||
|
|
||
| 1. on your Ledger screen. | ||
| 2. in the Tenderly simulation. You should use the same Tenderly | ||
| simulation as the one you used to verify the state diffs, instead | ||
| of opening the new one printed in the console. | ||
|
|
||
| There is no need to verify anything printed in the console. There is | ||
| no need to open the new Tenderly simulation link either. | ||
|
|
||
| After verification, sign the transaction. You will see the `Data`, | ||
| `Signer` and `Signature` printed in the console. Format should be | ||
| something like this: | ||
|
|
||
| ``` | ||
| Data: <DATA> | ||
| Signer: <ADDRESS> | ||
| Signature: <SIGNATURE> | ||
| ``` | ||
|
|
||
| Double check the signer address is the right one. | ||
|
|
||
| ### 5. Send the output to Facilitator(s) | ||
|
|
||
| Nothing has occurred onchain - these are offchain signatures which | ||
| will be collected by Facilitators for execution. Execution can occur | ||
| by anyone once a threshold of signatures are collected, so a | ||
| Facilitator will do the final execution for convenience. | ||
|
|
||
| Share the `Data`, `Signer` and `Signature` with the Facilitator, and | ||
| congrats, you are done! | ||
|
|
||
| ## Approving the Rollback transaction | ||
|
|
||
| Complete the above steps for `Approving the Update transaction` before continuing below. | ||
|
|
||
| ### 1. Simulate and validate the transaction | ||
|
|
||
| Make sure your ledger is still unlocked and run the following. | ||
|
|
||
| ```shell | ||
| make sign-rollback | ||
| ``` | ||
|
|
||
| Once you run the make sign command successfully, you will see a "Simulation link" from the output. Once again paste this URL in your browser and click "Simulate Transaction". | ||
|
|
||
| We will be performing 3 validations and then we'll extract the domain hash and | ||
| message hash to approve on your Ledger then verify completion: | ||
|
|
||
| 1. Validate integrity of the simulation. | ||
| 2. Validate correctness of the state diff. | ||
| 3. Validate and extract domain hash and message hash to approve. | ||
| 4. Validate that the transaction completed successfully | ||
|
|
||
| #### 3.1. Validate integrity of the simulation. | ||
|
|
||
| Make sure you are on the "Summary" tab of the tenderly simulation, to | ||
| validate integrity of the simulation, we need to check the following: | ||
|
|
||
| 1. "Network": Check the network is Ethereum Mainnet. | ||
| 2. "Timestamp": Check the simulation is performed on a block with a | ||
| recent timestamp (i.e. close to when you run the script). | ||
| 3. "Sender": Check the address shown is your signer account. If not, | ||
| you will need to determine which “number” it is in the list of | ||
| addresses on your ledger. | ||
| 4. "Success" with a green check mark | ||
|
|
||
| #### 3.2. Validate correctness of the state diff. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we aren't using the signer tool for the rollback, please update the expected state diff below
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's tricky to use the validation tool for the rollback as well because it requires switching the TO/FROM environment variables. Im not sure there is an easy way to tell the signing tool "switch the variables" without manually switching them OR modifying the SetGasLimit script in base-contracts to accept a TO_ROLLBACK/FROM_ROLLBACK env variables
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, this is possible now in a straightforward way with the latest version of the Signer Tool. Here's a working example of it with the Signer Tool: #491
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Got it, going forward we can use this |
||
|
|
||
| Now click on the "State" tab. Verify that: | ||
|
|
||
| 1. Verify that the nonce is incremented for the Incident Multisig under the "GnosisSafeProxy" at address `0x14536667Cd30e52C0b458BaACcB9faDA7046E056`: | ||
|
|
||
| ``` | ||
| Key: 0x0000000000000000000000000000000000000000000000000000000000000005 | ||
| Before: 0x000000000000000000000000000000000000000000000000000000000000005e | ||
| After: 0x000000000000000000000000000000000000000000000000000000000000005f | ||
| ``` | ||
|
|
||
| 2. Verify that gas limit value is appropriately updated under "Proxy" at address `0x73a79fab69143498ed3712e519a88a918e1f4072`: | ||
|
|
||
| ``` | ||
| Key: 0x0000000000000000000000000000000000000000000000000000000000000068 | ||
| Before: 0x000000000000000000000000000000000000000000000000000000000ee6b280 | ||
| After: 0x000000000000000000000000000000000000000000000000000000000bebc200 | ||
| ``` | ||
|
|
||
| #### 3.3. Extract the domain hash and the message hash to approve. | ||
|
|
||
| Now that we have verified the transaction performs the right | ||
| operation, we need to extract the domain hash and the message hash to | ||
| approve. | ||
|
|
||
| Go back to the "Summary" tab, and find the | ||
| `Safe.checkSignatures` call. This call's `data` parameter | ||
| contains both the domain hash and the message hash that will show up | ||
| in your Ledger. | ||
|
|
||
| Here is an example screenshot. Note that the value will be | ||
| different for each signer: | ||
|
|
||
|  | ||
|
|
||
| It will be a concatenation of `0x1901`, the domain hash, and the | ||
| message hash: `0x1901f3474c66ee08325b410c3f442c878d01ec97dd55a415a307e9d7d2ea243362891827d16bf147890f005c6ff8a313d9fdba85f0e7c87817862872c975f45090e1`. | ||
|
|
||
| Note down this value. You will need to compare it with the ones | ||
| displayed on the Ledger screen at signing. | ||
|
|
||
| ### 4. Approve the signature on your ledger | ||
|
|
||
| Once the validations are done, it's time to actually sign the | ||
| transaction. Make sure your ledger is still unlocked and run the | ||
| following: | ||
|
|
||
| ```shell | ||
| make sign-rollback | ||
| ``` | ||
|
|
||
| > [!IMPORTANT] This is the most security critical part of the | ||
| > playbook: make sure the domain hash and message hash in the | ||
| > following two places match: | ||
|
|
||
| 1. on your Ledger screen. | ||
| 2. in the Tenderly simulation. You should use the same Tenderly | ||
| simulation as the one you used to verify the state diffs, instead | ||
| of opening the new one printed in the console. | ||
|
|
||
| There is no need to verify anything printed in the console. There is | ||
| no need to open the new Tenderly simulation link either. | ||
|
|
||
| After verification, sign the transaction. You will see the `Data`, | ||
| `Signer` and `Signature` printed in the console. Format should be | ||
| something like this: | ||
|
|
||
| ``` | ||
| Data: <DATA> | ||
| Signer: <ADDRESS> | ||
| Signature: <SIGNATURE> | ||
| ``` | ||
|
|
||
| Double check the signer address is the right one. | ||
|
|
||
| ### 5. Send the output to Facilitator(s) | ||
|
|
||
| Nothing has occurred onchain - these are offchain signatures which | ||
| will be collected by Facilitators for execution. Execution can occur | ||
| by anyone once a threshold of signatures are collected, so a | ||
| Facilitator will do the final execution for convenience. | ||
|
|
||
| Share the `Data`, `Signer` and `Signature` with the Facilitator, and | ||
| congrats, you are done! | ||
|
|
||
| ## Execute the output | ||
|
|
||
| 1. Collect outputs from all participating signers. | ||
| 2. Concatenate all signatures and export it as the `SIGNATURES` | ||
| environment variable, i.e. `export | ||
| SIGNATURES="0x[SIGNATURE1][SIGNATURE2]..."`. | ||
| 3. Run `make execute-upgrade` | ||
|
|
||
| > [!IMPORTANT] IN THE EVENT WE NEED TO PERFORM ROLLBACK | ||
| > Repeat the above, but replace the signatures with the signed | ||
| > rollback signatures collected, the call `make execute-rollback` | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,21 @@ | ||
| [profile.default] | ||
| src = 'src' | ||
| out = 'out' | ||
| libs = ['lib'] | ||
| broadcast = 'records' | ||
| fs_permissions = [ {access = "read-write", path = "./"} ] | ||
| optimizer = true | ||
| optimizer_runs = 999999 | ||
| solc_version = "0.8.15" | ||
| via-ir = false | ||
| remappings = [ | ||
| '@eth-optimism-bedrock/=lib/optimism/packages/contracts-bedrock/', | ||
| '@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts', | ||
| '@openzeppelin/contracts-upgradeable/=lib/openzeppelin-contracts-upgradeable/contracts', | ||
| '@rari-capital/solmate/=lib/solmate/', | ||
| '@base-contracts/=lib/base-contracts', | ||
| '@solady/=lib/solady/src/', | ||
| '@lib-keccak/=lib/lib-keccak/contracts/lib' | ||
| ] | ||
|
|
||
| # See more config options https://github.com/foundry-rs/foundry/tree/master/config |
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.
Why do we need both the
OLD/NEWand theFROM/TOformat here?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.
This was because the signer tool was being used for the upgrade and the rollback was the normal way. For some reason the template sets FROM/TO to OLD/NEW