Microsoft’s Magnetar Turns Hash-Only Proving Into a Laptop Benchmark Win, but Recursion Is Still Unimplemented

On October 15, Microsoft Research published “Proof-based general-purpose computing with Magnetar”, a blog post by Srinath Setty about a new zero-knowledge virtual machine, or zkVM: software that runs an ordinary program and returns a proof that the run was correct. The post says Magnetar “runs 10 to 39 times faster on average than the prior fastest comparable systems” and “rests its security only on standard hash functions.” It sends readers to a technical paper, dated October 5, that “gives the full design, security analysis, and measurements.”

I read the paper against the blog. The speed claim holds up on the paper’s own table: I recomputed the three geometric means from its results and got the paper’s figures. What the blog leaves out is the price and the scope. The proofs run about 600 KiB, the recursion behind the claim that Magnetar can prove programs of any size is described in the paper as proposed rather than implemented, and the paper’s security theorem covers a succinct argument of knowledge rather than zero knowledge. Those are three different kinds of statement, one measured, one designed and one not claimed, and the blog’s wording does not separate them.

What Magnetar is

A zero-knowledge proof system lets a prover run a computation and hand a verifier a certificate that the output is right, so the verifier does not have to repeat the work. A zkVM does that for any program compiled for a standard processor design. Magnetar targets RV64I, the 64-bit base integer instruction set of RISC-V, so code written in Rust, Go or C and compiled as usual can be proven without hand-building a circuit. Its proof engine, BinarySpartan, works over binary fields, and its security rests on a standard hash function such as SHA-256 or SHA-3. The blog says it needs “no elliptic curves, no lattices, no special-purpose hash functions, no trusted setup, and no unproven conjecture about error-correcting codes.”

Two terms matter for the rest of this piece. A proof is succinct when it is much cheaper to check than the program was to run. A proof system is recursive when it can verify a proof of its own kind inside another proof, which lets a prover split a long execution into chunks and fold the chunk proofs into one. The paper’s abstract names three properties, general-purpose proving, hash-based post-quantum security and efficient recursion, and says Magnetar is “the first zkVM to simultaneously satisfy” all three.

The speed numbers recompute

The blog’s “10 to 39” is a range of three geometric means over 15 small workloads, not one average. The paper’s Table 2 sets Magnetar against Jolt with a lattice-based commitment (Jolt-Akita), Jolt with an elliptic-curve commitment (Jolt-Dory) and SP1 Hypercube, which the paper classes as a “hash-and-more-based” zkVM. I typed the per-workload throughputs from that table into a script and recomputed the ratios. They match the paper’s figures.

Magnetar itself is set to 120 bits of “provable security.” The last column covers the three workloads (SHA-256, token transfer and radix sort) that the paper reruns on longer traces. Jolt’s throughput rises with trace length and peaks at 2²⁷ or 2²⁸ cycles, and the paper’s Table 7 puts the low end of each range at radix sort, the workload where it says Magnetar’s lead over Jolt-Akita is smallest at 2²² cycles.

Several conditions sit behind the table, and the paper’s setup section states most of them. Every system ran on the 12 performance cores of one M4 Max MacBook Pro with 128 GiB of memory, one prover at a time, as the median of three runs after a warm-up run, and the paper reports no GPU runs for any system. The 15 workloads are small kernels: a Fibonacci loop, a 16-word buffer copy, a 64-node pointer chase, the decoding of a 17-byte LZ4 block. The ERC-20 token workloads “exercise only the token logic” and “do not verify signatures or check Keccak Merkle paths.”

Because the systems count cycles differently, the paper compares completed application-level operations per second, filling a fixed budget of each system’s own cycles. That is why the lead varies by workload, from about 15 times over Jolt-Akita on SHA-256 to about 6 times on radix sort. It also means the blog’s “7.2 to 8.7 million processor instructions per second” is not quite the paper’s unit. The paper counts virtual cycles, “each of which executes one virtual instruction,” and one instruction of a RISC-V program can expand into several.

The baselines were run “as released” at different security levels: Magnetar’s 120 bits sit above SP1 Hypercube’s 100-bit target and Jolt-Dory’s roughly 100 bits, near Jolt-Akita’s roughly 122, and below ZisK’s stated 128. The three hash workloads run in software on every system, “without precompiles,” the dedicated circuits some zkVMs offer for common operations. Those three rows do not drive the headline: dropping them moves my geometric means only to 9.0, 17.4 and 39.9 times for Jolt-Akita, Jolt-Dory and SP1 Hypercube. They do mean the paper reports no run with the baselines’ precompiles switched on, so it does not show how hash-heavy programs compare that way.

The ZisK and Lineth comparisons use one workload each: both provers take minutes per proof on the test machine, and the paper says “neither may be optimized for a laptop.” On token transfers Magnetar’s prover is about 330 times faster than ZisK’s “local CPU prover,” “although ZisK may not be optimized for a MacBook.” ZisK’s main tables have a fixed size of 2²² rows, so its proving time stays at 212 seconds when the work drops to a quarter, and Magnetar’s lead at 2²⁰ cycles grows to about 1,100 times. Against Lineth the paper reports about 2,500 times, comparing Magnetar at 2²⁰ cycles with Lineth on 15,360 transfers, and says it “did not verify the resulting level” of Lineth’s security. Those two comparisons appear to be what the blog’s “more than 300 times faster than two others on a token-transfer benchmark” refers to.

The paper’s optimized variant, Magnetar (opt), raises the geometric means to about 12.7, 24 and 52 times over Jolt-Akita, Jolt-Dory and SP1 Hypercube and trims prover memory by 36 to 40 percent. That matches the blog’s statement that it “increases each speedup reported here by about 1.3×.”

What the blog leaves out: proof size and memory

The blog gives no proof size and no memory figure for Magnetar. The paper’s abstract does: “proofs of about 600 KiB” that verify in 11 to 13 milliseconds. The blog’s opening describes zero-knowledge proofs in general as producing “a short proof.” That fits the verification time and is small beside the prover’s memory, but the comparison below shows where 600 KiB sits among zkVMs.

The figures are the largest per-workload values at 2²² cycles from the paper’s Table 2, with peak memory taken as the largest over all runs, except the ZisK row, which comes from Table 4 and covers one workload. On that workload Magnetar’s figures are 599 KiB, 11 milliseconds and 6 GiB.

Magnetar’s proofs are about 4.6 times smaller than SP1 Hypercube’s core proofs and about 6.6 times larger than Jolt’s. The paper explains the second gap this way: “curve- and lattice-based commitments prove evaluations with a logarithmic number of group or ring elements, whereas a hash-based commitment proves them with Merkle authentication paths for many queries.” So the size is the price of the hash-only design. Jolt-Akita also verifies faster, in under 9 milliseconds against Magnetar’s 11 to 13.

Memory is the other omission. Magnetar’s prover peaks at 6.4 GiB on a trace of 2²² cycles, about 1.6 KiB per cycle, against about 0.5 KiB per cycle for Jolt. The paper says “Further space optimizations of Magnetar’s prover remain to be done,” and the optimized variant peaks at 4.0 GiB. Magnetar is the lighter prover against SP1 Hypercube and ZisK, not against Jolt.

Recursion is a design, not a result

The claim that matters most for real programs is this one: “This is what allows Magnetar to prove computations of any size, by proving them in pieces and then combining the pieces. This also allows Magnetar to prove a long-running system such as a ledger or a blockchain.” The paper’s argument is straightforward. Magnetar’s verifier is mostly hashing and binary-field arithmetic, which is what BinarySpartan proves well, so checking a Magnetar proof inside Magnetar should be cheap.

What the paper does not do is build it. Its related-work discussion says Magnetar “proposes to prove successive execution chunks and recursively compose their proofs by proving an implementation of its own verifier,” and continues: “Neither proposed scaling path has been implemented.” The other path is Jolt’s streaming prover. The evaluation matches: Magnetar runs on single traces of up to 2²⁴ cycles, which the paper calls “the largest chunk size we expect to use,” and each reported proof covers one trace. The paper says something similar of Jolt-Akita: support for recursion there is “work in progress at the time of writing.”

That bounds what the measurements say. A trace of 2²⁴ cycles is about 16.8 million virtual cycles. On my arithmetic, a 3 GHz core executing one instruction per cycle covers that in under six milliseconds, so the longest execution the paper proves is milliseconds of ordinary computing. A program that ran for one second at that pace would need roughly 180 such chunks plus the recursion that is not yet built, and proving it at the paper’s 7.2 to 8.7 million cycles per second would take about 345 to 417 seconds, a floor because one instruction can take several virtual cycles. Against the blog’s statement that proofs have historically taken “millions of times more computation than running the program itself,” several hundred times or more is a large step. It is not yet routine.

The paper also ties its size problem to recursion. The final proof in a chain “covers only the verifier of the preceding proof,” so it can be produced at a lower code rate, with fewer queries and “hence a smaller proof.” The sentence that carries the weight is “We expect the gap to narrow under recursive composition.” That is a plan, with no measurement behind it yet.

Zero knowledge is not what the theorem says

The blog calls Magnetar “a zero-knowledge virtual machine,” and its opening section leans on privacy. “With the zero-knowledge property, the proof also reveals nothing about inputs that should stay private,” it says, and “Regulated financial institutions could prove that transactions were processed correctly without making their transactions public.”

The paper uses “zkVM” as the name of a category. Programs may take a private input, and the relation Magnetar proves includes one, but the paper’s first footnote says: “Most zkVMs provide only a succinct argument of virtual-machine execution; zero knowledge is an additional property.” Its security result, Theorem 1, says the construction is “a transparent preprocessing SNARK” with a stated knowledge error, and that the Fiat-Shamir transformation, which replaces the verifier’s random challenges with hash outputs, makes it non-interactive “in the random oracle model.” I found no statement that the proof hides the private input. The paper contains no occurrence of “hiding,” “blinding” or “simulator.” That does not show Magnetar leaks anything. It means the paper claims soundness, succinctness and transparency, and the blog’s privacy examples need a property the paper does not claim.

