Marvin Jones
dcc0c4b950
Introduces a new loader_program/loader_core crate pair implementing a Deploy instruction that claims a program's ProgramData PDA account (image_id, segment_number, update_auth, elf_segment), unifying deployment with ordinary PublicTransaction dispatch instead of the separate ProgramDeploymentTransaction path. Measured against every real program in this repo, computing a program's image_id inside the zkVM costs ~1,400-1,500 cycles per byte of deployed bytecode, pushing real deployments to 500M-900M cycles against the 32M public-execution cap (vs. ~27ms natively, since ProgramDeploymentTransaction's equivalent check runs as a plain host function today). To keep the unified dispatch path viable, Deploy is special-cased in from_public_transaction: calls targeting the reserved RESERVED_DEPLOYMENT_PROGRAM_ACCOUNT_ID run loader_core::execute_deploy natively instead of through the interpreted guest executor, wrapped in catch_unwind since the shared execute_deploy logic validates via assert!/expect() like every other guest program, relying on that boundary instead of the zkVM's own panic-to-Result conversion. The loader guest binary is kept buildable and covered by a test that runs it for real and asserts its output matches the native path exactly, so the two can't silently drift apart.
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.