contracts-bedrock: prevent too low of gas config#5112
contracts-bedrock: prevent too low of gas config#5112
Conversation
|
|
If we opt into this solution, then I will need to modify the L1 deploy process such that the correct optimism portal contract exists at the correct location before the deployment of the system config contract. Will require a refactor of how the L1 deployment works so that contracts are deployed + initialized + moved to the account one at a time, in dependency order. |
✅ Deploy Preview for opstack-docs ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
2af93fc to
80a8f2a
Compare
|
Semgrep found 1
Unchecked type assertion. Created by unchecked-type-assertion. |
protolambda
left a comment
There was a problem hiding this comment.
LGTM. Just a few comments about future contract dependency / checks. The PR description makes sense, but I'm not sure if future additional configurable values change this.
80a8f2a to
8f47ddd
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## develop #5112 +/- ##
===========================================
- Coverage 41.59% 41.05% -0.55%
===========================================
Files 358 337 -21
Lines 22385 21769 -616
Branches 776 660 -116
===========================================
- Hits 9312 8937 -375
+ Misses 12366 12123 -243
- Partials 707 709 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
|
|
I've move the min gas check outside of the constructor and added a comment that it should happen offchain. I added a check to the deployment code. It would require a large refactor of how we do deployments/initializations to be able to allow a contract to make a call in the constructor. |
|
Hey @tynes! This PR has merge conflicts. Please fix them before continuing review. |
39c384f to
86eb055
Compare
Ensures that things are smooth once #5112 is merged. A too small of gas limit will break things after that PR is merged. We will run with 30 million limit on mainnet, so we should ensure that our devnet config reflects that.
| * @notice Returns the minimum gas limit allowed by the system. If the L2 | ||
| * gas limit is set to a value smaller than this, then it is | ||
| * possible for a block to be produced that uses more gas than what | ||
| * is allowed on L2, resulting in a liveness failure. |
There was a problem hiding this comment.
Is that what would happen, or would deposit blocks be rejected or invalid? I honestly don't know.
There was a problem hiding this comment.
According to @trianglesphere it would cause the chain to halt. I don't believe we have test coverage of this case
There was a problem hiding this comment.
How difficult would it be to add a test for this case in op-e2e? Is this something we could do prior to mainnet launch, or okay to put in the backlog in your opinion?
The chain liveliness depends on the L2 gas limit being larger than the gas consumed by a deposit. If a deposit consumes more gas than what is possible in an L2 block, then the chain will halt and be unable to produce blocks. This was previously handled by having a hardcoded constant in the system config contract. This constant must be kept in sync with the value in the optimism portal. It is also possible to deploy a new optimism portal such that it has a different resource limit. To remove the need to always having to keep these values in sync, a handle to the portal is given to the system config contract. The system config contract will call the portal to get the value dynamically. This ensures that we do not need to remember what the value is and update the contracts in tandem.
7d62d4e to
640664b
Compare
| * gas the system transaction can consume in a block. | ||
| */ | ||
| function minimumGasLimit() public view returns (uint256) { | ||
| uint256 maxResourceLimit = uint256(ResourceMetering(PORTAL).MAX_RESOURCE_LIMIT()); |
There was a problem hiding this comment.
I find this relationship pretty ugly. If anything, ResourceMetering should be pulling the max resource limit from SystemConfig rather than the other way around. That way you don't need a minimum gas limit like this. You just derive the maximum available deposit gas from the maximum resource gas as defined in this contract.
There was a problem hiding this comment.
Considered this design but decided against it balancing amount of diff
There was a problem hiding this comment.
Also seems like a cleaner layout to me, but this feels like a change that should be done after we ship Bedrock (along with broader SystemConfig enhancements, like adding in immutables for all of the protocol's proxies etc. similar to curve's AddressProvider)
|
Hey @tynes! This PR has merge conflicts. Please fix them before continuing review. |
Description
The chain liveliness depends on the L2 gas limit being larger than the gas consumed by a deposit. If a deposit consumes more gas than what is possible in an L2 block, then the chain will halt and be unable to produce blocks.
This was previously handled by having a hardcoded constant in the system config contract. This constant must be kept in sync with the value in the optimism portal. It is also possible to deploy a new optimism portal such that it has a different resource limit. To remove the need to always having to keep these values in sync, a handle to the portal is given to the system config contract. The system config contract will call the portal to get the value dynamically.
This ensures that we do not need to remember what the value is and update the contracts in tandem.