A maintenance release for failures that hide behind normal operation
Erigon published version 3.6.1 at 20:41 UTC on September 9 as a bug-fix and security release recommended for its users. The Ethereum client project says operators already running 3.6.0 can install it without resynchronizing their nodes. The update addresses several different faults, but they share a practical theme: software should not quietly discard trusted local data, admit a peer that its own records have banned or retry a deterministic build with contaminated state.
These are client-level corrections, not changes to Ethereum’s protocol rules. Their inclusion in a final release establishes that Erigon’s maintainers packaged the code, not that every operator installed it. The release and linked pull requests are also first-party evidence. They document implementation decisions, tests and one node’s observations, but provide neither an independent security audit nor measurements across a representative fleet.
Giving completed local data an explicit ownership rule
Erigon uses snapshots to store portions of blockchain history in compact files. A node can obtain those files through a torrent-based distribution system, while an operator may also rebuild data locally. That creates a question of authority when a local segment file and its torrent metadata no longer have the same hash. During an initial download, the published manifest may need to remain authoritative. After synchronization is complete, silently replacing a present local file can instead destroy work the node has already accepted.
The repair in pull request 23859 distinguishes those conditions. Once the completed data directory contains its preverified manifest, a snapshot that is already present is kept rather than downloaded over. A missing snapshot is still fetched. During an incomplete synchronization, the manifest continues to control the process, but a mismatch that causes replacement is now recorded at warning level with information intended to expose the cause.
That visibility matters because the earlier behavior could create a hole in the snapshot tier. Later reads might fall through to the database and surface as an incorrect nonce or trie-root problem, far from the original file operation. A warning does not repair damaged data, but it connects the downstream symptom to the earlier decision. The retained file is also added to Erigon’s torrent bookkeeping so it remains visible to node statistics. The pull-request discussion notes a separate pre-existing branch defect that can still prevent such a retained file from uploading, so registration should not be confused with proof that seeding succeeds in every configuration.
A peer ban has to cover incoming connections too
The network fix concerns Caplin, Erigon’s consensus-layer implementation. A peer ban is meant to stop repeated interactions with a remote participant that has crossed the client’s configured failure threshold. The project found that its ban status was consulted when Erigon initiated an outbound connection but not when the same peer connected inbound. A banned peer could therefore return and receive another handshake whenever it approached the node from the other direction.
Version 3.6.1 applies the recorded ban before accepting that inbound handshake. This does not make peer-to-peer networking attack-proof, and the repository does not claim that the bypass compromised Ethereum consensus. It closes an inconsistency between two paths that were supposed to enforce the same local policy. Symmetric enforcement is important because an admission decision loses much of its value if the remote party can choose the unchecked direction.
Erigon reports that one Gnosis archive node recorded 13,827 failed handshakes involving 1,638 banned peers during a 90-minute period. That observation illustrates how a small admission gap can generate substantial repeated work, but it remains a measurement from one project-observed node. It does not reveal how common the pattern was across Erigon deployments, whether the connections were coordinated or how much processor time, bandwidth or memory the new check saves.
A clean retry must discard the failed attempt
Another repair targets recsplit, an indexing system used to map stored keys efficiently. Its construction process may encounter a salt collision and retry with a new salt. The defect was not that retrying was inherently unsafe. The problem was that the retry changed the salt without clearing every structure populated by the failed attempt.
The merged correction resets the Golomb-Rice encoder, the Elias-Fano structure and the existence filter before building again. These are compact data structures used to encode and locate information. If bits from an abandoned attempt remain, the next index can combine two incompatible construction histories and become corrupt even though the second run appears to complete. Resetting all related state turns a retry into a genuinely new attempt.
This is a broadly useful reliability principle. Recovery code deserves the same scrutiny as the main path because it operates after an unusual condition has already occurred. A retry that preserves hidden state can transform a detectable collision into a less obvious data-integrity failure. Erigon’s repository records the code change and project tests, but it does not provide an independent survey of affected databases or show how often real index builds encountered the condition.
Smaller boundaries around dependency and discovery risks
The release also upgrades Erigon’s gRPC dependency to version 1.83.2 for two upstream vulnerabilities classified as high severity by the project. One involved fragmented HTTP/2 data frames accumulating as separate receive messages, creating a memory-exhaustion path. The other concerned an xDS server panic when required authority information was absent. Erigon says the xDS path was not reachable in its client because it does not construct that kind of server. That is a scoped dependency assessment, not evidence that every integration around an Erigon node is unaffected.
At the peer-discovery layer, Erigon now requires evidence of a recent return path before accepting an endpoint claimed in a PING message. A corresponding PONG establishes that the sender can receive traffic at the asserted location. Without that bond, an arbitrary address could influence the node’s local endpoint prediction. The added condition does not prove a peer trustworthy. It verifies one narrower statement before allowing that statement to alter local network knowledge.
Erigon also replaced a hardcoded data-column retention window with values derived from each chain’s configuration, guarded against zero and overflow inputs. That matters as Ethereum clients take on PeerDAS responsibilities involving distributed custody of data columns. Configuration-derived retention reduces the risk that one network’s assumptions are applied unchanged to another, while the input guards prevent invalid parameters from turning into unsafe arithmetic.
Operational progress that still needs deployment evidence
Version 3.6.1 improves several boundaries that operators depend on but rarely see: when local files become authoritative, when a ban must be enforced, what state survives a retry and which network claims require proof of reachability. These changes can make failures easier to diagnose and reduce avoidable work. They also demonstrate why mature infrastructure advances through careful maintenance as much as through new protocol features.
The next evidence must come from use. Useful follow-up measurements would include upgrade adoption, recurrence of snapshot mismatches, inbound connection attempts rejected before handshake work and any index-rebuild failures after the reset correction. Until such data is available, the strongest conclusion is bounded: Erigon shipped concrete fixes for documented implementation paths, while their fleet-wide effect and residual risks remain to be measured.