Skip to content

Differential fuzzing · oracle design

Differential testing for systems with no single trusted oracle

A focused diagnostic for teams that need to turn disagreement between independent implementations into minimized, reproducible evidence.

Start a structured enquiryReview public evidence

When this is useful

  • Independent implementations must agree, but no single implementation is trustworthy enough to serve as ground truth.
  • A protocol, standard, or hard-fork change creates new behavior that must be compared before release.
  • An existing fuzzer reaches code but its oracle, corpus, or triage process produces weak signal.
  • A suspected divergence needs to be reproduced, minimized, and translated into an actionable upstream report.

How the work proceeds

  1. 01

    Model the contract

    Identify the shared semantic boundary, the independent witnesses, and the disagreements that would matter operationally.

  2. 02

    Design the harness and oracles

    Map inputs, normalization, comparison points, coverage, and failure modes without appointing one implementation as infallible.

  3. 03

    Run and triage a focused campaign

    Exercise the highest-value paths, minimize divergences, and separate implementation defects from harness or specification ambiguity.

  4. 04

    Hand off reproducible evidence

    Deliver prioritized cases, root-cause direction, regression-test recommendations, and a roadmap for the next campaign.

Public evidence

Start with work you can inspect

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.

Start a structured enquiryPGP key

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.