Marvin JonesandClaude Sonnet 5
7a1fc9a834
Deploy previously stored a program's entire ELF in one segment account, requiring DATA_MAX_LENGTH to be temporarily raised to 700 KiB. Splits user_elf across as many 96 KiB segment PDAs as its size requires (loader_core::plan_deploy, shared by execute_deploy and V03State::insert_program so genesis and live Deploy can't diverge on chunk boundaries or PDA derivation), and restores DATA_MAX_LENGTH to 100 KiB. ProgramData's segment_number field is renamed segment_count (same layout, now a count instead of a fixed index) so a reader knows how many segments to fetch without probing. V03State::get_program reconstructs a program's bytecode by fetching and concatenating segment_count segments, then recomputes the real image_id from the reconstructed bytes and compares it to the header's claim, returning LeeError::InvalidProgramBytecode on mismatch rather than silently returning corrupted bytecode. Companion fix: SeenShard::MAX_DELIVERIES recomputed for the restored 100 KiB cap (was sized for 700 KiB). Base PR scope only: segments exist, written in a single transaction, reassembly verified. Batched multi-transaction writing and the Data type's underlying word-encoding overhead are deferred follow-ups. Verified: RISC0_DEV_MODE=1 cargo test -p loader_core (8 passed) and -p lee --lib (218 passed); -p sequencer_core --features mock (109 passed, 1 known-unrelated ignore). Both CI clippy invocations and cargo fmt --check clean. Test fixture regenerated for the new header schema and multi-segment genesis shape. NOT yet verified: the full integration_tests suite. tps_test hangs past a 25-minute timeout with no progress logged even before its first phase completes (context setup / vault-claim submission) - root cause not yet identified. A ~13ms-per-dispatch cost from the new image-id integrity check in get_program was measured and ruled out as insufficient to explain a hang of this magnitude on its own. Needs follow-up before this branch is considered done. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.