From the perspective of the community observing the kickoff of the Hegota upgrade EIP scoping, it may seem as though everything is proceeding normally. However, the client funding crisis I wrote about in June has only deepened.
On the current path, it's likely that the EL/CL client landscape will look very different at the new year. To be clear: not all change is bad. Turnover is healthy and necessary in any context.
The challenge is in the magnitude produced by overlapping occurrences. Complex techno-political systems like Ethereum which aim to provide certain robust guarantees depend on continuity of deep institutional knowledge and client diversity for network stability. These characteristics are both best maintained via consistent neutral funding. Feature funding, intermittent injections, or abrupt shifts in the political economy without mitigations or succession plans are risky. These can disrupt fork cadence, distract from protocol workstreams, and damage morale. "100% uptime" is a stat that is hard won, far downstream of the incredible behind-the-scenes efforts by core devs. It can only be lost once, and I'm not confident we are doing enough to retain it as the network is still undergoing a significant evolution for the foreseeable future.
The ecosystem often responds to my concerns with "the EF/ @BitMNR /large patron should take care of it". Setting aside the free-rider problem: if I were confident any entity had a forthcoming solution, then I wouldn't keep bringing this up. Either they feel like they have done enough, are constrained, or something else. I cannot speak for them on their priorities.
The trouble with publicly communicating in advance about a private crisis is that I cannot point to concrete examples until clients choose to disclose. Until then you have to deal with my posts =)
7
8
63
17,502
Besu and geth are the only 2 ELs that deserve continued sponsorship. The others have just been fleecing yall.
Lodestar and lighthouse on the CL front.
It’s what the community uses and I ran bench tests on them to compare them. Can share, feel free yo comment and tag me
I think trimming the el/cl landscape is the right move. I remember trying to impl ssz encoding and discovering the specs are poorly written and all the CL clients impl it differently and can’t talk to each other lol.
Better to focus and improve quality
4
8
436
The spec is quite clear???? Which spec? There’s 5 different variants. A vlog post from some guy was the clearest crystalization of the thing. There were multiple audit companies like asymmetric that have demonstrated failures in the impl consistency between these clients
I dunno about you but I have like a decade plus of experience in tradition SE. you would never see a spec so poorly written and under specified at IBM or meta or any top tech company or in open standards.
Ssz doesn’t even have a shared test suite
Tell me the spec is quite clear after you impl it and test consistency across clients. I did this at bera.
Spec is clear as mud ime
1
35
The spec is here: github.com/ethereum/ssz-spec…. It used to live in consensus-specs but recently got moved out.
There ARE shared tests, I don't know why you are lying about this. See ssz_static tests in consensus-specs and ssz_generic tests which got moved to the ssz-specs repo.
2
3
35
I'm aware there have been minor SSZ divergences between impls, but it has never been anything serious or that would actually impact the network's operation. To suggest that big corps like IBM and Meta who write trash PHP and Java are somehow outdoing us here is stupid lol
2
2
61
@leonardoalt has also been working on a formal spec for SSZ, establishing properties like roundtrip correctness which we expected to hold on the informal text spec (and they do hold!)
Most SSZ libraries are tested against the spec. I built one where the core properties are formally proved, in Lean 4.
It also passes the full upstream test corpus. SSZ is how Ethereum serializes and Merkleizes its data — if hash_tree_root or deserialize is wrong, you get the kind of bug that can split the chain. For this reason I wanted something that is not only tested against the spec, but also proved.
Formal verification. The library is called SizzLean. I proved three theorems: roundtrip (decode after encode returns the same value), non-malleability (two different values cannot produce the same encoding), and a size bound. They hold for the fixed-size SSZ types: the integers, bool, fixed vectors and lists, and containers built from those. I have not proved them yet for bitvector, bitlist, and variable-size containers. So this is a base, not a finished proof.
Trust boundary. The only thing I assume without proof is the C SHA-256 function, declared as three named Lean axioms. You can list the full trust footprint with one grep, or with #print axioms on any theorem. Nothing else is taken on trust.
Two backends. The same spec runs on a fast cached backend, used for execution and for running the test vectors, and on a pure backend, used for the proofs. I put the hash function behind a typeclass, so SHA-256 can be replaced by Poseidon2 or a post-quantum hash without changing the containers, the proofs, or the cache.
Conformance. On top of the proofs, it runs the official ethereum/consensus-spec-tests on both presets:
ssz_generic: 2188 / 2188
ssz_static (mainnet): 1585 / 1585
ssz_static (minimal): 38991 / 38991
This covers every fork from Phase 0 to Gloas, including the new ePBS containers.
I also commented the code to be read. If you want to learn how SSZ works, or how to do this kind of work in Lean 4, you can follow it from top to bottom.
The verification was done with heavy help from an AI coding agent. With Lean this does not change the result: the kernel checks the proof, independently of who wrote it.
I work on specs and test vectors at the Ethereum Foundation, on the STEEL team. This is a personal project. The next step is to widen the proofs toward the remaining types.
Repo and full details: github.com/etheorem/etheorem…
3
3
120
It is @leolarav but I know that @leonardoalt also have done or is doing some FV. I take the confusion as a compliment.
If you need an really executable and usable Lean4 SSZ look into us, it is free software and we are very collaborative. Built by a humble volunteer team of already 5 people. (like @IvanAnishchuk)
We have not completed the formal verification of our implementation (although I would say it is 90%), because in @invisiblgarden philosophy we are using it as a learning tool. Ethereum Protocol Fellows and IG fellows are adding them.
However, it is very fast, we implemented "toggleable caching" for the merkle tree intermediate hashes, like remarketable, using implied type classes and meta programming.
The result, disabling the cache makes the code simple and easy to create proofs for it. Enabling the cache makes it very fast.
Soon we will publish benchmarks.
Thanks to metaprograming, it is trivial to use it, just derive SSZRepr in your struct. Zero builerplate: you get de/ser, Markle Root (with C or Lean hash), and cache that you can disable for simple proofs.
Also, it works with a C implementation of sha256, or with a Lean implementation.
github.com/etheorem/etheorem…
Sep 11, 2026 · 11:57 AM UTC
1
1
4
194