Ivan Anishchuk, EPF https://ivananishchuk.github.io/eth-protocol-fellowship/updates/ Ivan Anishchuk's Ethereum Protocol Fellowship cohort-seven dev updates and project notes. http://www.rssboard.org/rss-specification zensical-updates en Mon, 03 Aug 2026 00:00:00 +0000 EPF Week 6 - Ivan Anishchuk - the merkle-branch completeness proof goes upstream https://ivananishchuk.github.io/eth-protocol-fellowship/updates/2026-08-03-week-6/ Short version: Short version:

  • The merkle-branch completeness proof went upstream as #42, the first consensus-layer proof off the roadmap.
  • It's the bottom of a three-branch stack. Layer 2 (generalized index) goes up next, layer 3 (hash_tree_root agreement) is held behind a spec divergence I filed as #40.
  • Co-presented the proposal with Raj on 29 July. Video and slides linked below. The proposal itself is merged into the cohort repo.
  • Side quest: packaged jitsi-meet-desktop as an ebuild and presented on it. Guest mode only so far.

The proof went up

#42 is the result I've been promising since week 4: is_valid_merkle_branch accepts every honest opening of an openable tree, machine-checked. That's the check processDeposit runs against eth1Data.depositRoot, so the deposit path is covered directly. Eighteen files. Most of that is the tree and path vocabulary the statement quantifies over, not the theorem itself.

Fixed a divergence from the spec while I was in there. merkleBranchRoot now takes depth ≤ branch.size, so a short branch can't fold in Inhabited defaults where upstream's compute_merkle_branch_root raises IndexError. External signature unchanged, processDeposit needed no edit.

Trust footprint: propext, Classical.choice, Quot.sound, nothing else. The Sha256Spec corollaries add sha256Combine_eq_spec, the one named FFI-equals-spec bridge. No sorry anywhere.

The stack behind it

#42 is the bottom of three stacked branches, roadmap items A4, A9 and A5, against the roadmap in #35. Layer 2 models get_generalized_index and proves it names the position Node.ofShape actually puts a container field at, which reaches the data-column sidecar inclusion proof, FINALIZED_ROOT_GINDEX, EXECUTION_BLOCK_HASH_GINDEX and both sync-committee gindices. Layer 3 proves hash_tree_root equals the root of the cached Node tree.

The value is back-loaded. Layers 1 and 2 are stated over Node.merkleRoot, our own construction, not Ethereum's hash_tree_root, so neither says anything about spec behaviour until layer 3 bridges them.

Layer 3 is held, blocked on #40: our zero-hash table stops at 65 entries where the pyspec builds 100, and clamps out of range where the spec raises. That divergence is why layer 3's headline theorem carries a depth ≤ 64 side condition. Fixing the table removes the side condition and rewrites layer 3's central argument, so it has to land first.

Completeness only, throughout. The check accepts every honest opening, which rules out rejecting valid data, the failure mode that forks a light client off its peers. Binding, that a forged branch gets rejected, has no sound statement under a real 64-to-32 combine. It squeezes sixty-four bytes into thirty-two, so colliding branches exist by pigeonhole, and what's left is a hardness assumption rather than something you prove.

Proposal presented and merged

Raj and I co-presented the proposal on 29 July, in EPF7 Project Presentations 3 (our segment starts at 1:19:03), and here is the proposal deck.

The proposal is merged into the cohort repo as projects/etheorem-consensus-proofs-lean4.md.

Aside: jitsi-meet-desktop

Unrelated to the proofs. I packaged jitsi-meet-desktop as an ebuild in my overlay, net-im/jitsi-meet-desktop-2026.7.0, and gave the presentation above on it. Worked well, screen share included.

It joins OIDC-gated rooms as a guest, which is what got me through the call. Non-guest mode is another matter. It doesn't look like the desktop client supports authentication the way the Ethereum server does it, so that needs more investigation before it's usable as a properly logged-in client.

Next: get #42 through review, put layer 2 up behind it, and fix the zero-hash table so layer 3 can move.

