TL;DR
-
MiniJAM is about to conclude Stage 0, and there are no remaining blockers to the full testnet. We are now moving into the next stage: ZkRefine.
-
ZkRefine does not rely on nodes replaying Work Packages to establish correctness; instead, it uses zero-knowledge proofs to provide cryptographic guarantees of correctness.
-
During the initial design process, however, we realized that ZkRefine might also be reusable by a future Kusama. We are therefore sharing these ideas here at an early stage. If the Kusama community is interested, we will try to preserve compatibility and reusability from the beginning of the design.
Recap
During the previous stage, we completed the work we had planned on schedule, and many other pieces are now ready or close to ready.
-
Stage 0 testnet: It launched successfully and helped us identify a number of issues in both design and implementation. It will soon be taken offline as we prepare for the full testnet.
-
MINI Genesis: We launched MINI Genesis. We are very grateful for the support and trust of everyone who participated, and we will continue pushing forward until we reach the goal we originally set out to achieve.
-
Mini Lucky: Core development is largely complete, but for several reasons it is currently being reworked. We expect it to open within the next couple of days.
-
Incentive Market: The core implementation is largely complete.
ZkRefine
MiniJAM currently relies on a group of off-chain workers to ensure the correctness of Refine, which places this part of the system outside the shared security of the parachain. This works, but it is not the security model we ultimately want. The correctness of Refine should, as far as possible, be guaranteed cryptographically rather than by introducing another small “sub-consensus” system. Given the rapid development of the ZK ecosystem, the technology has now matured to the point where production deployment is realistic. MiniJAM therefore formally enters its next stage: ZkRefine.
Refine has very clear input and output boundaries, and we barely need to deal with global state—with one well-known exception that should be relatively straightforward to handle from an engineering perspective. This makes Refine particularly well suited to a proof system. In simple terms, ZkRefine needs to prove:
refine(committed_inputs) -> (result, exports, gas)
We already have an initial architecture, although the concrete implementation will still depend on what we learn during the early stages. Our general strategy is to reuse as much of the existing ZK ecosystem as possible, including systems such as OpenVM, rather than implementing a proving backend entirely from scratch. Below is a brief overview of the relevant work.
From PVM to Proofs
PVM is based on RISC-V, but it contains specialized designs in many areas and therefore cannot be executed directly by the existing frontends of general-purpose ZK frameworks. At present, we see two possible approaches: translation and a native backend.
Translating to a general-purpose zkVM ISA
One relatively simple approach is to implement a semantics-preserving translator that converts PVM execution into instructions already supported by existing zkVMs. The advantages are clear:
-
less engineering work;
-
support for different backends;
-
keeping PVM decoupled from the proving system.
The disadvantages are equally clear. Instruction expansion, memory emulation, and similar overheads may lead to substantially lower proving efficiency.
Native PVM proving backend
The alternative is to implement an optimized AIR directly for PVM, allowing dedicated optimizations for PVM’s 64-bit ALU, Memory, Gas, and Host Calls. This approach should offer significantly better performance, but the engineering effort is likely to be at least an order of magnitude greater.
Preprocessing
PVM runtime was designed around high determinism and high efficiency, and this turns out to align very well with the requirements of a ZK runtime, because ZK effectively amplifies the computational cost of runtime execution. We therefore want to preprocess as many PVM properties as possible where the runtime only needs to verify rather than infer them, so that the ZK runtime does not have to recompute the same information for every proof. This includes Gas Metadata, Control Flow, and similar information, which needs to be bound to the program and incorporated into consensus.
It is worth noting that some PVM design choices can appear almost redundant. For example, k may seem largely unnecessary because the same information could be inferred at runtime, which is also how more traditional designs tend to approach the problem. But once k and j are combined, deterministic control flow can be obtained very cheaply outside the runtime. Through preprocessing, this can save a substantial amount of ZK proving cost.
This was not an optimization designed specifically for ZK, but the optimization goals happen to be the same: high runtime determinism. Information removes uncertainty; you either pay space to remove that uncertainty in advance, or pay computation to remove it at runtime. Therefore, statements such as “this design reduces the blob size by X%” or “the system still works after removing this redundancy” are not sufficient to demonstrate that one design is better than another. What really needs to be compared is the cost across the entire lifecycle of the ecosystem.
Smoke
This is our next small milestone. The goal is to implement the complete Refine flow in the simplest possible way. It mainly includes:
-
Proof relation: Define the public inputs, witness, and outputs; prove that the actual inputs correspond to their commitments; and correctly produce
(result, exports, gas). -
Host Calls: Implement the core Host Calls required by Refine and ensure that values returned by
fetch,historical_lookup, and similar calls are correctly bound to their corresponding commitments. -
Memory and Gas: Implement both strictly according to PVM semantics.
-
Disable Inner PVM: Inner PVM is a relatively independent and complex problem. Host Calls related to it will be disabled during this stage, while compatibility will still be considered at the architectural level. We will address this module separately in a later stage.
-
Consistency testing: The same inputs must produce exactly the same outputs under native Refine and ZkRefine.
-
Performance baseline: Measure proving performance across different stages and components to provide data for architectural decisions. We will also compare the performance of the two approaches described above. If the difference remains within an acceptable range, we can consider a gradual transition from translation toward native optimization; otherwise, we may choose the native approach directly.
Kusama: Extreme Decentralization
ZkRefine does not reduce the verification cost of consensus itself; it addresses the off-chain computation side of the system. If we look only at Refine in isolation, it does not reduce the total amount of computation performed across the network, and its economic efficiency is therefore not necessarily better than JAM’s current approach. This is not really a question of which path is universally superior, but rather a design choice, and that choice ultimately depends on what mission the network is trying to pursue.
In my view, this corresponds quite naturally to the different choices Polkadot and Kusama can make. Polkadot can continue to optimize toward a network capable of supporting large-scale applications and high overall efficiency. Kusama, whose direction increasingly emphasizes ZK, privacy, cypherpunk values, and radical experimentation, can pursue a different objective: extreme decentralization.
Distributed Accumulation
ZkRefine allows validators to verify Refine without replaying the Work Package. This substantially reduces the workload placed on guarantors and makes it possible for validators to operate in more resource-constrained environments, but this is still not the most important part.
Historically, small independent validators, including home validators, have found it difficult to compete with professional node operators in terms of resource efficiency, even before considering MEV. JAM, however, provides another possibility: the accumulation of Work Reports is parallelizable. A group of resource-constrained Workers can independently take on different portions of the accumulation workload without communicating with one another during execution. Once their work is complete, they can return artifacts including state deltas and Gas usage to a Coordinator, which then completes the final state transition. After verification, all nodes only need to synchronize the resulting state deltas.
JAM’s design, in which the state root is computed after execution, also means that this advantage is not weakened by requiring every Worker to converge back into a single serialized execution path.
Different Workers can also take on different responsibilities. CPU Workers can handle Accumulate, storage nodes can handle data, machines equipped with GPUs or other cryptographic accelerators can handle Proof Generation, while a Coordinator is responsible for scheduling and final integration.
Taken together, these properties allow a Validator to genuinely evolve from one high-performance server into a group of ordinary devices.
Data Availability
Once guarantors and auditors no longer need to recover the complete execution data solely for the purpose of replaying Refine, the network topology changes. This gives us room to optimize the network specifically around validator groups and further strengthen the advantages of this structure.
-
At a minimum, streaming can be used to make block propagation friendlier to validator groups. In the future, RLNC may also be applied to block propagation and data availability.
-
Data availability itself can also be structured around validator groups. Individual Workers do not need to carry all data; they only need to store a deterministic portion of it, for example through a small DHT or even more direct node routing. We also expect that many such groups will eventually consist of geographically close nodes, giving them very low internal network latency.
-
We could also construct an improved DHT between validator groups, allowing different groups to back up differentiated pieces of data for one another. This would allow a validator group to preserve data even under relatively high churn among its own internal nodes.
Internal Consensus Within a Validator Group
A validator group can implement different internal coordination and consensus mechanisms according to its own needs. For example, PoP could be used as the basis for Sybil resistance and membership admission, allowing real users to join a group with extremely low staking requirements and then participate in an internal consensus mechanism built on top of that identity layer.
This could further reduce operating costs while increasing the number of independent individuals who actually participate in the network.
Other Considerations
Of course, validator groups also introduce disadvantages that cannot be completely eliminated, the most important of which is likely to be state storage. Professional node operators can keep a reasonably bounded state almost entirely in memory, while resource-constrained nodes may have difficulty doing so. In many cases, I/O overhead alone can erase much of the benefit gained from other optimizations.
We expect this to require substantial engineering work and careful optimization on the Worker side.
Next
-
ZkRefine Smoke: approximately 7–10 days.
-
Mini Lucky: very soon.
-
Incentive Market: launch on testnet.
-
MiniJAM: optimize and address the issues discovered during the Stage 0 testnet.