Skip to content

L2PS ZK — propagate range check from batch_10 to batch_5 #923

@linear

Description

@linear

What

The L2PS batch-5 ZK circuit's only balance guard is a dead constraint — check <== sender_after * sender_after — which binds nothing. Because sender_after === sender_before - amount is BN254 field subtraction, an overdraw wraps sender_after to a value about the size of the curve order and the proof still accepts.

The same circuit at batch-10 already has the proper guard — Num2Bits(64) on sender_after — with an explicit "SECURITY FIX — range check instead of squaring" comment in the source. The fix was never propagated back to batch-5.

Why this matters

If anything ever trusts a batch-5 proof on its own (light clients, cross-node aggregation, future bridges), a crafted overdraw transaction passes verification. The direct executor path re-validates balances against L1 state, so defence-in-depth on the happy path, but this is a genuine soundness hole the moment trust assumptions widen.

Fix

Copy the range check from batch-10 into batch-5, plus the matching range checks on amount and receiver_after on both circuits.

Blocker

Regenerating the proving and verifying keys requires a ZK ceremony. The code change is fast; the cryptographic key regeneration needs team coordination. Track the ceremony as a separate prerequisite for merge.

Source

PATH-OS L2PS hardening report. Their patch + 8-vector field-arithmetic test harness is ready to submit but was not compile-verified against our circom/ptau setup.

Status

Todo.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    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