besu-eth/besu

Summary The snap/2 GetBlockAccessLists handler has no dedicated per-request lookup cap, unlike its sibling snap handlers (GetByteCodes, GetStorageRanges) and the eth/71 GetBlockAccessLists handler. This is a consistency/hardening gap, not a vulnerability: the request is already bounded, just by much looser limits. Details SnapServer.constructGetBlockAccessListsResponse loops over every requested hash and calls blockchain.getBlockAccessList(blockHash) (SnapServer.java:~285-297). The only limits on that loop come from the shared ResponseSizePredicate: MAX_ENTRIES_PER_REQUEST = 100000 (SnapServer.java:75, enforced at :806) a 4 s per-request time budget (DEFAULT_MAX_MILLIS_PER_REQUEST, :762) the response byte budget (MAX_RESPONSE_SIZE = 2 MiB, :76) calculateBlockAccessListEncodedSize counts a missing BAL as 1 byte (SnapServer.java:~841), so unknown hashes barely consume the byte budget and the effective bound is the 100k-entry / 4 s one. Stored BALs are also fully decoded from storage ju

Steps to Reproduce Run Besu with named ephemery network Observe it does not get peers besu --p2p-port 30303 --discovery-mode BOTH --rpc-http-enabled --rpc-http-host 0.0.0.0 --rpc-http-port 8545 --rpc-http-cors-origins=* --rpc-http-max-active-connections=65536 --rpc-max-logs-range=65536 --rpc-ws-enabled --rpc-ws-host 0.0.0.0 --rpc-ws-port 8546 --host-allowlist=* --engine-host-allowlist=* --engine-jwt-secret=/var/lib/besu/ee-secret/jwtsecret --engine-rpc-port=8551 --logging info --metrics-enabled --metrics-host 0.0.0.0 --metrics-port 6060 --nat-method=DOCKER --data-path /var/lib/besu --network ephemery Further detail Besu uses chain ID 39438163, which matches Ephemery iteration 163. The Geth peers (v1.16.5 and v1.17.5) accept its status message (validated? true). Right after Besu's first header request (GetHeadersFromPeerTask), they disconnect it with 0x10 SUBPROTOCOL_TRIGGERED. Besu advertises eth/68–eth/71 and snap/1. It happens with the built-in bootnodes, with the release's enod

Description As an RPC node operator, I want the ability to import EraE history files so that I can sync a full node quickly. Similar to the existing era1 support, but updated for erae. It was possible to sync a node with --snapsync-synchronizer-pre-checkpoint-headers-only-enabled=false until 26.8.0. Now full sync, optionally with era1 files, is the remaining option. Not part of this request: The ability to generate / export EraE files Acceptance Criteria New parameter --erae-import-prepipeline-enabled New parameter --erae-data-uri, maybe defaulting to https://data.ethpandaops.io/erae/mainnet/ Alias parameter --erae-import-prepipeline-concurrency, same value as --era1-import-prepipeline-concurrency Full sync node can catch up from a set of full history EraE files

Steps to Reproduce Run Besu 26.8.1 with --rpc-ws-enabled=true --rpc-ws-max-active-connections=1000. Point any client that keeps opening/closing WebSocket connections at the WS port at a steady rate (health probe, reconnecting subscriber, connection broker — anything that generates fresh handshakes). Watch WebSocketService's reported active-connections count (via the Rejecting new connection ... N/M WARN log or the active_ws_connection_count Prometheus gauge). It only ever grows. Cross-check with ss / netstat inside the Besu process's network namespace — real TCP connection count stays flat. After N minutes (depending on rate) the counter passes the configured cap and Besu starts rejecting every new WS handshake until the process is restarted. Expected behavior: activeConnectionsCount decrements when the underlying TCP/WS connection closes, so the counter matches the real number of open sockets, and the cap only fires when real load approaches it. Actual behavior: The counter clim

Summary callTracer with tracerConfig: {"onlyTopCall": true} was fixed in #10967 (issue #10955) to return only the root frame, but Besu still collects a full opcode-level trace before discarding it. For deep/expensive transactions this means allocating a TraceFrame (with stack/memory/storage snapshots) per opcode for a request whose caller explicitly asked to skip exactly that work. Current flow DebugTraceTransaction, DebugTraceCall, and DebugTraceBlockStreamer each construct a DebugOperationTracer/StreamingDebugOperationTracer unconditionally before execution. tracePostExecution appends a frame for every opcode regardless of onlyTopCall. Only afterward does CallTracerResultConverter.convert(trace, onlyTopCall) (added in #10967) discard that work and return just the root. Why it's safe to skip earlier Tracers in Besu are pure observers — gas/output/error/revertReason all come from TransactionProcessingResult, computed by the EVM independent of whether any tracer is attached (the same