Specialized chips
This page covers the specialised chips inside the ZisK prover. It explains why the proof is split into many small per-chip proofs rather than one giant circuit, introduces the Main chip and the specialists it dispatches to (base operations, precompiles, Memory and MemAlign), and shows how the chips communicate over five buses with a single root-level bus-balancing check guaranteeing every message sent was received exactly once.
When the prover runs your guest, it isn't producing one giant proof of a single CPU. It's producing a collection of small proofs, one per chip, that get combined later. Each chip is specialised for a single class of operations and proves only its own slice of the work. This page covers what the chips are, why ZisK is built that way, and how the chips talk to each other.
Why split the proof at all?
Think of it as the difference between a Swiss-army knife and a toolbox.
| Approach | Trade-off |
|---|---|
| One giant circuit | A single object handles every RISC-V operation, but every blade pays the cost of the entire knife being thick. Memory-read constraints have to coexist with cryptographic-hashing constraints, and they all run sequentially. |
| Specialised chips | Each tool is shaped for one job and is as small as that job allows. The hash chip doesn't pay the cost of the memory chip; the memory chip doesn't pay the cost of the hash chip. And the toolbox can be carried by multiple people in parallel. |
The split also pays off in extensibility. Each chip is bounded by a bus interface the messages it sends and receives and nothing else. New primitives slot into that interface as new chips without disturbing the rest of the system:
| Approach | Cost of adding a new primitive |
|---|---|
| One giant circuit | Modify the global circuit, re-derive constraints, regenerate proving and verification keys for every program. A hard fork. |
| Specialised chips | Ship the new chip with its bus interface. Existing chips, their proofs, and previously-compiled program ROMs are unaffected. |
ZisK takes the toolbox approach. The chips together cover the full ZisK ISA, but each chip can be designed, optimised, proved, and aggregated independently and the catalogue can keep growing as cryptography moves without rebuilding the rest of the system or forcing existing guest programs to change.
Specialized chips approach
Each chip is a separate arithmetic object with its own constraint system, its own trace, and its own slice of the final proof. The diagram below shows how they fit together, with the Main chip at the spine of execution and the specialists hanging off it.
Main
Main is the execution spine: it allocates one row to every instruction, reads the next opcode from the Program ROM, and decodes it. Simple instructions — no-ops, jumps, and control flow — it computes directly in its own row. Anything that needs a dedicated constraint system (integer arithmetic, bitwise logic, cryptographic primitives) it delegates to a specialist and just records the dispatch. The specialists run their own constraint systems and produce their own proof obligations, which is what lets each one be as small as its task allows.
Memory
Memory is the most-connected chip in the diagram, and how an access reaches it depends on alignment, not on who's calling. Aligned 8-byte operations go straight to the Memory Bus. Sub-word and unaligned reads or writes are routed through MemAlign first, which decomposes them into the aligned 8-byte operations the Memory chip natively handles.
In practice this means precompiles typically take the direct path: their natural unit (a SHA-256 block, a curve coordinate, a DMA word) is already aligned and 8-byte wide, so they stream bulk reads and writes onto the Memory Bus without paying any alignment cost.
Base operations (ALU)
The base-operation chips prove the everyday RISC-V ISA: the integer math, bitwise logic, comparisons, shifts, and sign extensions that ordinary code spends most of its instructions on.
| Chip | What it handles |
|---|---|
| Arith | Integer addition, subtraction, multiplication, division (signed and unsigned). |
| Binary | Bitwise AND/OR/XOR/NOT, comparisons (<, ==), sign extensions. |
| Shift | Logical and arithmetic shifts, left and right. |
Precompiles
Precompiles handle operations whose plain-RISC-V cost would dominate the proof: cryptographic hashes, elliptic-curve arithmetic, big-integer math, and bulk memory transfers. Each is its own independent chip carrying the full proof obligation for the operation it represents.
| Family | Primitives |
|---|---|
| Hashes | SHA-256, Keccak-f[1600], BLAKE2b, Poseidon2 |
| Elliptic curves | secp256k1, secp256r1, BN254, BLS12-381 — curve add/double and the underlying field arithmetic |
| Big-integer arithmetic | add256, arith256, arith256_mod, arith384_mod |
| Bulk memory transfers | dma_memcpy, dma_memcmp, dma_inputcpy, and variants |
Chips communication
Chips don't share memory or registers, they're separate arithmetic objects. They communicate through buses: shared channels where one chip emits a message and another receives the same message, and the proof system enforces that every send matches a receive. The five buses ZisK uses are:
| Bus | What it carries |
|---|---|
| Operation Bus | "Do this". Main asks a specialist to run an operation. |
| ROM Bus | "Give me the next instruction". Fetches from the program ROM. |
| Memory Bus | "Read/write this address". Every memory access in the program. |
| Continuation Bus | "Here's where I left off". Chip state passed across segment boundaries. |
| Table Buses | "Look this up" Queries from chips into their precomputed tables. |
The rule that ties the independent chip proofs together is called bus balancing: every message put on a bus has to be picked up exactly once, with the same content. Nothing sent goes unreceived; nothing received was never sent.
It's enforced as a single arithmetic equality at the very end of aggregation: the sum of every chip's contribution to each bus, across every chip and every segment, must cancel to zero. If any message was dropped, duplicated, or altered, the sum doesn't cancel and the proof is rejected.
Anatomy of an instruction
The chips-and-buses picture is easiest to internalise by walking one instruction through the system. Whatever it is typical instruction takes a single row in the Main chip's trace, and that row coordinates a handful of bus messages:
| Step | Bus | What happens |
|---|---|---|
| Fetch | ROM Bus | Main sends the current program counter; the ROM chip returns the decoded instruction. |
| Resolve operands | Memory Bus | Source operands are read from registers and memory. Every read becomes a message the Memory chip must later reconcile against the most recent write. |
| Dispatch | Operation Bus | Main sends the operation and its operands to whichever specialised chip handles it. |
| Receive result | Operation Bus | The dispatched chip returns its result. Main doesn't compute it locally; it just records that the dispatch happened. |
| Write result | Memory Bus | Results are written. Stores, register updates, and precompile output addresses all flow through the same channel. |
For a plain integer instruction that is the entire story; a handful of bus messages, one row in Main. For a precompile call (SHA-256, ECDSA, a pairing) the dispatched chip does the rest of the work itself: it reads bulk input from memory over the Memory Bus, runs many internal rows, writes its output back to memory, and signals "done" on the Operation Bus:
In both cases, each bus message is a constraint. The Memory chip later proves every read returned the most recent write; the dispatched chip later proves its result is correct. The Main chip itself never verifies any of this locally, bus balancing, checked globally at the root proof, guarantees that every message was received by the right chip with the right content.
Summary
A ZisK proof is the joint output of a small catalogue of specialised chips. Main allocates one row per instruction and dispatches the heavy work to specialists: base operations (Arith, Binary, Shift) for the everyday ALU, precompiles (hashes, curves, big-integer, DMA) for primitives that would otherwise dominate the proof, and Memory for every read and write, with MemAlign decomposing sub-word and unaligned access first. The chips never share state directly. They communicate through five buses (Operation, ROM, Memory, Continuation, Table), and a single arithmetic equality at the root proof, called bus balancing, guarantees every send was matched by exactly one receive with matching content.