feat: sha256 air WIP

[luffykai]

on hold for now

ref INT-1726

[linear]

INT-1726 SHA2-256 Air

Motivation

Currently in-circuit we only have the BabyBear poseidon2 hash implementation.

For use in rollup state for an indexed merkle tree, we want to use sha2-256 (henceforth referred to as sha256) since it is not field dependent and also more friendly for on-chain / non-ZK usage.

Moreover, a second motivation is that as described here there is a good chance that we may want to use sha256 as the native hash for STARKs and use it in the aggregation circuits as well.

Implementation

Ultimately, we will want a chip that integrates into the VM in https://github.com/axiom-crypto/afs-prototype/tree/main/vm with COMPRESS_SHA256 and PERM_SHA256 opcodes similar to poseidon opcodes. However we begin with a sha256-air standalone implementation, which should be a separate crate similar to poseidon2-air

Background

SHA256 hashes variable length arrays of bits, but it does it by processing 512=16*32 bits (64 bytes) blocks at a time. For domain separation of variable length arrays, it always does a special padding after the array to both domain separate and make the length a multiple of 512 bits. (There are some arguments that the padding is unnecessary for the internal node hashes of a Merkle tree as an additional optimization, but we will stick with the version where all hashes must be padded to conform to existing rust implementations. For reference, the hash without padding is referred to as PseudoCryptographicHasher whereas the padded one is CryptographicHasher.)

AIR

We want an AIR (or set of AIRs) that can do the SHA256 hash with padding — this is commonly split into at least two AIRs, one that does it without padding (the compress part) and one that handles padding.

For now we do not care about separating the sha256 compress from padding and we just want something that can handle the variable length hash with padding. (We may want to refactor later to have a standalone compress for Merkle tree implementations as mentioned above.)

halo2 reference

We want to implement an AIR resembling this halo2 implementation of sha256 which handles the compress and padding together. This reference implementation requires 72 rows for each 512-bit block (SHA256 has 64 rounds per block).

• columns — this has closer to 100 columns
• constraints in halo2

The main distinction between halo2 and AIRs is that in halo2, you can have constraints where the local row references a row which is a fixed i rows before or after. In AIRs, currently the local row can only reference the next row 1 row after.

plonky3

We still want one row for each of the 64 rounds, but round i will need access to w[i-15], w[i-2], w[i-16], w[i-7]. Because of the restriction of next row only in AIRs, there are (at least) two ways to address this: (this are just suggestions, if you see a better way, please propose it!)

• Option 1: in round i, store a sliding window of 16 32-bit words w[i-16..i-1] (stored as 32 16-bit field elements). Only bit decompose w[i-15] and w[i-2] for the purpose of rightrotate (with additional columns).
  • Use the subair pattern for bit decomposition and rightrotate — these can be put in chips crate (perhaps in a new module bits)
• Option 2: use interactions between the Air and itself to send round i-15 to round i , etc.
  • Overally complicated and since we need to send i-15, i-2, i-7 the cost overhead of interactions is close to 32 columns anyways.

Verdict: We can try Option 1 unless there are unforeseen issues.

We may need an implementation using even fewer columns for the final STARK aggregation, but that will be scoped separately.

Reference

The pseudocode in the wikipedia article is quite good as a reference: https://en.wikipedia.org/wiki/SHA-2#Pseudocode

For reference, the analog for keccak256 hash (SHA3) is:

• AIR without padding (just keccakf): https://github.com/Plonky3/Plonky3/blob/main/keccak-air/src/lib.rs
  • it does an entire block (64*25=1600 bits) in NUM_ROUNDS=24 rows — this takes something like 2000 columns
  • approach is very similar to the one described here
• here is WIP implementation of keccak sponge to handle the padding part — this is often tricky

sp1's SHA256 AIR implementation is here: https://github.com/succinctlabs/sp1/tree/main/core/src/syscall/precompiles/sha256