Skip to content

docs: specify limb range assumptions for KZG point evaluation precompile - #1863

Merged
yelhousni merged 1 commit into
masterfrom
fix/kzg-limb-range
Oct 5, 2026
Merged

yelhousni merged 1 commit into
masterfrom
fix/kzg-limb-range

Conversation

@ivokub

@ivokub ivokub commented Oct 2, 2026 •

Copy link
Copy Markdown
Contributor

Description

Documents an input precondition of the EIP-4844 point evaluation gadgets in
std/evmprecompiles (KzgPointEvaluation, KzgPointEvaluation16,
KzgPointEvaluationFailure, KzgPointEvaluationFailure16).

Context. The gadgets take versionedHash, commitmentCompressed and
proofCompressed as native limbs of 16 bytes (128-bit variant) or 2 bytes
(16-bit variant). Each limb is decomposed with conversion.NativeToBytes and
only the low bytesPerLimb bytes are used. The discarded high bytes are not
constrained to be zero, so a limb v + k·2^(8·bytesPerLimb) is treated
the same as v. If the limbs are not range checked, multiple public limb
values map to the same precompile input.

Why documentation instead of an in-circuit check. These gadgets are meant
to be called from the Linea arithmetization, where the input limbs are already
range checked. Asserting the range again would add constraints for a check
already done by the caller. Instead, the method documentation now states
explicitly that the caller must range check every limb to 128 bits
(respectively 16 bits), and that the method does not check this.

Changes:

  • KzgPointEvaluation / KzgPointEvaluation16: add a paragraph describing the
    limb range assumption and what happens when it does not hold.
  • KzgPointEvaluationFailure / KzgPointEvaluationFailure16: point to the
    above for the range assumption, alongside the existing pointer for the data
    encoding.

Scope notes:

  • expectedBlobSize and expectedBlsModulus are compared for equality with
    constants and are not affected.
  • evaluationPoint and claimedValue are emulated elements and are not
    affected.

Type of change

  • This change requires a documentation update

How has this been tested?

  • Documentation-only change; go vet ./std/evmprecompiles and gofmt are clean.

How has this been benchmarked?

N/A — no circuit changes.

Checklist:

  • I have performed a self-review of my code
  • I have made corresponding changes to the documentation
  • I did not modify files generated from templates
  • golangci-lint does not output errors locally

🤖 Generated with Claude Code


Note

Low Risk
Comments-only change with no logic or constraint changes; it clarifies an existing caller obligation for correct circuit soundness.

Overview
Documentation-only update for EIP-4844 KZG point-evaluation gadgets in std/evmprecompiles.

KzgPointEvaluation and KzgPointEvaluation16 now document that callers must range-check every limb of versionedHash, commitmentCompressed, and proofCompressed (128-bit vs 16-bit per variant). The gadgets only take the low bytes from each limb via NativeToBytes and do not enforce that high bits are zero, so unconstrained limbs do not uniquely bind the precompile input.

KzgPointEvaluationFailure and KzgPointEvaluationFailure16 doc comments now point readers to those same encoding and range assumptions. No circuit or runtime behavior changes.

Reviewed by Cursor Bugbot for commit 0a87770. Bugbot is set up for automated code reviews on this repo. Configure here.

Signed-off-by: Ivo Kubjas <ivo.kubjas@consensys.com>
@ivokub
ivokub requested a review from a team as a code owner October 2, 2026 23:34
@ivokub
ivokub requested a review from yelhousni October 2, 2026 23:34
@ivokub ivokub self-assigned this Oct 2, 2026

@yelhousni yelhousni left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

accurate and complete

@yelhousni
yelhousni merged commit d0ca295 into master Oct 5, 2026
18 of 19 checks passed
@yelhousni
yelhousni deleted the fix/kzg-limb-range branch October 5, 2026 15:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants