fast finality mentioned
One step closer to 4-8x faster Ethereum finality!
It took some time and lots of tokens, but we now have a formally verified proposal for a decoupled consensus protocol in I* (a future Ethereum upgrade)! Not yet a full spec (up next), but it includes all the key consensus-relevant details to become one.
Since Ethereum aspires to be live without most of the stake online, the protocol involves many more components than a normal BFT protocol, and its correctness involves much more than standard safety and liveness. Those nuanced properties are now verified!
What's more, I came away convinced that all protocol design will involve AI-assisted Formal Verification in the future, both for correctness and iteration speed.
The work wasn't limited to just:
Design the protocol -> Formally verify it
Instead, the loop became more like:
Design -> Formal Model -> Find exactly what breaks and why -> Redesign it.
For a fairly complicated protocol like this one, I think having the Lean model be part of the design loop played a big role in accelerating the process.
A future with agents paired with formal models is a superpower for Ethereum development, because they can then use those models to find exactly where an argument breaks down, formalize counterexamples, test proposed fixes, iterate on the protocol.
Many details that would slip under the radar when asking agents (and indeed, humans) can now be specified exactly and checked by the Lean kernel. This then forces agents to be more precise and lets them make verifiable progress on their own. It's been incredible to see this play out, seeing agents find gaps and propose protocol changes to fix them.
In other words, autoresearch can speed up protocol design, formal verification is here to stay, and Ethereum Finality will get faster.
1
82
Ben Edgington retweeted
Digitization and AI have erased the costs that once protected our privacy. A new generation of cryptography is bringing them back.
Peer-to-Peer's first guest post. From @GoBankYourself p2p.coincenter.org/p/enginee…
2
6
28
40,829
fast finality mentioned
(in the EthResearch post)
New post on Eth Research!
Snappy with a memory: ~40% less gossip traffic
By:
- Nashatyrev
🔗 ethresear.ch/t/26078
Highlights:
- Compressing the entire gossip stream with shared context (instead of per-message Snappy) significantly reduces inbound bytes: ~73% of today’s bytes for a default node and ~63% for an all-subnets node using LZ77-in-Snappy-format with a 64 KiB history.
- Most of the gain comes from cross-message redundancy: the repeated topic string and repeated AttestationData across a slot effectively become short back-references, leaving an attestation largely as signature + indices (~117 bytes).
- A 64 KiB-history, Snappy-format LZ77 stream compressor gets big wins on consensus gossip: attestations compress to ~42% and aggregates to ~63% of current wire size in both default and all-subnets scenarios.
- The approach is practical to integrate: it can be added as an optional negotiated protocol (e.g., /snappy-stream/meshsub/1.2.0) that decompresses back into the existing gossipsub RPC stream with today’s ssz_snappy payloads—no changes to message IDs, validation, or the rest of the gossip stack required.
- Performance and safety look acceptable: decoding is essentially as fast as current Snappy plus a history buffer (same decompression-bomb bound); live tests showed large reductions on attestation-heavy streams (~43–44% wire bytes in a hub-and-spoke setup), while CPU and memory costs are predictable (64 KiB history per peer direction plus tables; compression is costlier than decompression but still a few percent of a core across several peers in rough estimates).
ELI5:
Normally, each gossip message gets squeezed (compressed) by itself, like packing each toy into its own small box. This research asks: what if we pack a whole stream of messages together, so we can reuse patterns we’ve already seen? Because many gossip messages repeat the same pieces (like the same topic name and the same attestation details), keeping a short “memory” of the recent past lets the compressor say “same as before” instead of sending the full data again. That can cut a lot of network traffic, especially for nodes that listen to many attestation subnets.
33
1,937
Ben Edgington retweeted
New post on Eth Research!
Etheorem update: the complete executable consensus specs written in Lean 4
By:
- leolara
🔗 ethresear.ch/t/26063
Highlights:
- The Lean 4 consensus specs for three forks (Fulu, Gloas, Heze) now pass upstream conformance vectors for state transition, fork choice, and modeled SSZ containers, for both mainnet and minimal presets (pinned to consensus-spec-tests v1.7.0-alpha.11).
- Etheorem is structured as a stack: cryptographic/hazmat primitives (LeanSha256/LeanHazmat) → formally-verified SSZ library (SizzLean) → spec authoring framework (EthCLLib) → per-fork specs and proofs (EthCLSpecs).
- EthCLLib provides an inheritance system across forks (inherit/override) with late binding, so inherited functions re-elaborate in the child fork and automatically pick up the child’s constants/types/overrides—reducing duplication while keeping forks explicit and typechecked.
- Spec code is written once but instantiated in two modes: a fast test-runner configuration (FFI SHA-256, blst BLS, caches, hashmaps) and a pure proof configuration (kernel-reducible SHA-256, symbolic BLS, simpler data structures), enabling both conformance testing and proof-friendly reasoning from the same source.
- Formal verification progress is early but concrete: 8 spec functions are fully characterized by theorems (with more appearing in statements), proofs are kernel-checked with an auditable axiom footprint (only standard Lean axioms), and the project tracks proof coverage via a public proof ledger inviting contributions.
ELI5:
This post is about rewriting Ethereum’s consensus “rulebook” in a math-proof-friendly programming language (Lean 4) so it can both (1) run like real code and (2) have machine-checked proofs about what it does. The project is built in layers: a verified SSZ serialization/hashing layer (SizzLean), a spec framework that makes it easy to define types/functions/constants and reuse code across forks (EthCLLib), and then the actual fork implementations and proofs (Fulu → Gloas → Heze). The Lean code is tested against the official consensus-spec test vectors (like unit tests for Ethereum clients), and some key functions already have formal theorems proving their behavior. The framework also separates a fast runtime configuration (with real crypto via FFI) from a pure configuration suitable for proofs (with kernel-reducible hashing and symbolic crypto assumptions), keeping the proof trust base small.
2
3
30
1,407
Ben Edgington retweeted
Security researchers, get ready! The Glamsterdam upgrade is approaching. The Ethereum Foundation’s bug bounty program will begin accepting reports for Glamsterdam bugs once the Sepolia upgrade blog post is published. And take note of the reward multipliers!
ethereum.org/bug-bounty/#gla…
4
42
176
9,766
Ben Edgington retweeted
Articles are anti-cypherpunk. You cannot read articles through alt UIs or without being logged in.
So you should not write articles (or if you do, simultaneously make the post available in another format)
24
12
323
48,976
Ben Edgington retweeted
Teku v26.9.0 is now available!
This is a recommended update.
Please check the release notes for breaking changes.
Full details and downloads: github.com/Consensys-Incorpo…
4
11
1,007
Ben Edgington retweeted
shoutout to forkcast.org/
it's a very niche tool (ethereum hf viz infra) but it really helps navigate what can often times be a zoo
2
12
46
6,082
Ben Edgington retweeted
I just published a new paper exploring the operational, financial, and business benefits of permissionless blockchains as compared to permissioned networks for activities such as payments and capital markets.
It lays out how permissionless systems like Bitcoin and Ethereum offer desirable properties such as resilience, diminished counterparty risk, and guaranteed settlement. These benefits are endogenous to the system: what regulators and users see is what they get.
It then describes the mechanical reasons why the reintroduction of a gatekeeper in permissioned networks forfeits these benefits. Such networks can never be as reliable and are more vulnerable to cyberattack, particularly in the age of AI. Their guarantees are exogenous and live inside off-platform agreements.
My paper argues permissioned networks are not blockchains and the assets they hold should not be considered tokens. Their consensus and cryptography are mostly performative.
Lastly, my paper describes an oft-missed business benefit of permissionless systems: the inability of incumbents to take them over and exercise monopoly power, in the way they historically have in TradFi.
Permissioned networks are destined for the same fate, which is why they should be avoided by smaller entities (like community banks) and startups.
My argument relies on the decades-old literature in distributed consensus, current statistics on network reliability, and the first principles of TradFi design for clearing and settlement.
I wrote it because I think it’s important for lawmakers and regulators to start distinguishing between the two designs. Thinking the two types of platforms are similar opens the door to dangerous regulatory arbitrage.
Now is the time to understand the difference from a technical, financial, and practical point of view.
So take a look and let me know what you think ⬇️
16
33
145
20,892
Another terrific article from @coincenter Good to be reminded why we crypto.
Peer-to-Peer: “It equates to a civil death." – What happens when America cancels you? p2p.coincenter.org/p/it-equa…
2
11
2,774
Ben Edgington retweeted
The EF Protocol teams are hosting a Reddit AMA on September 16.
This is your chance to ask EF Protocol researchers and devs directly.
Submit your questions about post-quantum Ethereum, L1-zkEVM, formal verification, the future of state, finality, privacy, and more now!
🔗↓
37
35
145
107,946
Faster finality is coming!
A very quick proof of concept, but on a network that's a decent fraction of Mainnet size. First step, a modest 4x improvement in time to finality - the main thing was to benchmark decoupled consensus.
Looks ok to me 😃
Nice work @yannvon and all!
First Decoupled Consensus networking benchmarks were just deployed 🔥🎢
Shoutout to @sukunrt and @_pk910_ for doing all the work!
And thanks to @ethPandaOps and @parithosh_j for letting us tag onto their huge 1000 node Glamsterdam testbed
2
15
120
9,623
Ben Edgington retweeted
First Decoupled Consensus networking benchmarks were just deployed 🔥🎢
Shoutout to @sukunrt and @_pk910_ for doing all the work!
And thanks to @ethPandaOps and @parithosh_j for letting us tag onto their huge 1000 node Glamsterdam testbed
15
82
17,751
Ben Edgington retweeted
Let's ship faster blocks (perhaps not what you think)
potuz.net/posts/hegota-faste…
4
10
42
3,344
Ben Edgington retweeted
From one meeting to ACDE, ACDC & ACDT, Ethereum’s All Core Devs coordination has evolved organically over the years.
In her latest piece, @PoojaRanjan19 looks back at how these roles evolved - from early ACD & Hard Fork Coordination to ECH, Protocol Support & today’s distributed structure.
Follow the evolution of ACD coordination 👇
#Ethereum #ACD #ProtocolGovernance #CoreDevs #EthereumCommunity
1
9
14
5,476