docs: specify limb range assumptions for KZG point evaluation precompile - #1863
Merged
Merged
Conversation
Signed-off-by: Ivo Kubjas <ivo.kubjas@consensys.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Documents an input precondition of the EIP-4844 point evaluation gadgets in
std/evmprecompiles(KzgPointEvaluation,KzgPointEvaluation16,KzgPointEvaluationFailure,KzgPointEvaluationFailure16).Context. The gadgets take
versionedHash,commitmentCompressedandproofCompressedas native limbs of 16 bytes (128-bit variant) or 2 bytes(16-bit variant). Each limb is decomposed with
conversion.NativeToBytesandonly the low
bytesPerLimbbytes are used. The discarded high bytes are notconstrained to be zero, so a limb
v + k·2^(8·bytesPerLimb)is treatedthe same as
v. If the limbs are not range checked, multiple public limbvalues 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 thelimb range assumption and what happens when it does not hold.
KzgPointEvaluationFailure/KzgPointEvaluationFailure16: point to theabove for the range assumption, alongside the existing pointer for the data
encoding.
Scope notes:
expectedBlobSizeandexpectedBlsModulusare compared for equality withconstants and are not affected.
evaluationPointandclaimedValueare emulated elements and are notaffected.
Type of change
How has this been tested?
go vet ./std/evmprecompilesandgofmtare clean.How has this been benchmarked?
N/A — no circuit changes.
Checklist:
golangci-lintdoes 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.KzgPointEvaluationandKzgPointEvaluation16now document that callers must range-check every limb ofversionedHash,commitmentCompressed, andproofCompressed(128-bit vs 16-bit per variant). The gadgets only take the low bytes from each limb viaNativeToBytesand do not enforce that high bits are zero, so unconstrained limbs do not uniquely bind the precompile input.KzgPointEvaluationFailureandKzgPointEvaluationFailure16doc 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.