week 3: Experience from Further Phase One Exploration and Mentor Handshake
- I switched my attention from Leanstart to Hive.
- Actual trajectory was like: Leanstart → Aglean → Hive.
- I got immersed in the Ream team workflow: we meet every Tuesday
- I played around with Hive, mapped out the architecture, shared findings with the maintainer and the ensuing exchange inspired what could be my EPF project.
Leanstart is an incredible project. Amazing that it is built by one person. But there is a misalignment between its near-term goal and mine. Right now, it needs to run the local devnet, push its limit and debug the errors. I want to type as much code as possible. Which brought my attention to Aglean (A consensus client written in Python which aims to also be framework for spinning up bespoke clients) and Hive (the Ethereum Integration test platform). Hive seems the most aligned with my ambition.
Hive is the integration test platform for Ethereum clients. As Ethereum plans and builds for a post-quantum future, an integration test project for PQ clients is a natural next step. PQ consensus clients, to be specific in this case.
I built and ran the lean workspace locally, worked through the unit tests, ran the default suites against ream_devnet4 and read two suites closely, namely the validation and lean-spec-tests-state-transition spec suite, to internalise the coding patterns. I watched the LeanSpec helper drive a post-genesis chain where finalisation tracked the head within a slot or two before interrupting the process to keep exploring the codebase. I also showed up to the weekly sync and shared my preliminary findings.
I noticed in the spec test-driver suites: each fixture runs against every client independently and is checked only against the fields the fixture pins; the clients are never compared to each other. Initially, I intended for differential testing to be the beginning of a series of tasks meant to strengthen the test harness, which will merge into the longer-term project plan for the cohort. I shared my findings with the maintainer, who is also the mentor for the project - Derek. After a series of exchanges with Derek, I realised that while differential testing might be great for exploratory reasons, there are other contributions which will provide immediate benefit to the project. One such approach is to document the correct response per the spec, then tighten the test assertions in the LeanSpec tests to ensure it.
Based on that info, I audited the devnet-4 state-transition test fixtures and found that, of the 45 fixtures, all pin post.slot, but only 5 pin latestBlockHeaderStateRoot. Fixtures also pin justifiedSlots that the driver response contract does not carry, so those checks are silently passed.
I wish to extend the audit to the fork-choice and verify-signatures groups, and draft my proposal around (1) tightening fixture pinning in the leanSpec generator and (2) widening the driver contract and hive assertions to enforce what’s pinned
Bis später — and more to come.