Use ChainConfig for stateless block validation #20

jsign · 2025-08-11T13:15:08Z

In this PR:

Remove ChainSpec stateless variant.
Add a fill_chainconfig helper which fills a ChainConfig from Hardforks + extra chain info. This is necessary since the Reth JSON files for mainnet do not have the chain config field.
In the MAINNET construction, use fill_chainconfig so the underlying genesis.chain_config is properly set.
In the ChainSpecBuilder, provide an option to fill the genesis config using the helper.
Add missing forks in the ChainSpecBuilder. These missing forks were Glacier-like forks (i.e., only bumping the difficulty bomb) and the DAO fork. More about this in comments.

I can provide some examples of how this works from the zkevm-benchmark-workload side (e.g., examples of JSON serialized chain configs), but I'll leave that to the upcoming PR I'll create there.

Supersede #13

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

github-actions · 2025-08-11T13:15:21Z

Your PR title doesn't follow the Conventional Commit guidelines.

Example of valid titles:

feat: add new user login
fix: correct button size
docs: update README

Usage:

feat: Introduces a new feature
fix: Patches a bug
chore: General maintenance tasks or updates
test: Adding new tests or modifying existing tests
bench: Adding new benchmarks or modifying existing benchmarks
perf: Performance improvements
refactor: Changes to improve code structure
docs: Documentation updates
ci: Changes to CI/CD configurations
revert: Reverts a previously merged PR
deps: Updates dependencies

Breaking Changes

Breaking changes are noted by using an exclamation mark. For example:

feat!: changed the API
chore(node)!: Removed unused public function

Help

For more information, follow the guidelines here: https://www.conventionalcommits.org/en/v1.0.0/

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

jsign · 2025-08-11T13:16:29Z

crates/chainspec/src/spec.rs

                for (fork, params) in bf_params.iter().rev() {
                    if self.hardforks.is_fork_active_at_timestamp(fork.clone(), timestamp) {
-                        return *params
+                        return *params;


Did some fighting to avoid these, but I'm not entirely sure what's the right vscode config for the Reth repo.

jsign · 2025-08-11T13:18:06Z

crates/chainspec/src/spec.rs

    chain: Option<Chain>,
    genesis: Option<Genesis>,
    hardforks: ChainHardforks,
+    fill_genesis_config: bool,


For the ChainSpecBuilder, I added an option fill_genesis_config(enable:bool) to make it optional. I think this might be the best take, since if you build from a correctly crafted genesis (e.g., Hoodi genesis), then you don't need to fill the chain config.

jsign · 2025-08-11T13:18:24Z

crates/chainspec/src/spec.rs

            chain: Some(MAINNET.chain),
            genesis: Some(MAINNET.genesis.clone()),
            hardforks: MAINNET.hardforks.clone(),
+            fill_genesis_config: true,


If you're starting from mainnet() then by default I activate the fill_genesis_config flag.

jsign · 2025-08-11T13:26:17Z

crates/chainspec/src/spec.rs

        self
    }

+    /// Enable Dao at genesis.


You will see I added the DAO and *Glacier forks that were missing.

I realized this when looking at the genesis chainconfigs that fill_chainconfig created, and noticed for these forks it always had mainnet block number instead of 0.

See here for an ordered set of forks. For example, the ChainSpecBuilder generated a chain spec with both Berlin and Istanbul activated at block 0, but MuirGlacier not activated. If you build a ChainSpecBuilder from mainnet(), that means that the underlying ChainConfig would be left with the MuirGlacier original block activation number instead of zero.

I guess this was OK for the testing crate since these are very old forks, and probably there aren't tests reg difficulty bombs delays or similar. I could have avoided adding these forks, but the underlying ChainConfig we would see generated for EEST blocks would have non-zero block number activations for them which looked very weird and seem buggy. This fixes it.

jsign · 2025-08-11T13:26:53Z

crates/chainspec/src/spec.rs

+        if self.fill_genesis_config {
+            fill_chainconfig(&mut genesis.config, &self.hardforks, self.chain, None);
+        }


If we were asked to "fill" the genesis block chainconfig, we do so.

BTW, note that None as the last argument (i.e., deposit contract address).
I'm honoring what is being done in L1024 below, but I feel this is somewhat wrong.

I'm not entirely sure why EEST tests don't seem to care about this, but I think some days/weeks ago I discovered that even if this is not set, some alloy-crate used mainnet contract address if it was needed and not provided (so I think it is interpreted as an "override" field).

In any case, I'm just accepting what they did before and avoid opinionating more about what I think might be better.

jsign · 2025-08-11T13:31:07Z

crates/chainspec/src/spec.rs

            chain: Some(value.chain),
            genesis: Some(value.genesis.clone()),
            hardforks: value.hardforks.clone(),
+            fill_genesis_config: false,


I think in this case setting this to false is the most conservative thing to do (i.e., how it worked before). The user can always call fill_genesis_config(true) if wanted.

jsign · 2025-08-11T13:31:30Z

crates/stateless/src/lib.rs

-pub mod chain_spec;
-/// ForkSpec module
-/// This is needed because ChainSpec is not serializable (neither is genesis)
-///
-/// Note: There is an exact copy of ForkSpec in `ef-tests` but since ef-tests is not no_std
-/// we cannot pull that in since we need ForkSpec in the guest program.
-///
-/// We convert the ef-tests version of ForkSpec in the host into the one located in here.
-///
-/// When we parse execution spec tests, we get back a ForkSpec, that we then pass into
-/// the guest program and convert it into a ChainSpec. If someone is using Hoodi/Mainnet
-/// etc, then this may not be needed, as you can just do ChainSpec::mainnet() in the guest program
-pub mod fork_spec;


Nuked crates.

jsign · 2025-08-11T13:34:40Z

testing/ef-tests/src/models.rs

-        .build()
-    }
-}
+        .build();


Note that we didn't need to call .fill_genesis_config(true) new option since in L317 we're building from mainnet() which activate this by default.

kevaundray

LGTM

jsign added 12 commits August 8, 2025 16:19

first step change

acc318e

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

fill chainconfig for tests

8cee4ee

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

add chain config

ca2e722

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

export genesis

39c7e54

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

update

4c51e81

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

more changes

65a6585

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

more work

8d348c8

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

more changes

b4bde84

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

remove stateless chainspec

6eda062

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

improvements

cb47abf

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

add glacier forks

e5eac83

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

add missing dao fork

8444a3e

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

not required activation since we build from mainnet

f17c70c

Signed-off-by: Ignacio Hagopian <jsign.uy@gmail.com>

jsign commented Aug 11, 2025

View reviewed changes

jsign mentioned this pull request Aug 11, 2025

Use ChainConfig for stateless-validator input eth-act/zkevm-benchmark-workload#138

Merged

jsign marked this pull request as ready for review August 11, 2025 15:16

jsign requested a review from kevaundray August 11, 2025 15:16

kevaundray approved these changes Aug 11, 2025

View reviewed changes

jsign merged commit 0880801 into kw/zkevm-benchmark-workload-repo Aug 11, 2025
13 of 36 checks passed

This was referenced Aug 11, 2025

Remove ForkSpec structure #18

Closed

Remove ForkSpec continuation #19

Closed

chore: benchmark workload repo with ChainConfig #13

Closed

Evaluate working solution to use ChainConfig as zkVM input for the stateless crate paradigmxyz/reth#17805

Open

Uh oh!

Use ChainConfig for stateless block validation #20

Use ChainConfig for stateless block validation #20

Uh oh!

Conversation

jsign commented Aug 11, 2025

Uh oh!

github-actions bot commented Aug 11, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kevaundray left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants