ZKM

Jul 1, 2025

In Part 1, we laid out the architectural reasons ZKM selected MIPS32r2 as the foundation for our zkVM: higher opcode density, stable specification, and hardware-proven toolchain maturity. In this follow-up, we go a level deeper - exploring how microarchitectural traits of MIPS align with zero-knowledge circuit design, and where RISC-V introduces complexity that must be actively mitigated.

Instruction Decode in ZK: Why It Matters

In traditional computing, instruction decoding is handled by hardware logic with virtually no performance penalty. In a zkVM, however, instruction decode logic must be expressed as arithmetic constraints. Every bit that must be matched, selected, or transformed adds rows to the trace and selectors to the constraint system. Complexity here directly impacts prover performance.

MIPS: Regularity and Flatness by Design

MIPS32r2 was designed around simplicity, uniformity, and fixed formats. These traits directly reduce the arithmetic burden in zkVM contexts:

Fixed Instruction Width: All MIPS32r2 instructions are 32 bits wide, eliminating the need to handle variable-length decodes. In ZK, this means simpler constraints for the instruction fetch and decode stages.
Field Predictability: MIPS instructions follow a consistent field layout (opcode, source/dest registers, function codes). Constraint systems can index and match against fixed bit positions without dynamic branching or lookup-based disambiguation.
Compact Opcode Space: MIPS has a limited, stable set of core opcodes. Lower encoding entropy leads to simpler constraint selectors - avoiding long selector chains or wide matching logic.

These traits enable deterministic, low-overhead instruction decoding in ZK. They also reduce the need for intermediate representations (IR) or lookup-based opcode dispatch systems, which are often used in other zkVMs to compensate for less structured ISAs.

RISC-V: Modularity Comes at a Cost

RISC-V’s instruction set was designed for hardware modularity and long-term extensibility. While this makes sense for silicon-level design, it creates overhead in a proving context:

Variable-Length Instructions: RISC-V supports compressed 16-bit instructions, standard 32-bit, and longer encodings for future extensions. This increases constraint complexity during the decode phase, since the VM must match and interpret variable widths.
Dynamic Extension Surface: Optional extensions or custom opcodes mean the decoder logic must be generalized and open-ended - introducing conditional constraint logic or requiring preprocessing through IR.
Higher Entropy: RISC-V’s opcode space includes many reserved or vendor-defined slots. In ZK, this means wider selectors and more circuit branching unless the architecture is tightly constrained.

These challenges are surmountable, and several zkVM teams are actively working around them. But the cost is real: more constraints, more trace length, and often, slower proving performance.

ZK Circuits Reward Determinism

The guiding principle here is that zero-knowledge circuits reward determinism and punish variability. The more structured and predictable the instruction set, the fewer gates are needed to enforce correctness. MIPS delivers that structure natively, without sacrificing expressiveness.

For a MIPS-based zkVM, this translates to:

Shorter decode logic per instruction
Fewer selector constraints
Lower trace width and length
No need for IR expansion or dynamic dispatch circuits

These aren’t theoretical advantages. They impact prover throughput, memory footprint, and composability when integrated into recursive systems.

Beyond the ISA: Full-Stack Control

ZKM’s approach isn’t limited to ISA choice. We build the entire stack - from compiler to constraint system to recursive verifier. That gives us freedom to tune each layer without being constrained by external toolchains or protocol mismatches.

When building verifiable compute systems, architectural simplicity compounds. It makes proof generation faster, circuit auditing easier, and version upgrades safer. MIPS gives us that simplicity not just at the opcode level, but at the circuit boundary.

This is why our production-ready zkVM is built on MIPS. Not just because it performs better - but because it verifies better.

Subscribe to the ZKM Blog to stay updated with the latest research by ZKM.

Get started with ZKM: Docs‍

Build with ZKM: Github

H1

h2

‍

h3

‍

H4

H5

What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

aasdasd

Experience in the fast-paced and dynamic work culture of an international team
Excellent growth opportunity as your role expands in direct relation to the growth of your region’s participation/involvement/adoption
Learn about the Metis ecosystem and its products

1. Metis Technical Advocate
2. Metis Community Advocate

// Get all <p> elements in the document
const paragraphs = document.querySelectorAll('p');

// Loop through each paragraph to check if it's preceded by an <h1> or <h2>
paragraphs.forEach(paragraph => {
    // Get the previous sibling element of the current paragraph
    const previousElement = paragraph.previousElementSibling;
    
    // Check if the previous element is an <h1> or <h2>
    if (previousElement && (previousElement.tagName === 'H1' || previousElement.tagName === 'H2')) {
        // Change the margin of the current paragraph
        paragraph.style.marginTop = '20px'; // Adjust the margin value as needed
    }
});

‍

Headings, paragraphs,

‍

Headings, paragraphs,

Cross-chain Asset Transfer Without a Bridge - Part One

To accomplish cross-chain asset transfer, most of the solutions currently available are based on a bridge, a separate, intermediate entity, which is typically trusted with holding these assets during some period of the transaction. This trust assumption is undesirable since it provides a large opportunity for attack. In this post I will explain that, assuming the existence of a zkRollup, one can implement cross-chain asset transfer without the need for additional trust assumptions (such as a bridge).

Lookup Argument (Logup) and Code Analysis

When representing computations as circuits, there are often complex operations such as bitwise XOR and bitwise AND. For example, performing a bitwise XOR operation on two 32-bit bitstrings usually requires hundreds of addition and multiplication gates, significantly increasing circuit size. Introducing the Lookup argument protocol effectively reduces circuit complexity.

Instruction Decode in ZK: Why It Matters

MIPS: Regularity and Flatness by Design

MIPS32r2 was designed around simplicity, uniformity, and fixed formats. These traits directly reduce the arithmetic burden in zkVM contexts:

Fixed Instruction Width: All MIPS32r2 instructions are 32 bits wide, eliminating the need to handle variable-length decodes. In ZK, this means simpler constraints for the instruction fetch and decode stages.
Field Predictability: MIPS instructions follow a consistent field layout (opcode, source/dest registers, function codes). Constraint systems can index and match against fixed bit positions without dynamic branching or lookup-based disambiguation.
Compact Opcode Space: MIPS has a limited, stable set of core opcodes. Lower encoding entropy leads to simpler constraint selectors - avoiding long selector chains or wide matching logic.

RISC-V: Modularity Comes at a Cost

RISC-V’s instruction set was designed for hardware modularity and long-term extensibility. While this makes sense for silicon-level design, it creates overhead in a proving context:

Variable-Length Instructions: RISC-V supports compressed 16-bit instructions, standard 32-bit, and longer encodings for future extensions. This increases constraint complexity during the decode phase, since the VM must match and interpret variable widths.
Dynamic Extension Surface: Optional extensions or custom opcodes mean the decoder logic must be generalized and open-ended - introducing conditional constraint logic or requiring preprocessing through IR.
Higher Entropy: RISC-V’s opcode space includes many reserved or vendor-defined slots. In ZK, this means wider selectors and more circuit branching unless the architecture is tightly constrained.

These challenges are surmountable, and several zkVM teams are actively working around them. But the cost is real: more constraints, more trace length, and often, slower proving performance.

ZK Circuits Reward Determinism

For a MIPS-based zkVM, this translates to:

Shorter decode logic per instruction
Fewer selector constraints
Lower trace width and length
No need for IR expansion or dynamic dispatch circuits

These aren’t theoretical advantages. They impact prover throughput, memory footprint, and composability when integrated into recursive systems.

Beyond the ISA: Full-Stack Control

This is why our production-ready zkVM is built on MIPS. Not just because it performs better - but because it verifies better.

Subscribe to the ZKM Blog to stay updated with the latest research by ZKM.

Get started with ZKM: Docs‍

Build with ZKM: Github