You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
S1 - SHA-256 relation: witness synthesis and sparse M/A construction
Implement the executable SHA-256 compression relation described in docs/sha256-f2z-note.
This issue owns:
Native SHA-256 witness synthesis.
The public binary map M_mix that derives virtual XOR values.
The public sparse integer matrix A_x that checks the SHA-256 word
equations.
The completed implementation must produce an exactly satisfied relation:
z = M_mix · f over F_2
M = [I; M_mix]
h = (1, f, z)
A_x · h = 0 over Z
This issue stops at constructing and checking that relation. It does not commit
the witness or construct a PIOP/proof.
Source of truth
Use the SHA-256 construction in docs/sha256-f2z-note, particularly:
Section 1, "The SHA-256 constraint system"
Figure 3, the sparse block structure of M_mix
Table 2, the integer row families
Table 3, the logical matrix dimensions
Section 2.1, the logical witness ordering
The document is normative for the mathematical relation. Prototype code may be
used as a reference, but the relation and index maps should be re-derived from
the document.
Relation variant
Implement the 206-row compression-core relation first.
The public instance consists of:
one 512-bit message block, represented as 16 SHA-256 words
the incoming chaining state H_in
the terminal state S_65
The relation does not include the final feed-forward additions. The
feed-forward and digest-only variants have different witness dimensions and
are out of scope for this issue.
Round constants K_1, ..., K_64 are fixed parameters, not witness values.
1. Typed relation and index layout
Add a shared SHA-256 relation crate, tentatively:
crates/sha256-relation
It should be usable by both the prover and verifier without depending on either
crate.
Define typed identifiers for at least:
committed witness bits
virtual witness bits
complete h coordinates
SHA words and trace positions
constraint families and row identifiers
There must be one authoritative implementation of each index mapping.
Witness synthesis, M_mix, A_x, the prover, and the verifier must not carry
independent copies of the layout arithmetic.
The logical relation layout must remain separate from the later physical
commitment layout, padding, and transpose.
2. Native witness synthesis
For one compression, synthesize the committed witness
f = (
a[-2..=64],
e[-2..=64],
W[1..=64],
bin3(mu_a[1..=64]),
bin3(mu_e[1..=64]),
bin2(mu_W[17..=64])
)
All word bits and carry bits are stored LSB first. Carry encodings are
round-major.
The six prologue words are initialized from the incoming state:
The synthesizer may retain a[65] and e[65] internally to construct and
check S_65, but they are public values and are not included in the committed
compression-core witness.
If a byte-oriented message adapter is exposed, it must parse each SHA-256
message word in big-endian byte order. The relation itself stores the bits of
each resulting word LSB first.
3. Construct M_mix
Represent M_mix as typed sparse XOR taps. Do not construct a dense 13,312 × 6,816 allocation in production code.
For LSB-first word bits, define:
(R_r u)[i] = u[(i + r) mod 32]
(S_r u)[i] =
u[i + r], when i < 32 - r
0, otherwise
S1 - SHA-256 relation: witness synthesis and sparse M/A construction
Implement the executable SHA-256 compression relation described in
docs/sha256-f2z-note.This issue owns:
M_mixthat derives virtual XOR values.A_xthat checks the SHA-256 wordequations.
The completed implementation must produce an exactly satisfied relation:
This issue stops at constructing and checking that relation. It does not commit
the witness or construct a PIOP/proof.
Source of truth
Use the SHA-256 construction in
docs/sha256-f2z-note, particularly:M_mixThe document is normative for the mathematical relation. Prototype code may be
used as a reference, but the relation and index maps should be re-derived from
the document.
Relation variant
Implement the 206-row compression-core relation first.
The public instance consists of:
H_inS_65The relation does not include the final feed-forward additions. The
feed-forward and digest-only variants have different witness dimensions and
are out of scope for this issue.
Round constants
K_1, ..., K_64are fixed parameters, not witness values.1. Typed relation and index layout
Add a shared SHA-256 relation crate, tentatively:
It should be usable by both the prover and verifier without depending on either
crate.
Define typed identifiers for at least:
hcoordinatesThere must be one authoritative implementation of each index mapping.
Witness synthesis,
M_mix,A_x, the prover, and the verifier must not carryindependent copies of the layout arithmetic.
The logical relation layout must remain separate from the later physical
commitment layout, padding, and transpose.
2. Native witness synthesis
For one compression, synthesize the committed witness
All word bits and carry bits are stored LSB first. Carry encodings are
round-major.
The six prologue words are initialized from the incoming state:
The synthesizer may retain
a[65]ande[65]internally to construct andcheck
S_65, but they are public values and are not included in the committedcompression-core witness.
Schedule carries
For
t = 17..=64, compute the full integer sumand define
Round carries
For each
t = 1..=64, compute the full integer sumsand define
Use sufficiently wide integer intermediates, such as
u64. Do not usewrapping_addbefore extracting the quotient carry.The exact carry bounds are:
If a byte-oriented message adapter is exposed, it must parse each SHA-256
message word in big-endian byte order. The relation itself stores the bits of
each resulting word LSB first.
3. Construct M_mix
Represent
M_mixas typed sparse XOR taps. Do not construct a dense13,312 × 6,816allocation in production code.For LSB-first word bits, define:
The virtual families are:
Rotation indices are reduced modulo 32. Shift terms outside the word are
omitted rather than wrapped.
The family ranges are:
The same sparse representation must support:
z = M_mix(f)M_mix^T(q)zmust always be derived through this map. No API may accept virtual bits asan independent witness.
4. Construct A_x
Construct
A_xas sparse signed-integer rows overThe leading coordinate
h[0] = 1is fixed by the relation and must not beprovided as a prover-controlled value.
For a bit-vector word
u, useDefine the bridge expressions
Emit the following row families.
State update C_a
For
t = 1..=64:At
t = 64,a[65]is public and is accumulated into the fixed-coordinatecoefficient.
State update C_e
For
t = 1..=64:At
t = 64,e[65]is public and is accumulated into the fixed-coordinatecoefficient.
Schedule update C_W
For
t = 17..=64:Boundary rows
Emit the following 30 word equalities:
Explicitly, the terminal trace pins:
The public values
S_65[0] = a[65]andS_65[4] = e[65]are checked inC_a(64)andC_e(64).Public message words, chaining-state words, terminal-state words, and round
constants are accumulated into the coefficient of
h[0].Build and check these rows over exact signed integers. Projection into
F_qbelongs to the later PIOP issue.
Expected relation size
For one SHA-256 compression core:
fzM_mixM = [I; M_mix]h = (1, f, z)A_xCommitted-witness census
Virtual-witness census
Constraint-row census
Expected bounds
The implementation must enforce or assert the following structural bounds:
Every prover-dependent coordinate of
his a bit.M_mixhas exactly 35,216 nonzero entries, all equal to one.Every
M_mixrow has support at most three.The largest non-fixed coefficient magnitude in
A_xis2^35.Maximum structural sparse-row widths, including the fixed coordinate, are:
For each emitted row define
The current construction must satisfy the conservative bound
Expose or calculate this bound from the emitted rows so the downstream PIOP can
check
For the configured
q = 2^100 - 15, this leaves a wide margin against modularaliasing.
Downstream shape contract
This issue does not implement the PIOP, but it must expose enough stable shape
metadata for the PIOP issue to assert:
The later evaluation-shaping sumcheck will therefore use 15 variables and
individual degree two.
Suggested API shape
The exact names are flexible, but the resulting interface should support the
equivalent of:
The verifier-facing relation and index definitions must not require access to
the native witness synthesizer.
Out of scope
F_qqchunked opener from E6 - Prover core: mod-q chunked opener, pre-sumcheck, sumcheck prover #7M_mixorA_xValidation
Done when all of the following hold:
Standard SHA-256 compression vectors match an independent implementation.
Random compression instances produce exactly 6,816 committed bits.
M_mix(f)produces exactly 13,312 virtual bits.M_mixhas exactly 35,216 nonzero entries.Every generated valid instance satisfies
A_x h = 0exactly over theintegers.
The
A_xrow count is exactly 206 with the expected family census.Every generated row satisfies the documented coefficient, sparsity, and
B_rowbounds.The adjoint identity passes for randomized binary vectors:
Negative tests independently mutate:
and demonstrate rejection by the appropriate relation.
Dedicated tests cover the zero-filled portions of
SHR^3andSHR^10.Golden index tests pin representative coordinates from every committed and
virtual family.
Boundary tests pin the complete prologue, initial-state, message, and
terminal-state mappings.
The fixed coordinate is always one and cannot be supplied by the prover.
Production code does not allocate either matrix densely.
The workspace passes:
Dependencies
pinned before this relation is frozen.
Effort M.