EPF - Update 10

# EPF - Update 10 ## tl;dr * Referring to the previous [update](https://hackmd.io/@0xprivateChaos/SkoNCwmYle), I’ve resolved the linter error. The issue was caused by the `zkcrypto/bls12_381` dependency. * Refactored the input data script (`build.rs`) and the [guest program](https://github.com/0xprivateChaos/grandine-zk/blob/zisk/zkvm/guest/zisk/src/main.rs). Implemented `bincode` for serialization and deserialization. * Successfully executed the guest program using the Zisk emulator. ## Details ### Resolving the linter error (`zkcrypto/bls12_381` dependency) When building the program with [zkcrypto/bls12_381](https://github.com/zkcrypto/bls12_381), I initially encountered linter errors. After digging into the Zisk workspace, I discovered that Zisk does not directly use `zkcrypto/bls12_381`; instead, it relies on its own adaptation [zisk-patch-bls12_381](https://github.com/0xPolygonHermez/zisk-patch-bls12_381) (package named `sp1_bls12_381`). Since our build required `bls12_381`, I cloned the Zisk fork, renamed the package back to `bls12_381`, and published it in a separate repo. I then patched it into the workspace via the root `Cargo.toml`: ```toml= [patch.'https://github.com/zkcrypto/bls12_381.git'] bls12_381 = { git = "https://github.com/0xprivateChaos/zisk-patch-bls12_381.git", branch = "features/sp1-libv5.0.0" } ``` However, this introduced another issue: version conflicts with the host program’s dependencies. * The Zisk patch was still using `sp1-lib v4.0.0`, which depended on `sp1-primitives v4.0.0`, in turn pulling in `p3-baby-bear v0.2.0`. * Meanwhile, the host program used `sp1-sdk v5.2.1`, which required `p3-baby-bear v0.2.3`. To resolve this, I upgraded the Zisk-patched `bls12_381` to use `sp1-lib v5.0.0`, aligning the dependency tree with the host program. Finally, the build succeeded when run manually: ```zsh= cargo-zisk build --release ``` This produced the ELF file at: `target/riscv64ima-zisk-zkvm-elf/release/zkvm_guest_zisk` ### Executing the guest program with the Zisk emulator Zisk provides a built-in emulator (`ziskemu`) that allows running guest programs for testing before generating a proof. The emulator performs the exact same execution as proof generation, except it does not produce a proof. This makes it useful for debugging and sanity checks. From the `grandine-zk/zkvm/guest/zisk` [directory](https://github.com/0xprivateChaos/grandine-zk/tree/zisk/zkvm/guest/zisk), the guest program can be executed with: ```zsh= ziskemu -e ../../../target/riscv64ima-zisk-zkvm-elf/release/zkvm_guest_zisk -i build/input.bin ``` **Handling step limits** For simple cases (e.g., an empty block as a sanity check), the emulator runs without issues. However, for programs requiring a large number of Zisk steps, you may encounter: ``` Error during emulation: EmulationNoCompleted Error: Error executing Run command ``` To fix this, increase the maximum number of execution steps with the `-n` (`--max-steps`) flag. For example: ```zsh= ziskemu -e ../../../target/riscv64ima-zisk-zkvm-elf/release/zkvm_guest_zisk -i build/input.bin -n 10000000000 ``` **Output format** The emulator outputs results in eight 32-bit chunks, since Zisk splits a 256-bit (32-byte) result into 32-bit words: ``` 9dcf9143 91241db4 713f72e8 db3cbe96 9934d9cc 571de2c7 6a047f05 dd780251 ``` This chunked format reflects how [Zisk handles](https://0xpolygonhermez.github.io/zisk/getting_started/quickstart.html#execute) outputs [internally](https://github.com/0xprivateChaos/grandine-zk/blob/7429fe417639ed2a9c5a49aab6aab8384e7327d3/zkvm/guest/zisk/src/main.rs#L85). ## Next Week Complete the host and guest program wiring.