blockifier_reexecution: compile Sierra to Casm in-process via library call

[avi-starkware]

Why

blockifier_reexecution (and through it, starknet_transaction_prover) compiles Sierra classes by shelling out to the starknet-sierra-compile sidecar binary. That binary is the only external runtime dependency of the prover: native (non-Docker) deployments fail at the first Sierra-class compilation unless the operator pre-installs it at the exact pinned version (the macOS pain point behind #14379, #14389, #14402).

The subprocess exists for the sequencer gateway, where Sierra classes are user-submitted adversarial input requiring resource-limited process isolation. Re-execution has no such input: every class compiled here is fetched from the chain — already declared, already compiled once by the sequencer under limits. The isolation buys nothing on this path.

What

sierra_to_versioned_contract_class_v1 now compiles in-process via cairo-lang-starknet-classes — the same crate the starknet-sierra-compile binary is a thin CLI wrapper around, already pinned in the workspace at the identical version (2.19.0-rc.2, bumped in lockstep with cairo_compiler_version.txt). Compilation parameters are unchanged: pythonic hints on, all libfuncs list, 10 * DEFAULT_MAX_BYTECODE_SIZE. The SIERRA_COMPILER LazyLock, the subprocess plumbing, and the apollo_compile_to_casm/apollo_compile_to_casm_types dependencies are removed; cairo-lang-starknet-classes moves from dev-dependencies to dependencies. No new external dependencies.

Result: the prover (and the replay tool) become single self-contained binaries — no sidecar to install, no version-mismatch failure mode, and no JSON/tempfile/subprocess round trip per class.

The sequencer node path (apollo_node → SierraCompiler component → apollo_compile_to_casm) is untouched and keeps the subprocess model.

Determinism

New test compiled_fixture_class_matches_expected_compiled_class_hash pins the in-process output to the fixture's known compiled class hash — the hash the gateway's subprocess-based flow verifies for the same class — guarding against divergence from the compiler used elsewhere in the system.

Validation

• cargo test -p blockifier_reexecution — 20 passed (incl. the new determinism test), 0 failed.
• cargo clippy -p blockifier_reexecution --no-deps --all-targets — clean.
• cargo build -p starknet_transaction_prover --features stwo_proving — passes.
• End-to-end: copied the bare prover binary alone to an empty directory and ran it with CARGO_TOOLS_ROOT=/nonexistent and HOME pointing at an empty dir — starts cleanly and stays up, no compiler binary anywhere on the machine path.

Note on #14402

Touches the same function as #14402 (which adds startup verification of the sidecar). If this PR lands, that verification — and the sidecar itself — become unnecessary for the prover; whichever lands second needs a trivial rebase.

🤖 Generated with Claude Code

[reviewable-StarkWare]

This change is 

[avi-starkware]

• starknet_transaction_prover,blockifier_reexecution: drop starknet-sierra-compile sidecar from docker images #14418
• blockifier_reexecution: compile Sierra to Casm in-process via library call #14406 👈 (View in Graphite)
• main-v0.14.3

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

Artifacts upload workflows:

• Started at 2026-06-07T12:17:29Z
• Started at 2026-06-07T12:18:01Z
• Started at 2026-06-08T10:34:01Z

[AvivYossef-starkware]

Can we remove the binary from the replay andstarknet_transaction_prover images?

@AvivYossef-starkware reviewed 4 files and all commit messages, and made 2 comments.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on Yoni-Starkware).

---

crates/blockifier_reexecution/src/compile.rs line 84 at r1 (raw file):

    let extracted_sierra_program = contract_class_for_compilation
        .extract_sierra_program(false)
        .unwrap_or_else(|err| panic!("Failed to extract the Sierra program: {err}"));

not in the scope of this PR ( since it was the behavior before )
But should we avoid panicking? ( we use it in the transaction prover )

Code quote:

.unwrap_or_else

[cursor]

PR Summary

Medium Risk
Changes how Sierra classes are compiled on the re-execution/prover path; correctness depends on matching sequencer compilation output, mitigated by the new hash pin test but still a sensitive execution path.

Overview
Re-execution and the prover no longer depend on the starknet-sierra-compile sidecar. sierra_to_versioned_contract_class_v1 compiles Sierra→Casm in-process via cairo-lang-starknet-classes and apollo_compilation_utils, with the same policy as before (pythonic hints, all libfuncs, 10 * DEFAULT_MAX_BYTECODE_SIZE).

The SIERRA_COMPILER LazyLock, apollo_compile_to_casm / apollo_compile_to_casm_types, and subprocess/JSON plumbing are removed; failures are returned as StateError::StateReadError instead of panicking. A new test compiled_fixture_class_matches_expected_compiled_class_hash pins output to the gateway fixture’s compiled class hash.

The sequencer gateway path (SierraCompiler / subprocess isolation) is unchanged.

^{Reviewed by Cursor Bugbot for commit dc87fbd. Bugbot is set up for automated code reviews on this repo. Configure here.}

[avi-starkware]

crates/blockifier_reexecution/src/compile.rs line 84 at r1 (raw file):

Previously, AvivYossef-starkware wrote…

not in the scope of this PR ( since it was the behavior before )
But should we avoid panicking? ( we use it in the transaction prover )

Done.

[AvivYossef-starkware]

follow app PR

@AvivYossef-starkware reviewed 1 file and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on Yoni-Starkware).