Skip to content
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(trace): allow override fork #836

Open
wants to merge 18 commits into
base: develop
Choose a base branch
from
Open

feat(trace): allow override fork #836

wants to merge 18 commits into from

Conversation

lispc
Copy link

@lispc lispc commented Jun 19, 2024

1. Purpose or design rationale of this PR

so we can get traces as if blocks are executed post curie hardfork

2. PR title

Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:

  • build: Changes that affect the build system or external dependencies (example scopes: yarn, eslint, typescript)
  • ci: Changes to our CI configuration files and scripts (example scopes: vercel, github, cypress)
  • docs: Documentation-only changes
  • feat: A new feature
  • fix: A bug fix
  • perf: A code change that improves performance
  • refactor: A code change that doesn't fix a bug, or add a feature, or improves performance
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • test: Adding missing tests or correcting existing tests

3. Deployment tag versioning

Has the version in params/version.go been updated?

  • This PR doesn't involve a new deployment, git tag, docker image tag, and it doesn't affect traces
  • Yes

4. Breaking change label

Does this PR have the breaking-change label?

  • This PR is not a breaking change
  • Yes

@0xmountaintop 0xmountaintop marked this pull request as ready for review June 19, 2024 06:31
@0xmountaintop 0xmountaintop changed the title (wip) trace: allow override fork feat(trace): allow override fork Jun 19, 2024
colinlyguo
colinlyguo previously approved these changes Jun 19, 2024
eth/tracers/api_blocktrace.go Outdated Show resolved Hide resolved
@lispc lispc marked this pull request as ready for review June 20, 2024 06:43
chainConfig.CurieBlock = curie
if block.Number().Cmp(curie) > 0 {
// set non zero values for these slots
misc.ApplyCurieHardFork(statedb)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if Curie fork is already enabled, this will overwrite L1GasPriceOracle's storage.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if block.Number().Cmp(api.backend.ChainConfig().CurieBlock) < 0 && block.Number().Cmp(curie) > 0 {. sounds more reasonable?

Copy link

@omerfirmak omerfirmak Jun 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that is better. But I am afraid not complete. Maybe something like below?

!api.backend.ChainConfig().IsCurie(block.Number()) && block.Number().Cmp(curie) >= 0

Copy link
Author

@lispc lispc Jun 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in fact if block.Number().Cmp(curie) == 0, i think we don't need to inject system upgrades twice.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in fact if block.Number().Cmp(curie) == 0, i think we don't need to inject system upgrades twice.

as long as !api.backend.ChainConfig().IsCurie(block.Number()) is true, I don't think we would be applying the upgrade twice. If we apply only when block.Number().Cmp(curie) > 0, ApplyCurieHardFork will be applied one block late if I am not mistkaen.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"ApplyCurieHardFork will be applied one block late": you mean the bytecode force upgrade does not happen exactly at the fork height? i don't think so..

0xmountaintop
0xmountaintop previously approved these changes Jun 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants