Skip to content

DROP_DEAD_ROBUST_DISABLE still applies the second robust drop pass #10

Description

@welttowelt

Problem:
DROP_DEAD_ROBUST_DISABLE=1 does not disable all robust dead-op dropping on the promoted da51a48 source. It disables only the first robust pass; the second pass still runs because DROP_DEAD_ROBUST_SECOND is checked independently.

Evidence:
On a clean worktree at origin/main / da51a48, after building the benchmark binaries:

env DROP_DEAD_ROBUST_DISABLE=1 ./target/release/build_circuit

The output includes both lines:

DROP_DEAD_ROBUST: disabled by DROP_DEAD_ROBUST_DISABLE=1
DROP_DEAD_ROBUST_SECOND: removed 2638 ops (10220088 -> 10217450)

The control flow in src/point_add/mod.rs matches that behavior: lines around 1902-1944 gate only the first pass on DROP_DEAD_ROBUST_DISABLE, while the second pass at 1945-1980 only checks DROP_DEAD_ROBUST_SECOND.

Effect:
A solver trying to turn off robust dropping for provenance, nonce comparison, or source-order debugging still gets a mutated op stream. This can invalidate Fiat-Shamir replay comparisons because the second drop changes the op stream and therefore the test inputs.

Smallest useful fix:
Return ops immediately when DROP_DEAD_ROBUST_DISABLE=1, or apply the same disable guard to both robust passes. If separate control is desired, add a second explicit disable flag and keep DROP_DEAD_ROBUST_DISABLE as the global off switch.

Gate:
With DROP_DEAD_ROBUST_DISABLE=1, build_circuit should emit no DROP_DEAD_ROBUST_SECOND: removed ... line and the op count should match the pre-drop stream.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions