Add detection of Arbos Version to the evaluation of IsPrauge #434
+104
−73
Conversation
This file contains 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 way we can enable the features for Prauge when the Arbos version is upgraded on chain instead of at some particular block number or block time. Part of: NIT-3139 and NIT-3173
rauljordan
previously approved these changes
Mar 26, 2025
rauljordan
previously approved these changes
Mar 26, 2025
This function returns a Signer which should be used on Arbitrum chains for any state-transition affecting code paths. This signer becomes a normal go-ethereum signer when ArbOs is not enabled. Part of: NIT-3139
rauljordan
previously approved these changes
Mar 27, 2025
In most places in the go-ethereum codebase where MakeSigner is clled, there is a header or a blockContext availble from which one can easily derive an arbosVersion. In all of those places, providing an accurate arbosVersion makes the signer more stable than the one returned from MakeSigner which uses a hard-coded `params.MaxArbosVersionSupported`. We have carefully documented the reasoning for why we think each of the contexts where we left calls to MakeSigner should be fine to use an Arbitrum signer initialized with the `MaxArbosVersionSupported` value in https://www.notion.so/arbitrum/MakeSiger-vs-VersionedArbitrumSigner-1c401a3f59f880eb84bded5e721e2647?pvs=4
tsahee
reviewed
Mar 31, 2025
The advantage of adding an argument to the MakeSigner function rather than creating a new VersionedArbitrumSigner function is that new calls to MakeSigner in the upstream go-ethereum project will immediately cause conflicts that will have to be resolved during merges which will cause us to think deeply about whether or not we have an appropraite arbos version to pass in to the function call.
|
Assigning to @tsahee to provide |
tsahee
requested changes
Apr 2, 2025
Essentially, the arbitrum chains do not support anything analogous to the L1 ethereum consensus layer. So, there is no need to perform special handling for those requests when running arbitrum nodes.
tsahee
approved these changes
Apr 3, 2025
| if b.cm.config.IsPrague(b.header.Number, b.header.Time) { | ||
| blockContext := NewEVMBlockContext(b.header, b.cm, &b.header.Coinbase) | ||
| // Arbitrum doesn't support Deposit, Withdrawal, or Consolidation requests. | ||
| if !b.cm.config.IsArbitrum() && b.cm.config.IsPrague(b.header.Number, b.header.Time, blockContext.ArbOSVersion) { |
There was a problem hiding this comment.
creation of redundant BlockContext (can just deserialise header)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This way we can enable the features for Prauge when the Arbos version is
upgraded on chain instead of at some particular block number or block time.
Part of: NIT-3139 and NIT-3173