JAM: Engineering a Trustless Verified Supercomputer

The blockchain space is littered with architectures that make fundamental engineering mistakes. Most systems either naively scale synchronous execution until hitting physics limits (Ethereum), fragment state into isolated silos with async messaging nightmares (Cosmos/Polkadot), or throw hardware at the problem until achieving Solana’s remarkable instability. Meanwhile, the “scaling solutions” involve SNARKs that multiply computation costs depending on the operation, while introducing trusted setup ceremonies and verifier centralization risks that defeat the entire purpose of decentralization.

JAM (Join-Accumulate Machine) takes a different approach. It’s not revolutionary in the hyperbolic blockchain sense—it’s evolutionary in the engineering sense combining previous inventions that worked and systematically addressing the actual constraints instead of pretending constraints don’t exist.

The Original Web3 Vision: Where Polkadot Failed

The original Web3 vision wasn’t about cramming everything onto blockchains—it was about recreating the Unix philosophy in a trustless environment. Small, focused services doing one thing well, composing cleanly through well-defined interfaces. No monolithic smart contracts trying to be everything. Just clean, modular components you could pipe together, build together.

Polkadot attempted this with parachains but hit a fundamental architectural wall: asyncronous cross-chain messaging with 12-18 second round-trip latency and complex interfacing. This isn’t just slow—it breaks composability at a fundamental level.

Consider a basic DeFi operation: a lending protocol checking collateral values from a DEX. In Unix, this would be a simple pipe operation—milliseconds at most. In Polkadot, it’s:

1. Send XCM message (wait 6 seconds)
2. Remote chain processes (wait 6 seconds)
3. Response returns (wait 6 seconds)
4. Original chain continues

By the time you get your answer, liquidation thresholds have been crossed, arbitrage opportunities have vanished, and your users have left. The async boundary forces every parachain to implement every feature locally—defeating the entire purpose of modular design.

The result? Every parachain runs identical pallets for DEX, lending, stablecoins, governance. Instead of Unix-like specialization, you get monolithic chains pretending to be modular. The maintenance burden is crushing—each chain maintaining forks of the same code, struggling to keep versions synchronized, duplicating security audits.

Polkadot’s XCM is technically impressive for what it is: a secure async messaging protocol. But async messaging is fundamentally the wrong abstraction for composable services. It’s like building Unix where every pipe spawns a distributed transaction—theoretically sound, practically unusable.

JAM fixes this at the architectural level. No persistent chain boundaries. Services execute in parallel during refinement, then compose synchronously during accumulation. Your lending protocol calls the DEX service directly—same block, same state, atomic execution. The Unix pipe dream finally works because there’s no async boundary to break it.

This isn’t a minor improvement—it’s the difference between services that actually compose and chains that pretend to interoperate while duplicating everything.

The Size-Coherency Problem

Every distributed system faces a fundamental limit: as state grows, coherency degrades. This isn’t a software problem—it’s physics. Information propagates at finite speed, whether that’s the speed of light in fiber or the considerably slower speed of packet-switched networks with their inherent jitter and congestion.

Most blockchain designs either:

1. Ignore this (Bitcoin/early Ethereum): Keep everything synchronous until hitting throughput walls
2. Fragment permanently (sharding/rollups): Create isolated state spaces with async bridges
3. Centralize coordination (Solana): Require datacenter-grade hardware and accept regular failures

JAM introduces a pipeline that bounds asynchrony without permanent fragmentation. The “collect-refine-join-accumulate” model isn’t just clever naming—it’s a concrete architectural pattern that maintains unified state while parallelizing computation across validator groups also known as cores.

The RingVRF Innovation: Why 3 Validators Can Match 1,023

Here’s what everyone else gets wrong about blockchain security: the assumption that every validator must check everything. This creates an impossible scaling bottleneck—if everyone validates everything, you can’t do more work than a single machine.

JAM’s Safrole consensus uses Bandersnatch RingVRF (a cryptographic lottery where validators can prove they won without revealing which validator they are) to solve this properly. The key insight: nobody knows who will author a block until the author reveals it. This isn’t just privacy—it’s a fundamental security property that changes the entire game theory.

Traditional systems announce block producers in advance:

• Ethereum: Validators know their slots 2 epochs ahead
• Solana: Leader schedule is public
• Polkadot’s BABE: Uses VRF but reveals winners publicly
• Result: DDoS attacks, targeted corruption, MEV extraction games

With RingVRF in Safrole:

