Marvin Jones
55b678cc85
instruction_data is word-serialized (risc0_zkvm::serde) for guest consumption, which encodes Vec<u8> at 4 bytes/word since it doesn't route through serialize_bytes — a Deploy transaction's wire size ran ~4x its raw bytecode. Add Message/ChainedCall::raw_payload, a plain borsh-encoded Vec<u8> alongside instruction_data, and move Deploy's bytecode there instead; Instruction::Deploy now only carries update_auth. Also stop transmitting and storing the ~32KB RISC0 platform kernel on every single deployment: it's byte-identical across every guest artifact in this repo, so Deploy now carries only the program-specific user_elf and execute_deploy reconstructs the full two-ELF binary from an embedded kernel constant to compute image_id. Segment accounts store user_elf only, roughly halving their footprint for a typical program. Measured on real Deploy dispatch (claimer, ~366KB): encoded transaction size dropped from 1,464,777 bytes to 334,094 bytes.
Programs
This crate serves two purposes at once:
- Provide one entrypoint for
cargo risczero buildto build guest binaries used in LEZ in one shot. - Provide access to the built binaries wrapped with
Programtype.
Binaries
This crate contains binaries taken from sub-directories: one per each program. This binaries are meant to be compiled with cargo risczero build. No other use is intended for them.
Library
You may import this crate as a library but it will only make sense if you enable artifacts feature flag.
Enabling this flag will make crate expect that binaries where already built and put in the right place (use just build-artifacts for that).
Why not just risc0_build::embed_methods() ?
Because this will either provide non-deterministic guest build or requires Docker. And forcing to use Docker to build the project is not an option for us especially because we also build Docker images for our services, which would mean we would have to call docker from docker (and this is not really feasible).
risc0_build::embed_methods() works well when you don't need deterministic build or Docker is not a problem. This is the case for our tests and we use it there.