A concise foundation for reasoning about fallible test oracles.
Team capability · practical workshop
Build a differential-testing capability your team can keep running
A practical workshop and focused advisory package built around your system, current harnesses, and the decisions your testing must support.
When this is useful
- The team understands fuzzing but needs a stronger model for oracles, witnesses, and correlated blind spots.
- A prototype harness exists but coverage, corpus design, minimization, or triage is not yet operationally useful.
- Maintainers need a shared method for translating disagreements into reproducible reports and regression tests.
- A new testing initiative needs a bounded roadmap rather than an open-ended tooling project.
How the work proceeds
- 01
Pre-workshop intake
Review the system boundary, existing tests, representative artifacts, team goals, and anything that must remain out of scope.
- 02
Tailor practical exercises
Build examples around the team’s languages, implementations, failure modes, and available test oracles.
- 03
Run the working session
Cover threat modeling, witness independence, harness architecture, coverage, minimization, triage, and honest negative-result reporting.
- 04
Turn learning into a roadmap
Close with concrete next experiments, ownership, success criteria, and focused office hours for the first implementation steps.
Public evidence
Start with work you can inspect
Why coverage is not enough when the mechanism judging correctness is weak.
Public presentations on fuzzing, compilers, clients, and vulnerability research.
Next step
Describe the decision, not secrets
A short, non-confidential note about the system, milestone, desired evidence, timing, and possible Ethereum Foundation conflicts is enough to begin. Do not email vulnerability details, source code, credentials, or secrets.
Independent engagements are limited, subject to conflict review, and represent my own views and work. They are not offered, endorsed, or reviewed by the Ethereum Foundation.