1. Each validator generates tickets using a VRF (Verifiable Random Function)
2. The ticket proves membership in the validator set WITHOUT revealing identity
3. Only when publishing the block does the validator reveal themselves
4. The entropy from each block feeds into future randomness—unbiasable and unpredictable

This anonymity until reveal means attackers can’t target specific validators. But here’s the genius part: it enables JAM’s auditing system to achieve the same security with just 3 validators assigned per core as if every validator checked everything.

Statistical Security Through Unbiased Assignment

JAM assigns exactly 3 validators as “guarantors” to form a CPU-like core. With 1,023 validators and 341 cores, this creates perfect coverage: each validator guarantees exactly one core (1023 ÷ 341 = 3). These guarantors:

1. Execute work-packages and stake their reputation on results
2. Don’t know assignment until the work arrives
3. Can’t collude in advance because assignments use unbiased entropy

Then the auditing kicks in:

• Random validators (selected by VRF) must re-execute work
• Initial selection: 10 cores per validator
• If anyone disputes: exponential expansion of auditors
• Negative judgment triggers: ALL validators audit

The math is brutal for attackers:

• Corrupting specific guarantors: impossible (anonymous assignment)
• Corrupting enough validators: need 342+ out of 1,023
• Cost of failed attack: slashed stake, permanent record

This gives equivalent security to full replication with ~300x less work. The unbiased entropy from Safrole makes it statistically impossible to predict and corrupt the right validators. And yes, it’s proven in ELVES.

PVM: A VM Design For Modern Hardware

The EVM was designed in 2014 for 2014 assumptions. Its 256-bit word size, stack-based architecture, and big-endian encoding are actively hostile to modern CPUs. Running EVM code involves constant overhead translating between its assumptions and reality.

PVM is very much RISC-V rv64em -like general purpose virtual machine with deterministic metering and sturdy sandboxing. No exotic opcodes, no blockchain-specific complexity. Just a standard ISA that:

• Maps directly to native instructions (1.6-2x overhead vs native in benchmarks)
• Works with existing toolchains (LLVM/GCC just work)
• Handles actual programs (has already run Quake in-core with verified on-chain output, rendering frames to the DA layer)

The polkaports repository demonstrates this isn’t theoretical. The team has ported musl(libc alt), patched it for polkavm/corevm, and built working toolchains with Clang 19/20. The result? You can compile standard C/C++/Rust and run it onchain with minimal modifications. No special “blockchain languages,” no transpilation layers, just pedal on the medal with deterministic execution.

The InCore/Onchain Split

JAM’s execution model splits work into two phases:

Incore (Refine): Parallel, stateless computation on 341 cores

• 2GB RAM per workload
• 2MB/s I/O per core
• Executes on validator subsets with crypto-economic guarantees
• Outputs 48KB digests

Onchain (Accumulate): Synchronous state integration

• Full state access
• Atomic updates
• Composable interactions

This isn’t sharding—state remains unified. It’s pipelining with bounded latency (6-12 seconds). The “cache affinity” model borrows from multi-CPU architectures: cores share state through a coherent protocol rather than isolated message passing.

Security relies on the RingVRF properties:

• Guarantees: 3 anonymous validators stake on results (can’t be corrupted in advance)
• Assurances: 2/3+ validators confirm data availability
• Audits: VRF-selected validators re-execute (statistically covers all work)
• Judgments: Negative result triggers universal audit

The entropy accumulator (η) ensures future randomness can’t be biased:

η'₀ = H(η₀ || VRF_output)  // Each block adds entropy
η'₁, η'₂, η'₃ = rotate(η)   // Historical values for epoch transitions

Data Availability That Actually Works

Ethereum’s danksharding promises 87KB/s (as of January 2025). JAM delivers 682MB/s—nearly 8,000x more. How? By not overthinking it:

• Systematic Reed-Solomon erasure coding (342-of-1023 threshold)
• Simple binary Merkle trees (not polynomial commitments)
• 28-day minimum retention for exports
• Direct validator storage (no intermediary networks)

Here’s where JAM gets greedy in the best way: it uses 1-dimensional erasure coding instead of 2D schemes. Why? Because when you already have a 2/3 honest assumption, you don’t need the extra complexity. 1D Reed-Solomon with a 342-of-1023 threshold is:

• Simpler to implement (no cross-dimension dependencies)
• Faster to encode/decode (linear in data size)
• More efficient in practice (no wasted redundancy)
• Perfectly adequate given the security model

This is engineering discipline: don’t add complexity where the security model doesn’t require it. The 2/3 assumption is fundamental to BFT consensus anyway—might as well exploit it for maximum performance.

