feat: add blake2b compression precompile

[0xkanekiken]

The implementation is based on reference #180 and partially addresses issue #231. In the Blake2b hash function, the state and message elements are represented as u64 values, whereas the sp1 standard supports u32 words. As a result, each u64 is implemented using two u32 limbs, with appropriate handling for this format.

Furthermore, two operations for u64 data types have been introduced:

• Fixed right shift for u64.
• Addition for u64.

The XOR operation for u64 can be derived from the XOR operations of individual u32 limbs.

To-Do:

• Add tests.
• Integrate with sp1.

[0xkanekiken]

encountered the following verification error and need to figure out how to resolve it

[kevjue]

@0xkanekiken - I see that your PR is modeled off of the Blake3 precompile. I recently fixed a bug in that precompile which I believe also affects this PR.

[0xkanekiken]

@kevjue- thank you. I had the same question when I was taking a look at the constraints of blake3. However, I noticed that the round_index was updated to ROUND_COUNT, which seemed to make the constraint valid. In fact, the tests for blake3 were also passing.

sp1/core/src/syscall/precompiles/blake3/compress/trace.rs

Lines 108 to 116 in 4cf6377

	pad_rows(&mut rows, || {
	let mut row = [F::zero(); NUM_BLAKE3_COMPRESS_INNER_COLS];
	let cols: &mut Blake3CompressInnerCols<F> = row.as_mut_slice().borrow_mut();
	// Put this value in this padded row to avoid failing the constraint.
	cols.round_index = F::from_canonical_usize(ROUND_COUNT);
	row
	});

I attempted to incorporate the fix you introduced, but I am still encountering the NonZeroCumulativeSum error. Is there a more systematic approach to evaluating all the AIR and determining whether it satisfies the constraints or not?

[kevjue]

@0xkanekiken - Ya, the fix PR removed the need for setting round_index. That was there to deal with the very last real row of blake3 where it expected the next (which would be a padded row) row to have a value of round_index + 1, which would be ROUND_COUNT.

Regarding the NonZeroCumulativeSum issue, that means that something is inconsistent with your interactions (a term we use for communication between chips).

You can try adding this function (

sp1/core/src/lookup/debug.rs

Line 112 in 0494105

pub fn debug_interactions_with_all_chips<SC: StarkGenericConfig<Val = BabyBear>>(

) in your test case which will output any inconsistencies. Here is an example of how to use it:

sp1/core/src/memory/global.rs

Line 200 in 0494105

fn test_memory_lookup_interactions() {

.

I actually suspect that all your constraints in your blake2b air related to the blake logic are fine. You normally encounter the NonZeroCumulativeSum after the constraints for the AIR are checked. You may want to check your memory constraints as that uses interactions.

[0xkanekiken]

Thank you for all the guidance and support! Indeed, the problem stemmed from how I defined the memory access AIR constraints. I've addressed this issue in 54a416e. Consequently, the tests are passing, and I'm able to generate the proof. It's ready for a review now.

[kevjue]

Thanks for the PR @0xkanekiken ! In general, it looks great! But we'll take a closer look at it soon.

[puma314]

would it be possible to import a pure rust implementation of blake2b in this program and then get the output_state from calling that so that we have a ground truth reference for the code?

[puma314]

do we not already have a generic thing of doing this? this seems like a really good utility to have in airbuilder in general tbh, so maybe we should move it to a move general crate with all the existing air builder methods

[0xkanekiken]

should I address this issue in the current PR, or should it be handled in a separate PR by creating an issue?

[puma314]

At some point, we should merge a PR like this for the blake2b precompile if there is further demand, but for now it's not high priority and this PR is quite out of date so closing for now.