This PR fixes the incorrect size calculation for blob sidecar. The
original formula is for legacy sidecar without the version tag. As the
legacy version has been deprecated and no longer supported by the Geth's
blobPool, the size calculation should also be flipped to sidecar v1.
commitPivotBlock updated committed without pivotLock, while other pivot
transitions serialize through that lock. Take the lock around the store
to keep pivot commitment consistent with pivotHeader updates.
This PR coordinates the prefetcher with the main tx executor. Block
processing publishes the index of the transaction it is executing,
prefetch workers skip anything already reached and transactions above 1M
gas are promoted to the front of the prefetch queue while the rest keeps
block order.
The deep-reorg check used depth >= maxReorgDepth, rejecting reorgs at
exactly the configured limit. Use > so a depth equal to maxReorgDepth is
still accepted.
When a peer drop removes the last waiter for a hash, waitlist and
waittime were cleaned up but partial could retain a stale entry. Delete
it too so the hash is fully forgotten.
This PR improves the sync mode management, disabling the snap mode once
the pivot block is committed.
Originally the mode will only be flipped from snap to full once the entire sync
cycle is completed. However, it's theoretically possible to cancel the sync cycle
after committing the pivot but before inserting the remaining blocks. It drags
the following sync cycle back to the snap mode.
The snap mode should only be used if the head state is missing and unrecoverable.
Enabling the snap mode for multiple times should be strictly prevented.
What's more, it brings a fix to pivot block management, that once the
pivot block is committed, the pivot block marker should be no longer advanced,
preventing the situation that the real pivot state is below the pivot marker.
Restarting a node mid-snap-sync can crash-loop during startup chain
repair. On a restart mid-sync the pathdb is disabled (`waitSync`), so
repair rewinds the stateless head to genesis and asks `StateRecoverable`
if it can roll back there. `Recoverable` doesn't check `waitSync`, so it
reports genesis as recoverable, but `Recover` does and refuses with
`waiting for sync`, tripping a `log.Crit`. The flag is persisted, so the
node crash-loops on every restart.
CRIT Failed to recover state number=0 hash=37fcdc..6edf0b err="waiting
for sync"
The fix is to make `Recoverable` return false while a sync is running,
so it agrees with `Recover`. Repair then falls through to the existing
"wait state sync" path.
This PR adds the CLI flag gogc for twisting the garbage collection
target. The default value is chosen as the 50, balancing the
performance gain and potential memory peak.
blobFetcherQueueingHashes used len(announces), which is the number of
peers with pending announces, not the number of queued hashes. Count
unique hashes across peers instead.
---------
Co-authored-by: Bosul Mun <bsbs8645@snu.ac.kr>
Now with 8037, there are transactions that fail AFTER intrinsic gas but
BEFORE Call or Create operation. These will currently result in a panic
in tracing, since they produce a receipt
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
`conversionQueue` is meant to run billy/legacy migrations serially on a
single worker. On each `startConversion`, it currently always calls
`runNextTask()`, which overwrites `taskDone` and starts another
goroutine even when a migration is already running.
That breaks two invariants during an upgrade with legacy entries in both
the main store and limbo:
1. Migrations intended to be serial can run concurrently.
2. `close()` only waits for the most recently launched task, so shutdown
can close the stores while a forgotten migration is still using them.
Only start the next queued migration when no task is active (`taskDone
== nil`). The existing `taskDone` completion path then advances the
queue, and `close` reliably waits for the active task.
Commit 1f87331fb moved the known-transaction marking in
`sendPooledTransactionHashes` to after a successful send, so hashes are
not marked known to the peer if the announcement fails to go out.
The sparse blobpool change (d91b71fb3) reintroduced the original
track-before-send ordering when adding the eth/72 packet variant,
causing failed announcements to suppress future re-announcements of the
same hashes to that peer.
This restores the send-first ordering for both eth/71 and eth/72 packet
versions, and adds a regression test covering success and failure paths
on both protocol versions.
## Checklist
- [x] Restored mark-known-after-send for ETH71 and ETH72
- [x] Added `TestSendPooledTransactionHashes` covering success and
closed-pipe failure
---------
Co-authored-by: Bosul Mun <bsbs8645@snu.ac.kr>
Follow-up to #34850. The miner's payload EVM previously used a private
per-EVM JUMPDEST map, so every ~2s payload rebuild re-analyzed the code
bitmap of every contract the block touches.
`Chain.GetHeaders` steps by `1 + Skip` in the forward branch but by `1 -
Skip` in the reverse branch. `Skip` is a `uint64`, so the reverse stride
is wrong for every `Skip > 0`:
| Skip | reverse step | result |
| --- | --- | --- |
| 0 | `-= 1` | correct |
| 1 | `-= 0` | block number never moves, the same header is returned
`Amount` times |
| >= 2 | `1 - Skip` underflows | walks *forward* instead of back (`Skip
= 2` on block 100 lands on 101) |
Per the `GetBlockHeadersRequest` definition, `Skip` is "Blocks to skip
between consecutive headers", so the stride is `Skip + 1` in whichever
direction the query runs. Subtracting `1 + Skip` makes the reverse
branch mirror the forward one.
The existing table test covers forward + `Skip: 1` and reverse + `Skip:
0` (which works by accident, since `1 - 0 == 1`). Added the missing
reverse + `Skip: 1` case; it fails on master:
```
--- FAIL: TestChainGetHeaders/3
Test: TestChainGetHeaders/3
FAIL github.com/ethereum/go-ethereum/cmd/devp2p/internal/ethtest
```
and passes with the fix (4/4).
No caller sends a reverse request with `Skip > 0` today, so nothing is
broken in the current suite. The helper computes the expected headers
that responses are checked against, though, so the moment a reverse+skip
case is added it would silently assert the wrong headers rather than
fail loudly.
This is the implementation of EIP-8070 Sparse Blobpool. It introduces
protocol version eth/72 which relays blob transaction cells instead of
full blobs.
The blobpool now store 'incomplete' transactions, where only some of
the cells are provided. The stored cell indexes are taken from the
custody bitmap, which is provided by the consensus layer in
forkchoiceUpdatedV4. This method will be called once Glamsterdam
activates, and the default custody is full custody, so for now there
is no change in the amount of stored cells for now.
The main entities added are the BlobBuffer and BlobFetcher, which work
together to track and fetch missing cells from connected peers. The
partial transactions become available for inclusion in blocks when
they are covered by enough peers that hold all cells.
This change also introduces engine_getBlobsV4, which allows for
cell-based responses (and partial blobs with only some of the cells).
We maintain backward compatibility with getBlobsV3 which expects full
blob responses by recovering the blob from available cells. Since this
process is resource-intensive, we proactively cache the conversion so
it is ready in time for getBlobsV3 calls. This mechanism will be
removed once support for getBlobsV4 is universal across all consensus
layer implementations.
devp2p tests for eth/72 are not part of this initial change. This is
to avoid breaking test success status for execution clients that do
not have eth/72 implemented yet. The tests will be added in a
subsequent change.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
- Move `msg.Discard` defer ahead of the max message size check in
`handleMessage`.
- Ensures oversized messages are released when the handler returns
early.
The DNS discovery crawler (ethereum/discv4-crawl) builds signed enrtree
lists by crawling the network and running the collected records through
`devp2p nodeset filter` and `devp2p dns sign`. Those records come from
external nodes, and `enr.Record` keeps entries it can't decode as raw
RLP, so a self-signed record with an out-of-range port (EIP-778 defines
ports only as "big endian integer", not `uint16`) can round-trip
verbatim into a signed tree. Consumers that decode ports strictly then
fail to decode that record.
Two publish-side checks:
- `MakeTree` rejects a record if a present port entry
(`tcp`/`tcp6`/`udp`/`udp6`/`quic`/`quic6`) does not decode as a
`uint16`. This is an invariant at the signing boundary: geth won't sign
a tree containing a record with an undecodable port, regardless of how
the node list was produced. Absent and zero ports are unaffected.
- `devp2p nodeset filter -dialable` keeps only nodes advertising a
usable RLPx port (non-zero `tcp`/`tcp6`/`quic`/`quic6`), letting the
crawler drop discovery-only and unreachable nodes so consumers aren't
handed peers they can't connect to.
The two are deliberately separate: the `MakeTree` check is a correctness
guard that always applies, while `-dialable` is an opt-in selection
filter for the crawler pipeline. A follow-up will add `-dialable` to
discv4-crawl's `filter_list`.
When we are deploying library dependencies, if the `TransactOpts` nonce
is unset we will choose the nonce of the next deployment transaction
based on the pending nonce of the sender. If a previous library
deployment transaction was made but not yet accepted into the pool, the
pending nonce will not be updated for the the next deployment
transaction.
This PR introduces a new method to the bind API `WaitAccepted` which
poll until a submitted transaction hash is accepted into the pool or
rejected. The bindings for v1 are updated to invoke this method after
deploying each library dependency.
## Summary
- Only apply user-configured `MaxBlobsPerBlock` when it is strictly
below the protocol-defined maximum.
- Prevents the miner from building blocks that exceed the consensus blob
limit.
## Test plan
- [x] `go test -short ./miner/`
WithAttrs and terminalFormat appended to h.attrs directly, which can
mutate the shared slice when it has spare capacity. Clone attrs first to
avoid corrupting parent handler state.
The peer dropper periodically disconnects random peers to create churn.
This was previously blind to peer quality.
This PR adds peer-score based peer protection, handling the
multi-dimensionality problem of peer scoring through the concept of
protected peer pools.
---------
Signed-off-by: Csaba Kiraly <csaba.kiraly@gmail.com>
Co-authored-by: healthykim <bsbs8645@snu.ac.kr>
## Summary
Sanity fixes surfaced by running the EELS `tests@v20.0.0` fixture
release (63,109 blockchain tests) through `evm blocktest`.
Also bumps CI to consume the new release: `build/checksums.txt` now
points at `tests@v20.0.0` / `fixtures.tar.gz` from
`ethereum/execution-specs` (supersedes the archived EEST repo's
`fixtures_develop`).
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