The Quake demo stored game assets on-chain, loaded them dynamically, and rendered frames—all verifiable, all on-chain. This isn’t a toy; it’s demonstrating that blockchain can handle actual data workloads without hand-waving about “data availability layers.”

CoreVM: Making Native Code Blockchain-Compatible

The polkaports CoreVM service shows how to bridge native code to JAM:

// Regular syscalls forwarded to PVM host
ssize_t write(int fd, const void *buf, size_t count) {
    return pvm_syscall(SYS_write, fd, (uintptr_t)buf, count, 0, 0, 0);
}

This isn’t emulation—it’s syscall forwarding. Native binaries compiled with the musl toolchain run with near-native performance. Demonstrations include:

• Quake: Full game engine, rendering pipeline, asset loading
• Clang/LLVM: Self-hosted compilation
• Standard libraries: musl libc, libstdc++

BusyBox and similar POSIX utilities are trivial given this foundation. You could run a shell on-chain—not because it’s useful, but because the architecture doesn’t arbitrarily prevent it.

The Entropy-Based Security

Traditional blockchain security models are stuck in a trap:

• Have everyone validate everything: doesn’t scale
• Shard validators: creates attack surfaces
• Use committees: allows targeted corruption

JAM breaks this with cascading entropy-based selection:

1. Block Production: RingVRF selects anonymous leaders

   • Can’t DDoS unknown targets
   • Can’t bribe anonymous validators
   • Each block adds unbiasable entropy

2. Guarantor Assignment: 3 validators per core via entropy

   • Assignments unpredictable until work arrives
   • No pre-coordination possible
   • Statistical coverage equivalent to full replication

3. Audit Selection: VRF determines who checks what

   • Initial: 10 random cores per validator
   • Escalation: Exponential growth on disputes
   • Universal: All validators on negative judgment

4. Finality: Only audited blocks finalize

   • No finalization without statistical verification
   • Malicious chains rejected before state commits

The accumulated entropy (η) threads through every decision:

• Past entropy seeds current selections
• Current VRFs add future entropy
• No single party can bias outcomes

This creates a system where 3 validators per core achieve the same security properties as having all 1,023 validators check everything—a 341x efficiency gain without security loss.

Performance Projections Based on Actual Measurements

With 341 cores and measured benchmarks:

• Computation: 0.15-1.5M EVM gas/μs equivalent (vs Ethereum’s 1.25 gas/μs)
• State reads: 1.4M/s (vs Ethereum’s 595/s)
• Throughput: 171K-1.4M TPS depending on workload
• Data availability: 682MB/s sustained
• Network requirements: 500Mbps sustained per validator

These aren’t theoretical limits—measured PVM performance, realistic network assumptions, and conservative overhead estimates support these numbers. The Quake demo validates these projections: complex workloads run at acceptable speeds without architectural bottlenecks.

Security Analysis Without the Hand-Waving

JAM’s security fundamentally relies on making targeted attacks impossible:

1. Anonymity prevents corruption: Can’t bribe validators you can’t identify
2. Entropy prevents prediction: Can’t plan attacks against random assignments
3. Economics prevents irrationality: Slashing makes attacks unprofitable
4. Auditing prevents lies: Statistical coverage catches misexecution

The 2/3+ honest assumption becomes much stronger when attackers:

• Can’t identify targets in advance (RingVRF anonymity)
• Can’t predict assignments (unbiased entropy)
• Face exponential auditor growth on disputes
• Risk total stake loss on detection

Conclusion: When Cryptography Meets Engineering

JAM’s real innovation isn’t in any single component—it’s in recognizing that proper cryptographic primitives (RingVRF) enable engineering solutions previously thought impossible. By making block producers anonymous until reveal and using the resulting unbiased entropy for all assignments, JAM achieves:

• 341x efficiency gain (3 validators vs 1,023) with no security loss
• DDoS resistance without special networking
• Bribery resistance without trusted hardware
• Statistical security without full replication

The choice of 1D erasure coding exemplifies this philosophy: when your security model already assumes 2/3 honesty, don’t waste cycles on 2D complexity. Be greedy for performance where the math allows it.

The Quake demo and PolkaPorts toolchain prove this works in practice. The math is sound—Bandersnatch RingVRF provides information-theoretic security, and the cascading audit system ensures economic rationality.

This is what blockchain architecture looks like when you stop cargo-culting Bitcoin’s “everyone validates everything” and start from first principles. The result: a system that can actually scale without compromising on trustlessness.

The code is there. The cryptography is proven. The only question is whether the blockchain space can accept that sometimes, less replication with better cryptography beats more replication with worse architecture.

Comments