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: https://t.co/dN5LvowSud
@josepjoubuch@CPerezz19 I think that you are not in the correct security frame. If google/apple/hw manufacturers wants, 99.99999% EU population are going to be compromised in 1s. This does not change anything.
Next week, new Ethereum Engineering Meetup
A nice combo for RiscV state-of-the-art
Jordi Baylina, founder of @ziskvm
Edgar González, Chief of software at @Openchip_
RVSP at https://t.co/rm7pGQmffQ
With much help from my really good friend @claudeai, I am trying to reverse engineer away all the Bitcoin Script nonsense (sorry!) and understand @avihu28's quantum-safe signature scheme, cryptographically.
AFAICT, this is how the scheme works 👇
@francis_cgl Close, an idealistic private messaging system where parties can compose ZKRiscV proofs via micro-opcode query language. Including stuff like zkEmail or zkPassport, gov issued stuff, decentralized PoH graphs and MPC TLS-Notary. All PQ why not. A modern https://t.co/EVaugI1jEn.
🦀 Looking for new interesting problems to work on.
ex-Ethereum core dev.
ex-EF: zkEVM & Halo2 circuits.
20y in applied cryptography (PKI → BC -> zk → PQ).
Rust, ZK, Ethereum, Privacy. No rush.
CV: https://t.co/MT0b9iLr8U