A read-only view of one mechanism, outside the article layout.
Deep explainer
Solana verifier stack machine
Step through the verifier as a resumable Solana state machine: each checkpoint selects account memory, typed task stack, owner boundary, and compute-budgeted execution state.
Computer analogyaccount data VM
The verifier behaves like a tiny bytecode interpreter. The client loads a memory image, each Execute call is one instruction cycle, the back stack holds functions still to run, and the front stack holds return values that the next task consumes. That makes the onchain verifier a resumable state machine: account bytes store the state, the task tag selects the transition, and the next transaction resumes from the same memory image.
RAM
Solana account data holds the large proof, task state, and cache.
Opcode
A 4-byte type tag selects which generated task executes next.
Stack
Back frames are scheduled calls; front frames are return values/data.
Protection
Only the owning verifier program can write the current account.
Animated scene
Solana verifier as an account-memory stack machine
Read the verifier like a tiny computer: account data is RAM, the front/back stack is the call/result stack, task tags behave like opcodes, and compute units are the cycle budget.
Active step - changes when you click01 / Load
Current instructionSetup · Client
Materialize account state
Create account memory image
idle
prepare_input builds the repr(C) stack account, fills StarkProof and OODS values, then cast_struct_to_slice_mut turns the whole struct into bytes.
client/src/verify.rs
account writes
0 / 1005 account writes
owner
verifier-a / account1-account2 owned by verifier1-verifier2
front frames
0
back frames
0
front stack0result/data frames
current stateLoad4-byte type tag then task bytes
back stack0scheduled task frames
prepare_input
StarkProof/OODS seed
set_account_data_chunked
The BPF stack holds offsets and references; the 904,176-byte state image lives in account data.
client/src/verify.rs sends SetAccountData batches with a 1.4M CU limit and batch size 100.
No verdict exists until the post-handoff verifier and FRI tail finish.
Solana boundary
Instruction data and transaction size are bounded, so the verifier treats account data as the large mutable memory region.
Artifact now produced
A full BidirectionalStackAccount image is written into account1 through 900-byte SetAccountData chunks.
Static reference - does not change when you clickThe constraints that shaped the pipeline
Account memory904,176 bytes per verifier account
stack buffer65,536 B
cache slab163,864 B
write chunk900 B
StarkProof fieldsOODS valuestyped task bytescached FRI data
Interpreter loopBorrow bytes, cast state, execute one typed task
let mut data = account.try_borrow_mut_data()?;let stack = BidirectionalStackAccount::cast_mut(*data);stack.execute();
The BPF stack holds only references, offsets, and small task locals. Proof-sized state stays inside account data. In state-machine terms, each task frame is the current state, each Execute instruction applies one transition, and the mutated account bytes are the checkpoint for the next transaction.
Four verifier program splitOne verifier pipeline, four executable program accounts
A single giant executable account would combine validate, decommit, OODS, FRI, and generated dispatch into one deploy artifact. Splitting verifier1-4 keeps BPF program artifacts stage-sized, keeps task dispatch local to each phase, and works with Solana ownership rules by moving the account-memory image between stage owners.
Stage 1 · Verifier1Init & STARK Commit
validate_public_input
get_hash
stark_commit
Stage 2 · Verifier2STARK Decommit
stark_verify
table_decommit
Stage 3 · Verifier3STARK Verification
stark_verify_verification
oods_boundary_poly
Stage 4 · Verifier4FRI Verification
fri_verify
fri_commit
Solana account model in this verifierCode accounts execute; data accounts carry verifier memory
Executable program accounts
verifier1-4 are separate deployed program IDs. The split keeps generated verifier code per stage smaller and gives each stage its own owner boundary.
Program data / loader accounts
With the upgradeable loader, a program ID points at program-data bytes written through loader buffer accounts. Code-size pressure lives here, separately from verifier state data.
Verifier state accounts
account1 and account2 are large writable data accounts. They store the 904,176-byte BidirectionalStackAccount image.
Instruction account metas
Each instruction marks source accounts readonly and destination accounts writable; Solana enforces that only the owner program mutates destination data.
Why the implementation looks unusualIt runs like a small interpreter built inside Solana account data
Why cast and unsafe
Solana gives the program bytes. The verifier needs typed state without copying a huge proof into the BPF stack, so repr(C) account bytes are length-checked and cast into the stack account in place.
How memory is managed
The 65,536-byte front/back stack stores length-prefixed frames: tasks are pushed on the back, results on the front, and large proof/cache fields stay in account memory.
Why two accounts
Solana write access is owner-gated. Each verifier writes only to the account it owns, then copies the account image across the account1/account2 ping-pong path.
How limits are handled
Heavy work is split into resumable typed tasks. The client simulates how many Execute calls are needed and sends them under explicit compute-unit budgets.
RAM
The large verifier state lives in Solana account data instead of the BPF stack.
Instruction cycle
Each Execute borrows the account, casts bytes to state, and advances one typed task.
Cycle budget
Compute units cap how much work each transaction can perform.
Memory protection
Solana ownership decides which program can write each account.