Resources

]]> https://ivananishchuk.github.io/eth-protocol-fellowship/updates/2026-08-03-week-6/ Mon, 03 Aug 2026 00:00:00 +0000 EPF Week 5 - Ivan Anishchuk - a joint proposal with Raj and the verification roadmap upstream https://ivananishchuk.github.io/eth-protocol-fellowship/updates/2026-07-27-week-5/ Short version: Short version:

  • The verification roadmap went upstream as a PR (#35), twenty proof targets across four tiers.
  • Raj Gill (@irajgill) and I wrote a joint proposal, split by layer. He takes SSZ, I take the consensus layer above it.
  • Three of my PRs are sitting open upstream: the roadmap, the fork-choice throw-faithfulness sweep (#22), and the Heze fork layer (#6) still going through review.

The proposal took most of the week. Raj and I worked on it together and wrote it as one project with two lanes, split by layer. His lane is finishing the three central serialization theorems until they hold for every type the codec actually implements. Mine is everything above SSZ, the arithmetic and structural invariants, merkleization, the shuffle, fork choice, plus keeping conformance green as the forks move and the roadmap both lanes work from. Splitting by layer rather than by ticket keeps us in different packages.

Where the SSZ side stands: the mixed-field container arm is in review (#28, #29). It's the hardest one and the shape BeaconState itself takes, since the decoder has to recover field boundaries from the offset table the encoder wrote. One arm sits behind it, vector and list over variable-size elements, same offset machinery element-wise, scheduled for August. After that the three theorems cover everything the codec implements.

The roadmap PR is up. Twenty targets, four tiers, each pinned to a function and an acceptance criterion, with prior-art tags for what the Dafny and Runtime Verification work covered.

The other two open PRs are older business. #22 is the throw-faithfulness sweep from the week-3 review, converting the fork-choice helpers that can throw in the Python spec into Lean versions that can also fail instead of quietly returning something. #6 is the Heze fork layer, still in review, still the piece the FOCIL inclusion-list proof target sits on. Neither is dramatic, both need to land before the proof work above them means much.

The presentation deck for the proposal is built too.

Next: submit the proposal to the cohort repo, present it, and start on the overflow-safety and slot/epoch invariants while the container arms land underneath.

Resources

]]> https://ivananishchuk.github.io/eth-protocol-fellowship/updates/2026-07-27-week-5/ Mon, 27 Jul 2026 00:00:00 +0000 EPF Week 2 - Ivan Anishchuk - expanding etheorem with Heze/FOCIL and cross-client conformance harness experimentation https://ivananishchuk.github.io/eth-protocol-fellowship/updates/2026-07-03-week-2/ Week 2 I shifted off the Charon+Aeneas extraction experiments and onto etheorem's conformance layer, the Lean 4 spec-container models that get checked against the official test vectors. That work landed: Week 2 I shifted off the Charon+Aeneas extraction experiments and onto etheorem's conformance layer, the Lean 4 spec-container models that get checked against the official test vectors. That work landed:

  • Two PRs merged, the consensus-specs re-pin to v1.7.0-alpha.11 with the new EIP-8282 builder containers (#5) plus a small cross-distro build fix (#4). My first merged PRs there.
  • The big one is the Heze fork layer (FOCIL, EIP-7805), published as #6 and now up for review. ~2.2k lines across 36 files; the spec delta over Gloas at this pin is compact (the inclusion-list containers plus the FOCIL fork-choice machinery), so most of the work was the fork-choice layer and keeping everything conformance-green (6770 passed / 0 failed on minimal, 997 / 0 on mainnet). One catch: alpha.11 ships no vectors that actually drive FOCIL behavior, so I pinned the vectorless fork-choice code with build-enforced #guard examples worked out by hand.

The other half of the week was research. How do we use etheorem to verify actual clients, starting with moonglass? Two candidate shapes. Differential testing (fuzzing-flavored), where you run both implementations over the same inputs and diff the verdicts, cheap and wide. Or proving by extraction, pulling the Rust through Charon/Aeneas into Lean and proving it equivalent to etheorem's definitions. Slower, way more painful, but you end up with an actual theorem. I settled on a 50/50 balance, the differential harness for breadth plus extraction proofs for the small pure kernels where a real theorem is within reach. (The extraction side already has an anchor from the week-1 experiments: the machine-checked proof that the extracted Rust u64 SSZ encoder is byte-equal to etheorem's now checks against SizzLean's actual definition instead of a pinned copy.)

In practice that meant fixing a few minor toolchain issues (the usual yaks) and getting an initial harness/runner implementation going. It drives etheorem and moonglass side by side over the official vectors and compares the two verdict streams, a real cross-implementation diff rather than each checked against the fixtures alone. On everything both currently cover (the gloas operations family) it finds zero divergences, which is the boring kind of result you actually want. The coverage edge is the runner's scope, not the harness's. The code is public now, consensus-diff (the harness) and moonglass-runner (the moonglass-side adapter). They're deliberately two repos, for a stupid copywrongs reason (the runner links moonglass's AGPL core so it has to be AGPL itself; the harness only talks to backends over a subprocess wire protocol, carries no moonglass code, and stays tri-licensed CC0/Apache/WTFPL). And the runner might hopefully get upstreamed into moonglass itself eventually anyway.

Next: handle whatever review lands on #6, then widen the moonglass runner past operations so the differential covers more of the suite. After that probably mutation-fuzzing inputs with etheorem as the oracle. I still need to shape what I'm doing into a more specific and presentable project proposal, too. To be continued.

Resources

]]> https://ivananishchuk.github.io/eth-protocol-fellowship/updates/2026-07-03-week-2/ Fri, 03 Jul 2026 00:00:00 +0000 EPF Week 1 - Ivan Anishchuk - Rust to Lean, first proofs https://ivananishchuk.github.io/eth-protocol-fellowship/updates/2026-06-22-week-1/ Week 1, still scoping. I leaned harder into the formal-verification side, and most of the time went into one question: can you take Rust code, generate Lean 4 out of it automatically, and then prove the generated Lean matches a reference model (or, where there isn't one, just holds the property I'm after)? None of this is worth submitting anywhere yet, it's all still exploration, but it's holding together so far. Week 1, still scoping. I leaned harder into the formal-verification side, and most of the time went into one question: can you take Rust code, generate Lean 4 out of it automatically, and then prove the generated Lean matches a reference model (or, where there isn't one, just holds the property I'm after)? None of this is worth submitting anywhere yet, it's all still exploration, but it's holding together so far.

