feat: add kona validator binary#151
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2f605f43d9
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| let witness_verification_time = 0.0_f64; // no_std: timing unavailable | ||
|
|
||
| // Replay block transactions | ||
| let (accounts, output) = replay_block_with_kona( |
There was a problem hiding this comment.
In Kona mode, replay_block_with_kona returns the header fields Kona derived, but validate_block never compares output.block_hash (or the derived withdrawals root) with the RPC block header before continuing with the local state-root checks. For blocks whose execution side effects still match the claimed state/receipt/gas fields, such as empty or no-op blocks with an invalid base fee or extra-data-derived header field, this accepts a block even though Kona rebuilt a different header; the existing BlockHashMismatch/WithdrawalsRootMismatch errors suggest these checks were intended here.
Useful? React with 👍 / 👎.
| let execution_context = MegaBlockExecutionCtx::new( | ||
| parent_hash, | ||
| attrs.payload_attributes.parent_beacon_block_root, | ||
| Default::default(), | ||
| block_limits, |
There was a problem hiding this comment.
generate_bundle_state is the state update later fed into SALT and withdrawal verification, but it creates MegaBlockExecutionCtx with empty extra data while the MegaEVM replay path passes header.extra_data.clone(). For blocks where MegaEVM hardfork logic or system-contract handling consults block extra data, the Kona bundle replay runs under a different context than the block and can reject otherwise valid blocks with state or withdrawal mismatches.
Useful? React with 👍 / 👎.
| &header.extra_data, | ||
| rollup_config, | ||
| )), | ||
| min_base_fee: Some(1_000_000), |
There was a problem hiding this comment.
payload_attrs_from_block always sets min_base_fee to 1_000_000, so kona_evm_env's attrs.min_base_fee.unwrap_or(config_min_base_fee) never uses the min base fee decoded from the parent header. On Jovian-active blocks where the parent extra data carries any other min base fee, Kona rebuilds the payload with the wrong base fee and can halt on otherwise valid blocks or compute state for the wrong BASEFEE value.
Useful? React with 👍 / 👎.
| let parent_header = if self.fetch_parent_header { | ||
| Some( | ||
| self.rpc_client | ||
| .get_header(BlockId::Hash(block.header.parent_hash.into()), false) |
There was a problem hiding this comment.
When kona-validator fetches a corrupt parent header whose hash field matches the requested parent hash but whose contents do not hash to it, this unverified fetch succeeds and the mismatch is only detected later inside Kona validation, where it is classified as a deterministic fatal validation failure. Fetching with hash verification here keeps the error in the RPC retry path, matching how full blocks are handled, instead of halting the validator because one provider returned a bad header.
Useful? React with 👍 / 👎.
flyq
merged commit 185b214
into
liquan/refactor/executor-abstraction
2 participants
Summary
KonaValidatorbackend and akona-validatorbinary so the same stateless validator pipeline can validate blocks with either the MegaEVM or Kona execution backend.Background
The validator pipeline already separates block fetching, contract caching, chain advancement, and reorg handling from per-block execution through the
BlockValidatorabstraction.This branch uses that abstraction to add Kona replay as a second execution backend without duplicating the pipeline.
That gives us a dedicated binary for running and debugging the Kona validation path while keeping the existing MegaEVM validator behavior intact.
One important difference between the backends is that Kona replay needs the parent header to re-derive parts of the header / payload, while the MegaEVM backend reads the execution parameters from the current block header.
For that reason, this PR does not make parent headers mandatory for every validator path.
Instead, the fetcher has a
fetch_parent_headerswitch that is enabled bykona-validatorand left disabled by the defaultstateless-validatorbinary.Approach
kona_replaymodule instateless-coreand exportKonaValidator.BlockValidatorforKonaValidator, replaying through Kona and validating the derived block hash, state root, withdrawals root, receipts root, logs bloom, and gas used.ValidationInput::parent_headeroptional for MegaEVM, while the Kona backend returns a backend error when it is missing.fetch_parent_headerswitch toValidatorFetcherso only the Kona path performs the extra parent-header RPC read.ValidatorProcessor<V>andworkers::run_with_signals<V>over anyBlockValidator<Block<Transaction>>, leaving production wiring to choose the backend.stateless-validatorwired toMegaEvmValidator, and addkona-validatorwired toKonaValidatorwith the same CLI surface.mega-konapath dependencies with Git dependencies onmegaeth-labs/mega-konabranchclay/feat/regist_pnet_config.Tests
cargo test --package stateless-core --lib -- kona_replay::tests::kona_validator_validate_block_mainnet_fixtures --exact --nocapturecargo test --package stateless-validator --test integration -- kona_validator_binary_exposes_cli --exact --nocapturecargo test --package stateless-validator --test integration -- kona_fetcher_includes_parent_header --exact --nocapturecargo test -p stateless-validator integration_test_ --test integration