# EPF Week 11 Update This week I rebased my [PR](https://github.com/Dyslex7c/grandine-zk/pull/1) with the original [PR](https://github.com/grandinetech/grandine/pull/304) opened by Artiom for integrating RISC0 and SP1 zkVM benchmarks to Grandine. I had to modify my guest program to add Config as a parameter and also detect the phase the data blobs correspond to by matching the first byte of `phase_bytes` with the known phase indices and carry out the deserializations based on the match (`from_ssz_at_phase` if a match is found, `from_ssz` otherwise). Previously, I had also tried proving beacon chain state transition function locally which took a lot of time before I eventually stopped it, so I tried to run it on [Google colab](https://colab.research.google.com/drive/1wM1_45qT48vbX9QHBQYM8Fi9HQ0iolGJ?usp=sharing), but no luck with that either. I had GPU T4 enabled but for some reason it was not getting utilized. ## Precompiles (sha256 and bls12_381) In the [universal precompiles](https://github.com/grandinetech/universal-precompiles) repository, I opened another [PR](https://github.com/grandinetech/universal-precompiles/pull/1) where I implemented SHA-256 hash compression function for Ziren with ability to directly interact with the precompiles using external system calls such as `syscall_sha256_extend` and `syscall_sha256_compress` from the [documentation](https://docs.zkm.io/dev/precompiles.html) that I found on ZKM precompiles. I figured out a way to detect Ziren zkVM during compile time to be able to use the corresponding hash compression functions at the time ```rust #[cfg(all(target_os = "zkvm", target_vendor = "zkm", target_arch = "mips"))] ``` I also tried to merge precompiles for Ziren on the BLS12-381 elliptic curve but the entire codebase consisting of base field implementations and group operations seemed a bit complicated for me. Hopefully with time as I skim through the codebase more, I will have better understanding and context. I tried to implement the ZKM versions of the core field operations on the BLS12-381 base field `GF(p)` using external system calls which I found in the documentation. One contradictory observation I came across was that the [ziren-patches](https://github.com/ziren-patches/bls12_381/tree/patch-0.8.0) repository uses the standard [zkcrypto](https://github.com/zkcrypto/bls12_381) implementation exactly as it is whereas the system calls Ziren uses are more related to the SP1 implementation which deviates from the [zkcrypto](https://github.com/zkcrypto/bls12_381) implementation in certain areas. Another concern I had was whether Ziren required Montgomery conversions or not. Ziren likely supports Montgomery form since the non-Montgomery form requires a different patch compared to the zkcrypto one. ## Resources - [ziren-patches](https://github.com/ziren-patches/bls12_381/tree/patch-0.8.0) - [Rust crypto-hashes patch](https://github.com/ziren-patches/RustCrypto-hashes/tree/patch-sha2-0.10.8) - [precompiles documentation (zkm)](https://docs.zkm.io/dev/precompiles.html) ## Work for the next week As the original PR by Artiom to integrate R0VM and SP1 into Grandine gets merged, I will open a PR shortly after. It is also nice to have the `prove` operation working and tested for Ziren zkVM. ## Conclusion This week was pretty decent overall. Moving forward with no major blockers from my side, I wish to resolve the remaining precompiles implementation and also get feedback and make any further improvements wherever possible.