zkdefi · notes

#ed25519

Forty-four certificates, and the war we declared on our own green light

Each of our four verified ed25519 libraries went from 16 proven statements to 44. But the real story of the past month is uglier and more useful — what it took to make the script that PRINTS "all green" as trustworthy as the proofs behind it.

We signed the same thing twice to see if the ink matched

Ed25519 signatures are deterministic — same key, same message, same signature, forever. We used that to audit ourselves, re-signing an already-published record and comparing byte for byte. The bytes matched. The exercise still caught a real bug.

An append-only witness for "the proof still checks" — the Lean Transparency Log

A verification proof is a claim about a specific commit. Claims rot — the repo moves, the axioms drift, "it verified once" becomes folklore. The Lean Transparency Log is an append-only, Merkle-anchored ledger of signed attestations that named proofs re-check with exactly their documented assumptions, plus the agent tooling that asks the only question a downstream consumer cares about.

The deferred half, done four times — point-level ed25519 verification lands on every fork

The four ed25519 verification pyramids each ended their first post with an honest asterisk — the signature apex was proven at the byte level, and lifting it to the point level was deferred. That deferral is now closed, on all four forks: decompress is extracted and proven, the modular square root is proven, compress is canonical, and the acceptance criterion now reads as a real curve-point equation.

From 1+1=2 to machine-checked curve arithmetic — the book

A LaTeX/TikZ book plus compiling exercise files - now in its second edition (14 chapters, 132 pages) - a curriculum that takes an undergraduate with zero formal-methods background to the point of reading, and extending, the real Lean 4 proofs in the ed25519/Pallas verification family.

Verifying Solana's ed25519 — same theorems, different codebase

The proof pyramid rebuilt against Solana's solana-ed25519 crate — its own Charon/Aeneas extraction, its own compiled certificates. Forks drift; theorems about the upstream prove nothing about the fork.

The signature check in your pocket — verifying Betrusted's ed25519

The fourth ed25519 target - the curve25519-dalek fork used by Betrusted/Precursor, the security-first open hardware device whose entire boot chain and update trust reduce to this code accepting the right signatures.

A proof pyramid over the real curve25519-dalek

Machine-checked correctness for the ed25519 implementation everyone actually ships — field, group law, scalar arithmetic, and the EdDSA acceptance criterion itself — proven in Lean 4 about the Aeneas-transpiled Rust, not about a flattering re-model.

Proofs about the code inside the prover — RISC Zero's dalek fork, verified

The third target of the ed25519 verification family - RISC Zero's curve25519-dalek fork (v4.1.3), the one that runs inside zkVM guests. A ZK proof attests that code ran; it does not attest that the code is correct. These certificates cover the half the SNARK can't.