Aeneas emits a *_Template.lean naming everything the extracted code needs
from outside itself — the extraction's own statement of its boundary.
extract.sh has always said, in prose, "after regenerating, diff the template
against the hand-written file". Prose is not a gate, and the diff cannot be
one: the two files legitimately differ in almost every line, holes and
Aeneas comments against real definitions and modeling policy.
MEASURING FIRST CHANGED WHAT THIS ITEM SHOULD BE. The TODO offered two
options — enforce the diff, or pin both files — and the answer turned out to
be neither. Both files were ALREADY byte-pinned by Phase 0b. And two further
things stand here: the generated Funs.lean imports the model and CALLS these
externals, so the Lean compiler enforces their TYPES wherever the extracted
code uses them; and the per-certificate exact cones catch any external that
becomes, or stops being, an assumption anything depends on.
What none of those three sees is the CLASSIFICATION: for each name the
extraction asks for, whether this repository answers with an ASSUMPTION or
with a PROOF. That is the tier-A/B claim the documents make in prose — the
curve calls and the three curve types resolve to proven definitions rather
than axioms, because gen/CurveField/Funs.lean opens `namespace
curve25519_dalek` and so defines the very names Aeneas asks for. Nothing
checked it. A regeneration that renamed one, or a model that quietly
answered one with an axiom instead, would have left the documents claiming a
proof where the repository had an assumption.
Phase 0d recomputes the classification with model-correspondence.py
(namespace-aware, so a definition inside a namespace counts under its full
name) and requires equality with the committed MODEL-CORRESPONDENCE.txt.
UNRESOLVED — the extraction asking for something nothing here provides — is
a hard failure.
dalek 43 MODEL 8 PROVEN 3 EXTRA
anza 38 MODEL 0 PROVEN 4 EXTRA (no CurveSig crate)
risc0 36 MODEL 8 PROVEN 4 EXTRA
betrusted 35 MODEL 8 PROVEN 4 EXTRA
selftest-correspondence.sh, five cases, negative-tested by disabling the
comparison. The case that matters is 2: a PROVEN external answered by an
axiom instead. No name changes anywhere, every byte pin still matches, and
it compiles, because the signature is unchanged — before Phase 0d nothing in
the button could tell.
Trap recorded for whoever extends it: case 3 first deleted the PROVEN rows,
which was VACUOUS on anza, since anza has none — it removed nothing, the
table still matched, and the case passed while testing nothing. It now
deletes the first row whatever its verdict AND asserts the file changed.
extract.sh now points at the gate instead of asking a human to look.
Certified by a full sweep: both buttons, all four forks, purged trees,
machine otherwise idle. 8/8 green.
(verify_accepts_iff_decompress, button-enforced)
Port of the dalek decompress chain to the risc0 fork (v4 gen):
- source patch 8b69091: decompress step_2 negate-then-conditional-assign
(the documented sqrt_ratio_i rewrite; sqrt_ratio_i itself was already
in the compatible shape); extract.sh: decompress un-opaqued,
re-extracted - the step_1/step_2 external axioms vanish from the
template, decompress is transparent.
- Proofs/DecompressSpec.lean: dalek port, instance rename
Shared0FieldElement51 -> SharedAFieldElement51.
- Proofs/FromBytesSpec.lean: PORT DELTA - this gen's from_bytes takes
RangeFrom subslices (bytes[k..]) into a local load8 CLOSURE with
literal indices instead of dalek's named load8_at: new
range_from_index_spec (over the step_simps-reduced slice index) +
closure_call_spec (same disjoint-OR loader math); window/telescope
arithmetic identical.
- Proofs/DecompressMain.lean: decompress_of_canonical (standard three)
+ verify_accepts_iff_decompress (corollary verbatim - this fork's
point-equation signature is byte-identical to dalek's):
accept <=> decompress(R) = [k]*(-A) + [s]*B (as points).
check.sh: 4-tier Phase 3b; full-lift cone exactly [3 standard +
Signature + sha512_hash3 + to_bytes + Error + Error.new]. Full button
green fresh.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The [3/4]+[4/4] steps that produced the shipped gen/CurveSig, verified
byte-exact by re-running them and diffing Types.lean/Funs.lean against
the installed model. Deltas from dalek's recipe for the sha2-0.10 stack:
`--opaque crate::verifying::sha512_hash3` (single-call oracle) instead of
the three stateful wrappers, `--opaque block_buffer --opaque crypto_common`,
`--exclude generic_array` (mixed recursion with typenum), and
`-- --no-default-features` (no-std error path, no boxed dyn-Error).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Replicates dalek's gen merge: extract.sh co-extracts the Scalar52 backend
and scalar::from_bytes_mod_order[_wide] into the CurveField model (with this
fork's sub::black_box opaqued, its identity model ported to the merged
FunsExternal), pins RUSTFLAGS --cfg curve25519_dalek_backend="serial" so
the SIMD dispatch arm compiles out (get_selected_backend becomes a real
definition), and upgrades unwrap_u8 to the documented Choice-model
definition. ScalarDenote repoints by one import line; both buttons green
over the merged gen (scalar chain + field/group/dsm chain, all certificates
axiom-clean).
Prepares the verify-glue integration (CurveSig) on this fork.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
extract.sh now opens crate::backend::serial::scalar_mul::vartime_double_base
(the other scalar_mul strategies stay opaque): non_adjacent_form (with its
loops), NafLookupTable5 (from/select), the curve-model helpers and
vartime_double_base::mul itself land in gen/CurveField - the same
namespace as the proven edwards operations, so the coming double-and-add
induction can consume EdDouble/EdAddProjNiels/EdConvert directly.
Zero sorries, zero external axioms (the pinned sources carry documented
compat refactors: single-assignment loop helpers, param-rooted while,
always-256-iterations, index-based LE load).
Full check.sh pressed fresh over the regenerated model: every existing
field and group-law certificate still green and axiom-clean - the scope
extension is purely additive.
