The Account and Storage methods on *reader were pure forwarders to the
embedded StateReader; Go's method promotion makes them redundant.
Remove the EIP-7702 delegation-clear regression test; coverage is
deferred to the execution-spec test suite, which already exercises the
BAL apply path via tests/block_test_util.go.
For BAL blocks AccountReads/StorageReads/CodeReads stay zero by design,
so the slow-block JSON state_read_ms read 0 — misleading to cross-client
consumers. Sum s.Prefetch (the prefetcher's elapsed time) into the field;
it's already zero on the pre-BAL path so the formula is unchanged there.
Also gofmt -w on reader.go and reader_eip_7928.go (trailing blank lines
left over from earlier cleanup).
- Pre-BAL path keeps StateDB synchronous read-time accumulators
(AccountReads, StorageReads, CodeReads, CodeLoaded, CodeLoadBytes)
so Execution = ptime - reads stays well-formed under single-thread
execution.
- BAL path drops aggregate reader read-times; under parallel workers
they sum across goroutines and aren't a wall-clock proxy.
- Delete dead PrefetchReadTimes/WaitPrefetch forwarders on *reader and
the now-unused ReadTimer/ReadDurations scaffolding.
- Add regression test for EIP-7702 delegation clear: empty []byte code
in the BAL must reset CodeHash to EmptyCodeHash.
Populates per-block state read/write counts in slow-block JSON for BAL
blocks (which #34892 left as TBD), and adds reader-level read timing.
Builds on top of bal-devnet-3 — most of the PR's earlier slow-block log
infrastructure was adapted into upstream by that commit, so this change
is now scoped to the metric population that the BAL alone can derive.
- BAL helpers: BlockAccessList.{UniqueAccountCount, UniqueStorageSlotCount,
WrittenCounts}. WrittenCounts walks the BAL once and returns the
block-aggregate write counts.
- Reader-level read timing: *reader times all synchronous Account/Storage/
Code/CodeSize calls via atomic counters; exposed via ReadTimes()
ReadDurations and the new state.ReadTimer interface. Replaces StateDB-
level AccountReads/StorageReads/CodeReads tracking (the StateDB shouldn't
time its dependencies — the reader is where the I/O happens).
- Reader-level code-load dedup: *reader.codeLoaded sync.Map records the
first-seen byte length per address; CodeLoads() returns (count, bytes).
Exposed via state.CodeLoadTracker. Replaces StateDB CodeLoaded/
CodeLoadBytes tracking and the SnapshotCodeLoads aggregation pattern.
- BALStateTransition: caches BlockAccessList.WrittenCounts() once at
construction; tracks accountDeleted/storageDeleted atomics for the
parallel root-pass (the BAL alone can't distinguish a selfdestruct from
a balance/nonce reset). Exposes Deletions() DeletionCounts. Drops the
older accountUpdated/storageUpdated/codeUpdated/codeUpdateBytes counters
(now derived from WrittenCounts).
- BAL block stats path (blockchain.go): populates StateCounts directly —
AccountUpdated = WrittenCounts.Accounts - Deletions.Accounts (same for
storage). AccountLoaded/StorageLoaded come from BAL. CodeLoaded/
CodeLoadBytes come from the shared *reader (deduplicated across phase
StateDBs naturally because they share one reader instance).
- Non-BAL block stats path: read durations come from the reader; counts
from StateDB fields. StorageUpdated/StorageDeleted unified to int width.
- Hard type assertions: state.ReadTimer / state.CodeLoadTracker /
state.ReaderStater consumers use direct casts (no silent zero
fallback) — every Reader chain in production satisfies these
interfaces.
- Meter alignment: account/storage Updated meters subtract Deletions to
avoid double-reporting blocks under both Update and Delete dashboards.
Adapts some of the changes from
https://github.com/ethereum/go-ethereum/pull/34861 . Some other metrics
which are recorded manually during execution in that PR, but can be
deduced from the BAL are TBD.
I've added two bal feature flags:
* `--bal.prefetchworkers <uint>`: this tunes the number of concurrent
go-routines that will be used to perform state fetching tasks by the BAL
prefetcher. Default is `runtime.NumCPUs`, the current behavior in
`bal-devnet-3`.
* `--bal.blockingprefetch`: If set, state prefetching will block the
execution of transactions and state root update.
---------
Co-authored-by: CPerezz <cperezz19@pm.me>
The BAL reader tracker captures access list reads at the reader level.
When statedb has an account cached the BAL tracker is not informed of
the access. This is ok during the lifetime of a transaction because you
only need to record the access the first time. It is also ok during the
lifetime of a block because BAL reads are block-level (same as statedb
caches).
Where I think the issue can rise is in the miner. Namely when building a
block, if the miner picks up a tx which fails, it drops it and picks up
another tx to include. There might be some edge case here where the
failed tx which is not included poisons the cache and a future block
which is included omits an account because it wasn't aware of the
access.
To check whether a transaction can be applied, we validate that
`blockGasLimit > txGasLimit + (cumulativeRegularGasUsed +
cumulativeStateGasUsed)`. However, the check should only be applied to
the bottleneck resource, i.e. `blockGasLimit >
max(txRegularGasUsed+cumulativeRegularGasUsed, txStateGasUsed+
cumulativeStateGasUsed)`.
The changes here break multiple tests. I am trying to determine why.
---------
Co-authored-by: qu0b <stefan@starflinger.eu>
* add method on StateReaderTracker to clear the accumulated reads
* don't factor the BAL size into the payload size during construction in the miner
* simplify miner code for constructing payloads-with-BALs via the use of aformentioned StateReaderTracker clear method
* clean up the configuration of the BAL execution mode based on the preset flag specified
CopyHeader copies all pointer-typed header fields (WithdrawalsHash,
RequestsHash, SlotNumber, etc.) but was missing the deep copy for
BlockAccessListHash added by EIP-7928. This caused the BAL hash
to be silently shared between the original and the copy, leading
to potential data races and incorrect nil-checks on copied headers.
Add persistent storage for Block Access Lists (BALs) in `core/rawdb/`.
This provides read/write/delete accessors for BALs in the active
key-value store.
---------
Co-authored-by: Jared Wasinger <j-wasinger@hotmail.com>
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
`pool.signer.Sender(tx)` bypasses the sender cache used by types.Sender,
which can force an extra signature recovery for every promotable tx
(promotion runs frequently). Use `types.Sender(pool.signer, tx)` here to
keep sender derivation cached and consistent.
Problem:
The max-initcode sentinel moved from core to vm, but RPC pre-check
mapping still depended on core.ErrMaxInitCodeSizeExceeded. This mismatch
could surface inconsistent error mapping when oversized initcode is
submitted through JSON-RPC.
Solution:
- Remove core.ErrMaxInitCodeSizeExceeded from the core pre-check error
set.
- Map max-initcode validation errors in RPC from
vm.ErrMaxInitCodeSizeExceeded.
- Keep the RPC error code mapping unchanged (-38025).
Impact:
- Restores consistent max-initcode error mapping after the sentinel
move.
- Preserves existing JSON-RPC client expectations for error code -38025.
- No consensus, state, or protocol behavior changes.
Fix incorrect key length calculation for `numHashPairings` in
`InspectDatabase`, introduced in #34000.
The `headerHashKey` format is `headerPrefix + num + headerHashSuffix`
(10 bytes), but the check incorrectly included `common.HashLength`,
expecting 42 bytes.
This caused all number -- hash entries to be misclassified as
unaccounted data.
## Summary
In binary trie mode, `IntermediateRoot` calls `updateTrie()` once per
dirty account. But with the binary trie there is only one unified trie
(`OpenStorageTrie` returns `self`), so each call redundantly does
per-account trie setup: `getPrefetchedTrie`, `getTrie`, slice
allocations for deletions/used, and `prefetcher.used` — all for the same
trie pointer.
This PR replaces the per-account `updateTrie()` calls with a single flat
loop that applies all storage updates directly to `s.trie`. The MPT path
is unchanged. The prefetcher trie replacement is guarded to avoid
overwriting the binary trie that received updates.
This is the phase-1 counterpart to #34021 (H01). H01 fixes the commit
phase (`trie.Commit()` called N+1 times). This PR fixes the update phase
(`updateTrie()` called N times with redundant setup). Same root cause —
unified binary trie operated on per-account — different phases.
## Benchmark (Apple M4 Pro, 500K entries, `--benchtime=10s --count=3`,
on top of #34021)
| Metric | H01 baseline | H01 + this PR | Delta |
|--------|:------------:|:-------------:|:-----:|
| Approve (Mgas/s) | 368 | **414** | **+12.5%** |
| BalanceOf (Mgas/s) | 870 | 875 | +0.6% |
Should be rebased after #34021 is merged.
EIP-7928 brings state reads into consensus by recording accounts and storage accessed during execution in the block access list. As part of the spec, we need to check that there is enough gas available to cover the cost component which doesn't depend on looking up state. If this component can't be covered by the available gas, we exit immediately.
The portion of the call dynamic cost which doesn't depend on state look ups:
- EIP2929 call costs
- value transfer cost
- memory expansion cost
This PR:
- breaks up the "inner" gas calculation for each call variant into a pair of stateless/stateful cost methods
- modifies the gas calculation logic of calls to check stateless cost component first, and go out of gas immediately if it is not covered.
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
This PR introduces a new type HistoryPolicy which captures user intent
as opposed to pruning point stored in the blockchain which persists the
actual tail of data in the database.
It is in preparation for the rolling history expiry feature.
It comes with a semantic change: if database was pruned and geth is
running without a history mode flag (or explicit keep all flag) geth
will emit a warning but continue running as opposed to stopping the
world.
## Summary
**Bug fix.** In Verkle mode, all state objects share a single unified
trie (`OpenStorageTrie` returns `self`). During `stateDB.commit()`, the
main account trie is committed via `s.trie.Commit(true)`, which calls
`CollectNodes` to traverse and serialize the entire tree. However, each
dirty account's `obj.commit()` also calls `s.trie.Commit(false)` on the
**same trie object**, redundantly traversing and serializing the full
tree once per dirty account.
With N dirty accounts per block, this causes **N+1 full-tree
traversals** instead of 1. On a write-heavy workload (2250 SSTOREs),
this produces ~131 GB of allocations per block from duplicate NodeSet
creation and serialization. It also causes a latent data race from N+1
goroutines concurrently calling `CollectNodes` on shared `InternalNode`
objects.
This commit adds an `IsVerkle()` early return in `stateObject.commit()`
to skip the redundant `trie.Commit()` call.
## Benchmark (AMD EPYC 48-core, 500K entries, `--benchtime=10s
--count=3`)
| Metric | Baseline | Fixed | Delta |
|--------|----------|-------|-------|
| Approve (Mgas/s) | 4.16 ± 0.37 | **220.2 ± 10.1** | **+5190%** |
| BalanceOf (Mgas/s) | 966.2 ± 8.1 | 971.0 ± 3.0 | +0.5% |
| Allocs/op (approve) | 136.4M | 792K | **-99.4%** |
Resolves the TODO in statedb.go about the account trie commit being
"very heavy" and "something's wonky".
---------
Co-authored-by: Guillaume Ballet <3272758+gballet@users.noreply.github.com>
