Technologie & IA
Ethereum: a week of work begins on peer-to-peer networking checked with Lean
Machine-Checked Devcon Week starts November 2 around leanp2p. The project targets networking components with checked proofs while distinguishing its reference prototype from an implementation still being built.

Networking work still under construction
Invisible Garden lists Machine-Checked Devcon Week online for November 2–7, 2026. Work centers on leanp2p, a Lean 4 project building communication components aimed particularly at Ethereum consensus. This opening is a development event, not the release of a new Ethereum network version.
The repository still describes its main implementation as bootstrapping. It says the package tree, import checks, and testing infrastructure are in place, while code is to arrive incrementally. A separate branch holds a reference prototype. That organization distinguishes an already working experiment from the final library being rewritten. Architectural goals should therefore not be presented as features fully delivered to users.
Specific properties rather than absolute security
The design separates a protocol’s logical core from operations performed with the system. The core receives a state and an event, then produces a new state and expected actions. Network reads, the clock, and random values are supplied as explicit inputs. That makes scenarios easier to replay: a test can use the same events without relying on an external connection or an instant that cannot be reproduced precisely.
The target properties are concrete. The document names a receive window that never becomes negative, compliance with stream-numbering rules, and no reuse of a retired identifier. Proofs address these mechanisms and their models. They do not mean that an entire program, its dependencies, and its host system become invulnerable. The purpose is to make particular guarantees examinable and checkable within a more precise scope than a general claim of robustness.
Proofs complement interoperability testing
The architecture calls for complementary checks: theorems about pure functions, reference data from other implementations, tests producing varied inputs, and replay of recorded network exchanges. Comparisons with go-libp2p are intended to check that another software stack still understands the messages produced. The project also plans tests involving silent peers or slow readers. A mathematical property and compatible communication answer different questions; the verification program retains both.
The first announced target is Ethereum’s consensus layer, with TCP communications, Noise, and yamux multiplexing. The architecture also prioritizes request-response exchanges and gossipsub message distribution. Other functions remain deferred, limiting the scope of the planned first version. The week’s work is therefore about producing checkable components and integrating them progressively. The workshop’s opening proves neither completion of the stack nor adoption by Ethereum clients.
