…ytes
SelfDestructRefundBytes iterates s.stateObjects and previously called
IsNewContract / HasSelfDestructed on each entry to filter for accounts
that were both created and selfdestructed in the current transaction.
Both helpers go through StateDB.getStateObject, which unconditionally
records an EIP-7928 account read via s.stateReadList.AddAccount(addr).
The effect is that *every* live entry in the stateObjects cache gets
added to the per-tx read list whenever a tx triggers the EIP-8037
selfdestruct refund check (i.e. on every successful tx post-Amsterdam).
This pollutes the BAL with addresses the tx never actually touched.
In the miner, the cache may contain accounts loaded by earlier failed-tx
attempts (preCheck via getStateObject loaded them; RevertToSnapshot does
not evict the cache because reads aren't journaled). Validators
re-executing the sealed block don't have those cached entries, so they
don't reproduce the reads. Result: BAL hash mismatch on otherwise
deterministic execution.
Use direct field access on the already-iterated *stateObject so the
filter doesn't go through getStateObject. Functionally equivalent --
newContract and selfDestructed are the same fields the helpers consult
-- but with no read-list side effect.
## Summary
Marks `amsterdam` as `optional` in the blob-schedule fork-validation
table in `params/config.go::CheckConfigForkOrder`, so that a chain
config setting `amsterdamTime` no longer requires a corresponding
`blobSchedule.amsterdam` entry to be present.
## Why
Hive's `clients/<el>/mapper.jq` removed the `amsterdam` block from the
generated `blobSchedule` in
[ethereum/hive#1387](https://github.com/ethereum/hive/pull/1387)
("Remove Amsterdam blob param defaults — values are wrong; we agreed to
remove named forks from blob config").
With strict validation in place, every hive simulator that activates
Amsterdam — including `ethereum/eels/consume-engine` against
`bal-devnet-4` — now fails immediately at `geth init`:
```
Fatal: Failed to write genesis block: invalid chain configuration:
missing entry for fork "amsterdam" in blobSchedule
```
This shows up in the latest scheduled CI runs of
[ethpandaops/hive-tests](https://github.com/ethpandaops/hive-tests) as a
flood of `"could not start client … terminated unexpectedly"` errors on
Amsterdam tests (the simulator job is marked "success" only because the
simulator process itself completes — `tests=46285 failed=24369`).
The `bal-devnet-3` branch already carried a relaxation for the same
reason (commit
[`265d74b75`](https://github.com/ethereum/go-ethereum/commit/265d74b75)
commented the entire check out). This change is narrower:
- only `amsterdam` is marked optional,
- every other fork (`cancun`, `prague`, `osaka`, `bpo1..bpo5`) keeps its
strict check,
- `cur.config.validate()` still runs whenever a caller *does* supply a
blob entry, so misconfigured Amsterdam blob params remain rejected.
It also matches the pattern already used in the fork-ordering table just
above, where `amsterdam` and the BPO timestamps are likewise marked
`optional: true`.
## Test plan
- `go build ./...` and `go test ./params/...` pass locally.
- Reproduced the original failure: a freshly-built
`ethpandaops/geth:bal-devnet-4` errors at `geth init` on a genesis with
`amsterdamTime` set but no `blobSchedule.amsterdam`. With this patch
applied, the same `geth init` succeeds and writes the genesis state.
- Suggest re-running `ethpandaops/hive-tests` workflow
`hive-devnet-4.yaml` against this branch (`common_client_tag:
qu0b/relax-amsterdam-blobschedule-validation`, `client_source: git`) to
confirm Amsterdam tests start the client cleanly.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
getPending builds the pending block on demand via generateWork, but after
EIP-7843 (#33589) prepareWork rejects the call unless generateParams.slotNum
is non-nil once Amsterdam is active:
if miner.chainConfig.IsAmsterdam(header.Number, header.Time) {
if genParams.slotNum == nil {
return nil, errors.New("no slot number set post-amsterdam")
}
header.SlotNumber = genParams.slotNum
}
getPending never populated slotNum, so on any Amsterdam-activated chain
eth_getBalance(addr, "pending") (and every other RPC that resolves through
the pending state) fails with "pending state is not available", breaking
faucets and nonce trackers that poll pending.
Fix by synthesising a slot number from the parent header when available,
mirroring how the Shanghai branch above already conditionally populates
withdrawals. The pending block is empty post-merge so the exact slot value
is not user-visible; SlotNumber+1 (or zero) is sufficient to satisfy the
prepareWork invariant.
Observed on a bal-devnet-3 Geth build: every eth_getBalance(...,"pending")
returned -32000 "pending state is not available" until the faucet was
repointed at a non-Geth EL. Other clients (Nethermind, Besu, Reth, Erigon,
Ethrex) serve pending on the same chain without issue.
ExecutableData.BlockAccessList was added to the struct in types.go but
gen_ed.go was never regenerated, so MarshalJSON/UnmarshalJSON silently
dropped the field. engine_getPayloadV6 responses were emitted without
blockAccessList, which Prysm rejected with "missing required field
'blockAccessList' for ExecutionPayload", preventing any block
production post-genesis.
Regenerated via `go generate ./beacon/engine/`.
The stateReadList field introduced by #34776 to track the state access
footprint for EIP-7928 was not propagated by StateDB.Copy. Every other
per-transaction field that lives alongside it (accessList,
transientStorage, journal, witness, accessEvents) is copied explicitly,
so this field was simply missed.
After Copy the copy's stateReadList is nil while the original keeps its
entries, so the nil-safe guards on StateAccessList.AddAccount / AddState
silently drop every access recorded on the copy. For any post-Amsterdam
code path that copies a prepared state and keeps reading from the copy,
the BAL footprint becomes incomplete.
Add a Copy method on bal.StateAccessList and invoke it from
StateDB.Copy, matching the pattern used for accessList and accessEvents.
---------
Co-authored-by: jwasinger <j-wasinger@hotmail.com>
The testPeer request counters (nAccountRequests, nStorageRequests,
nBytecodeRequests, nTrienodeRequests) were plain int fields incremented
with ++. These increments happen in Request* methods that are invoked
concurrently by the Syncer from multiple goroutines
(assignBytecodeTasks, assignStorageTasks, etc.), causing a data race
reliably detected by go test -race.
Change the counters to atomic.Int64 so increments and reads are
synchronized without introducing a mutex.
Fixes races detected in TestMultiSyncManyUseless,
TestMultiSyncManyUselessWithLowTimeout,
TestMultiSyncManyUnresponsive, TestSyncWithStorageAndOneCappedPeer,
TestSyncWithStorageAndCorruptPeer, and
TestSyncWithStorageAndNonProvingPeer.
scheduleFetches.func1 is the single biggest allocator in the Pyroscope
profile of a busy node (~13.5 GB/hr, 8% of total alloc_space). Each
peer-iteration pre-allocated 'make([]common.Hash, 0, maxTxRetrievals)'
= 8 KB, even for peers that end up collecting no new hashes (all their
announces were already being fetched by someone else).
Defer the slice allocation to the first append. Peers that collect zero
hashes now pay zero allocation, which is the common case on the
timeoutTrigger path where all peers with any announces are iterated.
New benchmarks BenchmarkScheduleFetches_{100peers_10new,
100peers_allFetching, 500peers_3new} (benchstat, 6 samples):
scenario ns/op B/op allocs/op
100p/10new unchanged unchanged unchanged (fast path)
100p/allFetching -62% -92% -20%
500p/3new -22% -44% -7%
geomean -33% -65% -9%
`StateSetWithOrigin.decode()` was missing size computation after
deserializing origin data, causing `size` to remain zero after journal
reload. Added the same calculation logic used in
`NewStateSetWithOrigin()`.
This PR updates the BAL structure definition to the latest the spec,
- Balance has been changed from [16]byte to uint256
- Storage key and value has been changed from [32]byte to uint256
- BlockAccessList has been changed from a struct to a slice of
AccountChanges
- TxIndex has been changed from uint16 to uint32
The stateReadList field introduced by #34776 to track the state access
footprint for EIP-7928 was not propagated by StateDB.Copy. Every other
per-transaction field that lives alongside it (accessList,
transientStorage, journal, witness, accessEvents) is copied explicitly,
so this field was simply missed.
After Copy the copy's stateReadList is nil while the original keeps its
entries, so the nil-safe guards on StateAccessList.AddAccount / AddState
silently drop every access recorded on the copy. For any post-Amsterdam
code path that copies a prepared state and keeps reading from the copy,
the BAL footprint becomes incomplete.
Add a Copy method on bal.StateAccessList and invoke it from
StateDB.Copy, matching the pattern used for accessList and accessEvents.
---------
Co-authored-by: jwasinger <j-wasinger@hotmail.com>
The testPeer request counters (nAccountRequests, nStorageRequests,
nBytecodeRequests, nTrienodeRequests) were plain int fields incremented
with ++. These increments happen in Request* methods that are invoked
concurrently by the Syncer from multiple goroutines
(assignBytecodeTasks, assignStorageTasks, etc.), causing a data race
reliably detected by go test -race.
Change the counters to atomic.Int64 so increments and reads are
synchronized without introducing a mutex.
Fixes races detected in TestMultiSyncManyUseless,
TestMultiSyncManyUselessWithLowTimeout,
TestMultiSyncManyUnresponsive, TestSyncWithStorageAndOneCappedPeer,
TestSyncWithStorageAndCorruptPeer, and
TestSyncWithStorageAndNonProvingPeer.
scheduleFetches.func1 is the biggest allocator in the long-duration
profile of node (11% of total alloc_space).
Each peer-iteration pre-allocated make([]common.Hash, 0, maxTxRetrievals),
even for peers that end up collecting no new hashes (all their announces
were already being fetched by someone else).
Defer the slice allocation to the first append. Peers that collect zero hashes
now pay zero allocation, which is the common case on the timeoutTrigger
path where all peers with any announces are iterated.
When `rpc.Client.Close()` is called, the TCP connection is torn down
without sending a WebSocket Close frame. The server sees `websocket:
close 1006 (abnormal closure): unexpected EOF` instead of a clean 1000
(normal closure).
### Root cause
`websocketCodec.close()` delegates to `jsonCodec.close()` which calls
`c.conn.Close()` — gorilla/websocket's `Conn.Close` explicitly "[closes
the underlying network connection without sending or waiting for a close
message](https://pkg.go.dev/github.com/gorilla/websocket#Conn.Close)"
(per RFC 6455).
### Fix
Send a WebSocket Close control frame (opcode 0x8, status 1000) before
closing the underlying connection. Uses `WriteControl` with the same
`encMu` mutex pattern already used by `pingLoop` for write
serialization, and reuses the existing `wsPingWriteTimeout` (5s)
constant.
`WriteControl` errors are safe to ignore — the connection may already be
broken by the time we attempt the close frame.
Fixes#30482
This PR adds three cell-level kzg functions required for the sparse
blobpool (eth/72).
- VerifyCells: Verifies cells corresponding to proofs. This is used to
verify cells received from eth/72 peers.
- ComputeCells: Computes cells from blobs. This is needed because user
submissions and eth/71 transaction deliveries contain blobs, while
eth/72 peers expect cells.
- RecoverBlobs: Recovers blobs from partial cells. This is needed to
support both eth/71 and eth/72
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
scheduleFetches.func1 is the single biggest allocator in the Pyroscope
profile of a busy node (~13.5 GB/hr, 8% of total alloc_space). Each
peer-iteration pre-allocated 'make([]common.Hash, 0, maxTxRetrievals)'
= 8 KB, even for peers that end up collecting no new hashes (all their
announces were already being fetched by someone else).
Defer the slice allocation to the first append. Peers that collect zero
hashes now pay zero allocation, which is the common case on the
timeoutTrigger path where all peers with any announces are iterated.
New benchmarks BenchmarkScheduleFetches_{100peers_10new,
100peers_allFetching, 500peers_3new} (benchstat, 6 samples):
scenario ns/op B/op allocs/op
100p/10new unchanged unchanged unchanged (fast path)
100p/allFetching -62% -92% -20%
500p/3new -22% -44% -7%
geomean -33% -65% -9%
The rlpx ping command mishandled disconnect responses on two counts:
the error return from rlp.DecodeBytes was ignored, so decode failures
silently produced an "invalid disconnect message" error with no context;
and the decoder assumed the spec-compliant list form exclusively, while
older geth and some other implementations send the reason as a bare
byte.
Accept both wire forms (matching the legacy-tolerant behavior already
in p2p.decodeDisconnectMessage), and on decode failure include the raw
payload so operators can see exactly what the peer sent. Add a unit
test for the decoder covering both forms plus the empty-payload error
path.
This PR reverts the last change to the freebsd build, and it fixes the
_direct_ FreeBSD build.
Here, we change the upstream of github.com/karalabe/hid to its new home,
github.com/ethereum/hid. The new dependency includes a dummy.go file
that makes `go mod vendor` work.
##### Origin of the problem
Enrique is maintaining the FreeBSD ports, and FreeBSD ports only support
vendored go modules. It turns out that `go mod vendor` will not include
C files if there is no `.go` file in the directory. Since the C files
were missing for `karalabe/hid`, the ports maintainer tried to use the
version of `hidapi` that is provided by the ports. To do so, he had to
modify the way things are included. This broke the _out of ports_
FreeBSD build.
Difference to Appveyor:
- Missing 386 build. Hit some issue because user-space memory there is
around 2Gbs. Also seems generally extremely niche.
- Not doing the archive step and NSIS installer and uploads (those are
done on the builder).