The naming habit is wider than Magnetar. SP1’s security page says: “While our implementations of Groth16 and PLONK are zero-knowledge, individual STARK proofs in SP1 do not currently satisfy the zero-knowledge property.” A team that needs hiding should ask for it by name and ask where it is proved.

The hash-only claim matches the paper

The hash-only claim is the part of the blog that tracks the paper most closely. The 120-bit figure is described as provable: each round has soundness error at most 2 to the power of minus 120, using only proven proximity gaps for Reed-Solomon codes within the unique-decoding radius, and the security proof is in the random oracle model, which treats the hash function as an ideal random function. The blog says hash functions are “the basis of the stateless hash-based signatures that NIST standardized as its own conservative post-quantum option,” and NIST’s FIPS 205 does specify “the stateless hash-based digital signature algorithm (SLH-DSA).” For Microsoft the choice comes with a date: its June 30 Security Blog post “Accelerating the quantum-safe timeline” says “the goal is to transition products and services to PQC by 2029.” Readers following that migration may recognize the size problem from our tutorial on Merkle Tree Certificates and from our Python adoption checklist.

One framing in the paper needs a note. Its abstract says some earlier zkVMs “rest on conjectured soundness.” SP1’s documentation says “SP1 Hypercube does not rely on proximity gap conjectures.” The paper’s specific case against SP1 Hypercube is narrower: it uses Poseidon2 hashes, an elliptic-curve multiset hash for memory consistency across shards, and a 100-bit target. Those are the differences to weigh.

What generality costs

A zkVM buys generality, and the same author’s BinarySpartan paper hints at the price. Its abstract reports “Keccak-f at 287,000 permutations/second, including witness generation” on an M4 Max MacBook Pro using its 12 performance cores and no GPU. Magnetar’s Table 2 shows 888 Keccak-f1600 permutations per second when the hash runs in software inside the zkVM, a gap of about 320 times. I could read only the abstract, because the ePrint server returned a bot challenge for the PDF, so I cannot say whether the security settings or the permutation width match. Read it as a rough sense of scale, not a benchmark.

What to ask before building on it

Can I run it? The paper names the exact version it benchmarked for every baseline, for example Jolt at commit 7a052796e373, but gives none for Magnetar, and the blog links no code. A GitHub search of the microsoft organization for “magnetar” returned no repository when I ran it on October 15, although its earlier Spartan repository is there. Until code exists, the speed figures are the paper’s alone.

Do I need zero knowledge? If the use case involves private inputs, ask Microsoft Research whether Magnetar hides them and where that property is proved.

Can my channel carry 600 KiB per proof? Until recursion exists, that is the price of the hash-only design.

How long is my program? The paper’s measurements stop at 2²⁴ cycles per proof, and anything longer depends on recursion that is described as proposed. Setting that against the length of the programs you want to prove is the first feasibility check.

Which security level do I need? Magnetar’s 120 provable bits compare with 100 for SP1 Hypercube and Jolt-Dory and a stated 128 for ZisK, and the paper compares systems “as released” rather than at one level.

Has the implementation been reviewed? The theorem covers the protocol on paper, and I found no mention of an implementation audit in the paper. Our earlier post on Trail of Bits’ audit of a zero-knowledge VM describes a signature-forgery bug in a VM’s code rather than in its protocol theory.

None of this undercuts the measured result. On the paper’s own table, Magnetar proves RISC-V executions from about 6 to 66 times faster than the three zkVMs it was set against, depending on workload and baseline, on one laptop, with a security argument that rests on one kind of primitive. The blog’s “a future where cryptographic proofs are a routine output of computation” depends on two things the paper does not show: recursion, which it says is not implemented, and, for privacy uses, a zero-knowledge property it does not claim.

Sources and method

The sources are the blog post, the paper (also on its Microsoft Research publication page), the abstract page of the BinarySpartan paper, SP1’s Hypercube security model page, NIST’s FIPS 205 page and Microsoft’s June 30 Security Blog post. I did not run Magnetar or any baseline, so every speed, size and memory figure is the paper’s, and I checked each quotation from the paper against text extracted from its PDF.

I read Table 2 from the PDF’s text layer and typed the per-workload throughputs into a script. The geometric means come out at 18.10, 9.59 and 39.05, and the per-workload ranges at 11.6 to 37.0, 5.8 to 19.6 and 23.9 to 66.1, which the paper rounds to about 18, 9.6 and 39 and to 12 to 37, 6 to 20 and 24 to 66. The geometric means without the three hash rows (9.0, 17.4 and 39.9), the 320 times figure for Keccak and the chunk arithmetic, which assumes 3 GHz and one instruction per cycle, are my own calculations and illustrations, not measurements. The paper does not name a source language for its 15 workloads, so I cannot say how much of the blog’s “Rust, Go, or C” the evaluation exercises.