The engine that does the Rust→Lean step is Charon+Aeneas. I got it set up with the stable Lean release (v4.29.1, after fighting some typical dependency hell a little) and spent the week playing with the stack, extracting Rust code and proving what came out.

On moonglass (experimental CL client) I worked up a handful of small slices. Cheapest first, and not even a proof: I fed moonglass's gloas test fixtures through etheorem's SSZ runner with no transpiler at all, just to see whether two independent implementations agree on the hashes, and they did, 5 out of 5 on what I tried. Then the extracted-and-proved slices, each one machine-checked and sorry-free (the Lean kernel actually checks them, no holes): the integer primitives, the u64 SSZ round-trip (Rust SSZ library encoder coming out byte-for-byte equal to etheorem's), the balance and slashing arithmetic, the attester-slashing latch, and LMD-GHOST head pick.

On leanVM (zkVM from the lean-Ethereum effort, its arithmetic running over a small prime field called KoalaBear) I was mostly exercising the tooling on something other than consensus. I got its arithmetic core to extract and proved it matches MeanVM (my partial, tool-generated model of leanVM), at least for add, subtract and multiply: those I grounded fully against the extracted low-level arithmetic, no field axiom assumed. The inverse I left on one clearly-labeled assumption, rather than pretend it comes for free.

What I learned... The low-level field arithmetic extracts transparently and proves with no trust assumptions at all, which is honestly great; the higher-level wiring (Rust traits) is where the extractor still kinda struggles. So the move is to prove at the level I can actually back up, instead of forcing the whole thing. The differential cross-check was the cheapest piece and maybe the highest-value, which surprised me a bit (no extraction needed, and it'd flag any divergence between the two).

Caveats/blockers. I hit two toolchain limitations on the full leanVM extraction that I'm holding as candidate/unconfirmed for now, could be real bugs, could be me holding it wrong tbh, I need to properly sit down and review before I know next steps. And a couple of the slices currently lean on a small faithful stand-in for a private upstream function, so those want a drift-check against source before I'd trust them long-term.

Next is grinding down that inverse assumption, chasing those two questions upstream, and probably checking in with the projects' devs for pointers. Exploration goes on, stay tuned.

Resources

]]> https://ivananishchuk.github.io/eth-protocol-fellowship/updates/2026-06-22-week-1/ Mon, 22 Jun 2026 00:00:00 +0000 EPF Week 0 - Ivan Anishchuk - Getting Started https://ivananishchuk.github.io/eth-protocol-fellowship/updates/2026-06-17-week-0/ I'm Ivan ([@IvanAnishchuk](https://github.com/IvanAnishchuk)), a backend engineer by trade, about fifteen years of it, mostly Python, mostly in web2 and some early AI before it was cool, the last few in applied cryptography and ZK. The one constant under all of it is math: I did discrete math and probability at university (although never graduated, I'm actually also currently catching up on academic things in parallel) and my first actual research was in abstract algebra (finite function algebras, k-valued logic, the sort of thing nobody asks you about at parties). That's probably most of why formal methods keep pulling me back. I came into cohort 7 drawn to the consensus layer but without a project picked, so Week 0 was mostly scoping. I'm Ivan (@IvanAnishchuk), a backend engineer by trade, about fifteen years of it, mostly Python, mostly in web2 and some early AI before it was cool, the last few in applied cryptography and ZK. The one constant under all of it is math: I did discrete math and probability at university (although never graduated, I'm actually also currently catching up on academic things in parallel) and my first actual research was in abstract algebra (finite function algebras, k-valued logic, the sort of thing nobody asks you about at parties). That's probably most of why formal methods keep pulling me back. I came into cohort 7 drawn to the consensus layer but without a project picked, so Week 0 was mostly scoping.

