Skip to content

Explore instance-commitment fixed-window precomputation tradeoffs #96

Description

@ValarDragon

Context

PR #80 adds a bounded unsigned eight-bit fixed-window table for batch-verifier
instance commitments. For each cached Lagrange-basis point, the table retains
its 255 nonzero multiples. A 255-bit scalar is then evaluated in 32 radix-256
windows with 248 doublings between windows.

The current constructor accumulates all projective multiples and
batch-normalizes them together. This minimizes inversions, but keeps both the
projective and affine buffers live during normalization. PR #80 bounds the
cache at 64 instance rows and uses the generic MSM above that limit.

For Orchard's ten-row instance shape, the current table retains 163,200 bytes
and needs approximately 408,000 bytes for the new projective and affine
construction buffers. At the 64-row limit, those figures are 1,044,480 and
2,611,200 bytes respectively.

Related: #80.

Follow-up experiments

1. Use multiple batch inversions to reduce peak construction memory

Construct and normalize the table in smaller chunks instead of retaining all
255 * row_count projective points until one global batch normalization.

  • Sweep sensible chunk sizes, such as 1, 2, 4, 8, and 16 bases.
  • Record the additional inversion cost against peak allocation and cold-build
    latency.
  • Preserve immutable affine chunks after construction so live commitment
    evaluation does not acquire locks.

2. Use Pasta GLV decomposition to reduce doubling depth

Decompose each scalar into two signed approximately 128-bit components and
evaluate against G and its endomorphism image.

  • Measure whether halving the scalar/window depth outweighs decomposition and
    endomorphism costs.
  • Compare deriving endomorphism images during construction with retaining them
    in the table.
  • Account explicitly for any increase in retained table size.

3. Cache 64-bit-shifted bases to reduce runtime doublings

Explore retaining selected shifted bases such as [2^64]G, [2^128]G, and
[2^192]G. Four 64-bit scalar limbs could then be evaluated against the
corresponding shifted bases with fewer sequential doublings.

  • Measure the table-size increase against the reduction from the current 248
    runtime doublings per commitment.
  • Compare full shifted tables with smaller derived or hybrid tables.
  • Evaluate this independently before combining it with GLV.

4. Fast-path zero public instance values

Avoid entering either the fixed-window or generic MSM machinery when an
instance column contains no public values. Its commitment is the fixed w
term, so the verifier can return that point directly instead of allocating
scalar representations, traversing 32 empty windows, and performing 248
identity doublings.

  • Avoid acquiring or initializing an empty fixed-window table.
  • Skip instance-commitment work entirely when the verifying key has no
    instance columns.
  • Keep the empty-column case distinct from columns containing scalar zeroes;
    this experiment is about zero public instance values, not data-dependent
    scalar filtering.
  • Benchmark B1 and B64 for both no-instance-column and empty-column circuit
    shapes, and verify that the cache remains uninitialized.

Measurement requirements

For every candidate, record:

  • cold construction latency;
  • peak construction allocation or RSS;
  • retained cache size;
  • one-off B1 verification;
  • warm B1 and B64 verification using the standard authenticated fixture
    corpus;
  • both Pasta curves and the existing fixed-window differential tests.

Keep PR #80's 64-row bound and generic-MSM fallback unless a candidate provides
an independently justified replacement. Prefer isolated experiments so that
the contribution from each precomputation strategy remains attributable.

These are verifier implementation optimizations only. They should not change
proof, transcript, parameter, verifying-key serialization, or public API
semantics.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestrustPull requests that update rust code

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions