feat: rvr support for rv64 deferral extention

[mansur20478]

rvr support for deferral extension.

The PR required changes in how the rvr deferral extension reads and write to the memory, from 4 byte granularity to 8 byte. This also meant that for output length, the u64 LE stored right after the commit, formula got changed to accommodate 8 byte granularity.

Also, DEFERRAL_COMMIT_NUM_BYTES had to be updated to DEFERRAL_DIGEST_SIZE * F_NUM_BYTE from DEFERRAL_DIGEST_SIZE * WORD_SIZE. This is because DEFERRAL_DIGEST_SIZE is digest size in field elements, not in WORDS.

resolves INT-8113

[mansur20478]

@claude provide review of this PR. make sure that all deferral related constants are took into account and updated accordingly, make sure that changes that were done are correct

[claude]

Claude finished @mansur20478's task in 5m 2s —— View job

---

PR Review: RVR support for RV64 deferral extension

• Gather context and understand changes
• Review constant updates in rvr-openvm-ffi-common/src/lib.rs
• Review C code changes in rvr_ext_deferral.c
• Review CI changes
• Cross-check all deferral-related constants for consistency
• Post final review

---

Summary

This PR fixes the deferral extension for the RV64 migration by correcting DEFERRAL_COMMIT_NUM_BYTES (which was silently wrong since WORD_SIZE changed from 4 to 8), migrating all guest memory I/O from u32 to u64 granularity, and re-enabling the deferral RVR CI tests.

Correctness: DEFERRAL_COMMIT_NUM_BYTES fix

Correct and important. The core fix changes DEFERRAL_COMMIT_NUM_BYTES from DEFERRAL_DIGEST_SIZE * WORD_SIZE to DEFERRAL_DIGEST_SIZE * F_NUM_BYTES:

• DEFERRAL_DIGEST_SIZE = 8 (field elements), verified by the static assert in crates/vm/src/arch/rvr/abi_consts.rs:32 against DIGEST_WIDTH
• BabyBear field elements are 4 bytes each, so commit = 8 × 4 = 32 bytes (correct)
• The old formula with WORD_SIZE = 8 gave 64 bytes, which was wrong and caused the Rust host callbacks to read/write 64 bytes from 32-byte buffers (buffer overflows in host_deferral_call_lookup and host_deferral_output_lookup)

Downstream derived constants are all correct after the fix:

Constant	Formula	Value	Status
DEFERRAL_COMMIT_NUM_BYTES	8 × 4	32	✅ Fixed
DEFERRAL_OUTPUT_KEY_BYTES	32 + 8	40	✅ Correct
COMMIT_WORDS	32 / 8	4 (u64s)	✅ Correct
OUTPUT_KEY_WORDS	40 / 8	5 (u64s)	✅ Correct
DIGEST_MEMORY_OPS	8 / 8	1	⚠️ See note below

Correctness: u32 → u64 migration in C

All changes are consistent:

• commit_words, key_words, row_words arrays correctly changed from uint32_t[] to uint64_t[]
• All rd_mem_u32_range_traced / wr_mem_u32_range_traced / trace_mem_access_u32_range calls correctly changed to their _u64 variants
• The output_len extraction simplification (key_words[COMMIT_WORDS] instead of manual two-u32 assembly) is correct — the u64 at index 4 is exactly the 8 bytes at byte offset 32, matching the output key layout (commit ++ u64 length)

Correctness: CI change

Removing the TODO comment and uncommenting the deferral RVR test entry is appropriate — this PR lands the support it was waiting for.

Pre-existing issue worth noting

DIGEST_MEMORY_OPS = DEFERRAL_DIGEST_SIZE / WORD_SIZE = 1 — This formula mixes units (field elements ÷ bytes). It produces the correct page-tracking behavior only because pages are large (512 elements at PAGE_BITS=6, PTRS_PER_LEAF=8) and one digest (8 elements starting at a 16-aligned address) always fits within a single page. However, the formula is semantically fragile. If page geometry ever tightened, this would under-report touched pages.

This is not introduced by this PR (it was 8/4=2 in RV32, now 8/8=1 in RV64 — same formula, different numeric result), and there is already a TODO on the deferral address space semantics at rvr_ext_deferral.c:58-60. Just flagging it for awareness.

u32s_as_u8s in rvr-openvm-ffi-common/src/lib.rs:173 uses WORD_SIZE (= 8) instead of size_of::<u32>() (= 4) to compute the output slice length, which would produce a slice 2× too long. This is not part of this PR's diff — pre-existing issue.

Verdict

LGTM. The changes are correct and fix a real bug (wrong commit byte count causing buffer overflows in FFI callbacks). The u32→u64 migration is clean and consistent. No issues introduced by this PR.

---

[github-actions]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

[github-actions]

group	app.proof_time_ms	app.cycles	leaf.proof_time_ms
fibonacci	1,035	4,000,051	400
keccak	16,338	14,365,133	3,025
sha2_bench	8,260	11,167,961	1,010
regex	1,223	4,090,656	360
ecrecover	438	112,210	285
pairing	595	592,827	296
kitchen_sink	3,859	1,979,971	851

Note: cells_used metrics omitted because CUDA tracegen does not expose unpadded trace heights.

Commit: 5c137cf

Benchmark Workflow