A bit of background

No core-client work yet, I'll be honest. The closest thing I've built is ETH Consensus Neotrace, which started as a consensus-spec study at Invisible Garden and turned into a tool that generates cross-client test vectors by tracing the spec (the upstream spec PR out of it got closed unmerged, so I file it under "study" rather than "contribution"). Before being accepted to EPF I mostly dabbled in applied crypto: NoZKash, privacy eCash on the EVM with no zk-SNARKs (just BLS blind signatures over the EIP-2537 precompiles), plus some zkML research, a little bit of decentralized AI development and a few smaller things in other ecosystems.

What I did this week

Got oriented and scoped. I read wide first, the study-group tracks (Lean/zkEVM, cryptography, protocol fundamentals) and the kickoff, then went through the cohort project board and open issues from client teams to see what's actually being asked for, beyond what I happen to find interesting.

Surveyed the formal-verification work, since that's the part I keep coming back to. I mapped what already exists on the consensus layer: ConsenSys's Dafny effort (archived now), pieces from Runtime Verification, the etheorem project in Lean 4, and the EF consensus team's model-checking work (arXiv:2501.07958). etheorem is the one I went deepest on. It formalizes SSZ, Ethereum's serialization and Merkleization layer, and already proves the core encoding properties for the simpler cases, with the harder ones still open. I also kept half an eye on the recent lean-Ethereum interop devnets, where serialization bugs keep turning up (leanSpec #327, zeam #942).

Got hands-on with etheorem. On top of an overall review of the repo, I got it building on its pinned toolchain (Lean v4.29.1, Lake) and ran the conformance suite for a clean baseline, then did a tool-assisted audit I drove myself: 24 findings awaiting triage, 4 high-severity across three root causes (subgroup checks in the BLS code, deserializer offset validation, and an out-of-bounds path in the Merkle cache), plus a fork that's implemented but not yet wired into conformance. Enough to feel the shape of the codebase, and what actually picking it up would involve. Yeah, I did some catching up on Lean4 too in the weeks leading to this.

Areas, tools, and what's next

What I'm drawn to, and happy to be pointed at: formal verification and the consensus layer most of all, but plain implementation and tooling too. I work mostly in Python (my strongest) and Rust, with the applied-crypto and ZK background sitting underneath. Over the next couple of weeks I'll keep surveying (open issues, the project ideas the teams have posted, the formal-methods efforts, and what proposing my own would actually take, etheorem being the one I've gone deepest on), then commit to one. It might end up a proof-heavy project, a hands-on implementation task, plain bug-fixing, or my own proposal; I'd rather make that call with the survey done than guess at it now. Either way: small and concrete to start. We'll see.

Resources

]]> https://ivananishchuk.github.io/eth-protocol-fellowship/updates/2026-06-17-week-0/ Wed, 17 Jun 2026 00:00:00 +0000