-
Notifications
You must be signed in to change notification settings - Fork 38
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
feat: Add feature-gating in prover code based on target network #598
Conversation
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.
Really nice job
c1fcc37
to
196460c
Compare
196460c
to
97b1c1c
Compare
97b1c1c
to
05830e7
Compare
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.
Looks good, thanks!
@@ -327,8 +327,16 @@ min_stack_len_for_opcode: | |||
BYTES 0 // 0x46, CHAINID | |||
BYTES 0 // 0x47, SELFBALANCE | |||
BYTES 0 // 0x48, BASEFEE | |||
BYTES 1 // 0x49, BLOBHASH | |||
BYTES 0 // 0x4a, BLOBBASEFEE | |||
#[cfg(feature = eth_mainnet)] |
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.
Nit: I think an invalid instruction will be caught elsewhere anyway, so we don't need to make a distinction 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.
It seems weird to me to have BYTES 1
lying around for an instruction that doesn't exist. Even though as you point this would get caught elsewhere, I think we'd rather not have invalid Kernel bits if we have workarounds
} else { | ||
158 | ||
// unreachable | ||
0 |
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.
Nit: is there no way to panic here in a const?
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.
You can't compile if you do not have a usize
(like if you were to rely on unreachable!()
for instance), and I didn't want to have the else
only be equivalent to the last network feature in case we were to add another chain later on (as it would easily mess things up)
@@ -968,59 +968,45 @@ impl BurnAddrTarget { | |||
} | |||
} | |||
|
|||
#[cfg(feature = "cdk_erigon")] |
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.
Can't we just put the entire section concerning the burn address behind this cfg
?
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 would require to conditionally remove this field from PublicValuesTarget
but I think we'd prefer keep it consistent with the non target version
Co-authored-by: Hamy Ratoanina <hamy.ratoanina@toposware.com>
We were previously mixing bits of eth mainnet, cdk-erigon, etc...
Now the prover (i.e.
evm_arithmetization
) supports 3 network features:eth_mainnet
(by default for now): full Ethereum equivalence, Cancun HFpolygon_pos
: Prunes the ignored bits of Cancun from Napoli upgrade1 and supports incoming PIP-302cdk_erigon
: Prunes the ignored bits of Cancun irrelevant for CDK, includes LxLy pre-state execution3 and (yet unimplemented) post-state execution4, as well as the EIP-1559 variant for L2s.Notes:
parallel
feature (as we will always want it enabled, and this allows to not mess up when calling--no-default-features
to change network)bls12
Kernel file as being unused at the momentglobal_exit_root
) to run undereth_mainnet
feature flag.Based on #594
closes #575
closes #563
Footnotes
https://forum.polygon.technology/t/pip-33-napoli-upgrade/13405 ↩
https://forum.polygon.technology/t/pip-37-ahmedabad-hardfork/13885 ↩
cdk-erigon: Update LxLy pre-block processing logic (post Etrog) #436 ↩
cdk-erigon: Implement post-block execution LxLy logic #437 ↩