ProgramData::segment_count's doc referenced the pre-rename `loader_core`
path; fix to `program_loader_core`. Tighten execute_deploy's and
MAX_SEGMENT_DATA_LEN's doc comments and one test's rationale comment.
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>
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.
CallerData and the PDA derivation primitives keyed authorization off a
program's image id (ProgramId), so two deployments of identical bytecode
with different update_auth collided on the same PDA. Switch derivation,
wire fields, and comparisons to the program's real dispatch AccountId
throughout the host, guest, and test-harness code, including the
privacy-circuit test harness's default dispatch address and the
wrapped_token/ping_receiver governance-authorization check, which
compared against the wrong address via the legacy bijection.
Codebase-wide rename of the stale loader_core crate name to
program_loader_core (192 call sites, plus Cargo.toml dependency
declarations), needed after the loader crate's rename landed upstream.
ping_receiver/wrapped_token's UpdateSources handler, cross_zone_inbox's
inbox_source_marker_account_id (moved from the now-superseded
cross_zone_marker crate), and several test/genesis call sites still
referenced ProgramId-bijection addresses or pre-unification struct
shapes (CrossZoneMessage.src_program_id, WrappedTokenConfig/
ReceiverConfig field types, InboxInstruction::Dispatch's tuple form)
that this branch's own dispatch-address unification had already moved
past elsewhere.
Programs dispatch at the address seeded via with_programs/a live Deploy
(loader_core::immutable_deploy_account_id), not the bijection
AccountId::from(program_id) used by the legacy ProgramDeploymentTransaction
storage shape. This sweep threads the correct address through
lee/lez/integration_tests/wallet-ffi call sites and fixes 7 dispatch-address
bugs the mismatch was masking: bijection-vs-real-PDA mismatches in
lez/wallet's native_token_transfer facade, integration_tests'
auth_transfer/private and private_pda suites, wallet-ffi's
generic_transaction FFI boundary, a stale assertion in program_deployment.rs,
and a stale expected-error string in cross_zone_state_machine.rs.
Also includes a full clippy/fmt pass: doc-comment reflow, #[expect(...)]
attribute additions, redundant type-annotation/unused-import removal, and
two assert!s added purely for bounds-check elision on already-guarded
slices — no logic changes. Both CI clippy invocations and cargo fmt --check
are clean.
Verified: RISC0_DEV_MODE=1 cargo test -p lee --lib (214 passed) and the
broader sanity set across lee/wallet/bridge_lock_core/ping_core/
cross_zone_outbox_core/sequencer_core (mock features) both green.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Privacy-preserving circuit:
- Add ProgramImageClaim, letting a Deploy-created program's real image_id be
anchored to its account for privacy-circuit env::verify, with the sequencer
independently re-deriving the real image_id via get_program to authenticate
the claim (journal reconstruction, same pattern as public_actions pre-states).
- Fix compute_public_authorized_pdas and the private circuit's
resolve_authorization_and_record_bindings to use the caller's real recovered
image_id instead of bijection-guessing it from the caller's account_id, which
was wrong for Deploy-created callers.
Program storage:
- V03State::insert_program (used by both genesis's with_programs and live
ProgramDeploymentTransaction execution) now always writes the Deploy
two-account shape (ProgramData header + segment), not the legacy
PROGRAM_STORAGE_OWNER raw-elf shape. The header stays at the existing
bijection address so no dispatch-address reference needed to change; only
the segment (never a caller-facing address) moves to its PDA.
- Drop the now-redundant ProgramAlreadyExists pre-check in
ProgramDeploymentTransaction validation; PDA claiming already prevents
redeploying an account.
- Migrate remaining tests off ProgramDeploymentTransaction onto native Deploy
(sequencer_core, integration_tests' auth_transfer and block_size_limit),
adding a shared deploy_targets/deploy_transaction/encoded_tx_size helper.
Rebuild artifacts and the prebuilt test fixture for the circuit and program
storage changes.
- RESERVED_DEPLOYMENT_PROGRAM_ACCOUNT_ID: restore the SHA256 derivation
docstring that explains the constant instead of leaving it as an opaque
byte array, and switch the array itself to a hex literal (hex-literal,
already a workspace dependency) for readability.
- Rename the loader/loader_core crate to program_loader/program_loader_core
to disambiguate it, across the directory, package name, workspace
members/dependency alias, both dependent crates, and every call site.
Marvin Jones