Memory Paging and LA Cost Model

Execution Motivation

During large LLM inference, a single point trace may exceed the local memory of the Coprocessor node. Generating STARK all at once can lead to overflow and extremely high generation delays.

Paging Strategy

1. Page Table Creation

Trace is sequentially divided into 4 MiB blocks, assigning an incrementing pageID to each block, and recording the offset → hash correspondence table.

2. Lazy Load

The circuit only pulls the corresponding page when specific operations need to be verified; the rest is deferred to the aggregation layer, significantly reducing peak RAM.

3. Paging Commitment

• Each page generates a Poseidon chunk root.

• All page roots are hashed again to form the PageRoot, outputting to the final π_agg public input.

4. On-chain Verification

The Verifier performs a single consistency check on the PageRoot, without needing to verify page by page, with Gas costs equivalent to regular aggregation.

LA Fee Rate Algorithm

fee = base + (pageCount × μ)

• base is dynamically adjusted by FeeOracle;

• μ is the additional fee per page, used to subsidize nodes for paging hash IO.

• Each completed page unlocks the corresponding μ, reducing cash pressure for long tasks.

Risk Collateral

• Prover must attach pageCount × β of LA when stake();

• If any page hash is inconsistent with the PageRoot, SlashGuard immediately deducts 80% of the excess collateral and blacklists that node for 1 epoch.

• 50% of the forfeited amount is destroyed, and 50% goes to the insurance pool to compensate users.

Governance Parameters

Parameter Initial Value Adjustable Authority

pageSize 4 MiB Governor 48 h Timelock

μ 0.2 LA FeeOracle Adaptive

β 0.5 LA Governor

Paging allows extremely large traces to run on standard hardware, while LA hooks paging fees and additional collateral, binding computational costs, cash flow, and risk control as adjustable functions, balancing performance and security.

#Lagrange

$LA

@Lagrange Official