Once ZkJAM is implemented, we will have an extremely decentralized and highly scalable network—close to what many other blockchains describe as their ultimate roadmap.
If we cap the gas limit of a single work item at roughly the equivalent of one Ethereum block, then under ideal maximum load, ZkJAM could process:
16 × 341 = 5,456 Ethereum blocks within a single 8-second slot.
Importantly, this is achieved while maintaining extreme decentralization: resource-constrained nodes can participate as validators, and the network can accommodate hundreds of thousands of physical validators.
At the moment, we have only implemented a few basic instructions, one HostCall, and the complete end-to-end proving pipeline. We will continue implementing the full instruction set, HostCalls, Sub-VMs, and gas accounting. Finally, we will implement the network topology.
Once all of this is complete, ZkJAM will be fully operational end to end.
There is no delivery deadline this time. Progress will depend on the resources available to us, so I cannot make a commitment on the timeline.
So far, we have validated the key technical feasibility of the overall approach and made an initial estimation of the potential benefits. However, from an economic perspective, current zkVM implementations still require a prover with very powerful hardware resources.
That said, JAM has a rather unique design space. In practice, we do not necessarily need a complete replication of the currently popular zkVM approach, because we do not necessarily require:
extremely succinct proofs;
extreme optimization for runtime verification;
aggressive recursive compression;
The more important optimization target is TP, rather than reducing |π| to the smallest possible size.
Based on this objective, we explored several directions.
Protocolizing the ZK pipeline:
We explored decomposing the traditional ZK proving pipeline, keeping the algebraic front-end including Sumcheck, while leveraging JAM’s existing online roles, randomness, and interaction capabilities to bypass some of the expensive witness binding and polynomial commitment steps. We also considered Oracle-style approaches. However, we eventually found that this shortcut does not exist. As long as we require the proof to maintain full soundness, the expensive parts will eventually come back in some form.
Multi-Prover:
In theory, these approaches can leverage multiple independent provers to reduce the reliance on witness binding. However, the additional assumptions required by these models are difficult to integrate directly into JAM’s current security model.
Doubly-efficient interactive proofs:
We also investigated several doubly-efficient interactive proof approaches. They are theoretically very close to our requirements and can make the verifier very lightweight. However, the current prover cost, memory requirements, and engineering complexity remain unclear, and they are still some distance away from practical deployment.
At this stage, we believe a more practical direction is a Brakedown-style linear-time proving system.
It prioritizes the prover by keeping the proving cost at a linear scale, while accepting larger proofs and higher verifier costs. Although the proof size and verifier cost are significantly larger, this trade-off may actually be well suited for JAM. We can also apply limited proof compression techniques.
Our next steps are relatively clear:
Continue improving the current ZkJAM implementation based on a general-purpose proving system. In the future, it can be used for Services, and it can also serve as a benchmark baseline during development;
In parallel, implement a Brakedown-based ZkJAM proving path, and evaluate different proof-size / prover-cost trade-offs, including Shockwave, Orion, and SwitchFold / BrakeFold. We consider a 1–3 MB proof per Work Package as an initial engineering target range;
Build models comparing prover time, verifier time, peak memory usage, and proof size, and identify the most suitable trade-off point for JAM.
Any feedback or suggestions on this work would be greatly appreciated.
