Larger Blocks vs STARK Proofs

StarkWare co-founder Eli Ben-Sasson argues that quantum-safety for Bitcoin is more likely to arrive through ZK STARKs—especially when used to compress the huge signature data expected from post-quantum (PQ) schemes—rather than by simply expanding blocks or accepting slower throughput. He also suggested that Adam Back, founder of Blockstream, aligns with the core idea, though Cointelegraph reported no response from Back to its outreach.

The broader debate has resurfaced this week as Ben-Sasson also drew attention for a separate, contentious proposal on X: raising Bitcoin inflation to 4% annually. However, his technical case for ZK STARK aggregation rests on a concrete concern—PQ signatures are far larger than today’s ECDSA/Schnorr signatures—and the resulting trade-offs for network capacity and decentralization.

Key takeaways

• Post-quantum signatures are much larger than Bitcoin’s current signature schemes, potentially forcing major capacity changes.
• ZK STARK aggregation could compress many large signatures from a block into a much smaller proof, reducing on-chain data pressure.
• Simply increasing block size is an alternative, but it may raise costs for nodes and revive decentralization concerns.
• Bitcoin’s governance and Script limitations are the main bottlenecks for adding native STARK verification at the base layer.
• StarkWare’s roadmap points to a different approach via account abstraction, making post-quantum upgrades operationally easier on systems like Starknet.

The core constraint: PQ signatures don’t fit like today’s

Ben-Sasson’s argument starts with the mismatch between Bitcoin’s existing cryptographic footprint and the expectations around post-quantum schemes. Adding PQ signatures “by itself,” he says, does not make the chain quantum-safe in a practical sense; it introduces an engineering problem first: the new signatures are orders of magnitude larger.

According to the article, the current set of PQ signatures approved by the US-based National Institute of Standards and Technology (NIST) are roughly 10 to 100 times larger than Bitcoin’s prevailing ECDSA and Schnorr signatures. The practical risk is throughput and verification overhead—one oft-cited concern is that a block could end up supporting far fewer transactions.

Ben-Sasson’s counterproposal is to move the bulk of that data off the chain and replace it with a compact cryptographic statement. In his view, the signatures for all transactions in a block could be aggregated into a single ZK STARK proof, which would be significantly smaller than including the original signatures. That, he argues, could preserve or even improve effective efficiency compared with a naive on-chain PQ upgrade.

“If they don’t allow for ZK STARK aggregation, then definitely it will be a very unfortunate move because it won’t really solve the problem … where the problem is ‘can everyone actually use Bitcoin?’” Ben-Sasson said.

“So for that you need massive scale. And for that, you need things like signature aggregation and just increasing the block size isn’t enough.”

Block size as the “simple engineering” fix—and why it’s controversial

One alternative Ben-Sasson acknowledges, via commentary from other experts, is increasing Bitcoin’s block size. The dispute is not about whether it works—it’s about the cost structure and the governance path.

Marin Ivezic, author of PostQuantum.com and founder of Applied Quantum, told Cointelegraph that Bitcoin’s SegWit scheme reduced the impact of larger signatures by up to 75%. But Ivezic’s modeling of NIST’s ML-DSA-44 scheme (described in the article as having 2,420 bytes per signature) suggests block capacity could drop to roughly 500 to 700 transactions under those conditions—down from 2,500 to 3,000 “today.”

That figure is what makes block-size debates feel inevitable: if PQ signatures drive transaction sizes sharply upward, the network needs somewhere for that data to go. Yet, as the article notes, critics see block growth as a blunt instrument because it pushes more storage, bandwidth, and verification work onto all nodes. Over time, that can mean higher operating costs and potentially less hardware diversity—an outcome that opponents argue could shift Bitcoin toward centralization.

The article also points to Blockstream Research’s recent experiments compressing hash-based post-quantum signature schemes for Bitcoin. It cites SHRINCS and SHRIMPS, with “everyday” signatures said to be around five times larger than current Bitcoin signatures, and up to 40 times larger in recovery scenarios such as wallet resurrection. The implication is that even with compression, larger signatures remain a throughput challenge unless block sizes increase.

“Raising capacity natively is the simple engineering answer and the hardest governance answer,” Ivezic said. “We just don’t have time for those debates.”

Why ZK aggregation could matter more than capacity alone

The attraction of ZK STARK aggregation is not simply that it is smaller. It’s that it changes the economics of what must be stored and verified by nodes.

At a high level, ZK proofs let one side prove that some statement holds without exposing all underlying details. In the Bitcoin setting described in the article, a STARK proof could certify that the necessary conditions for multiple transactions—tied to signatures—are satisfied, without requiring the chain to carry the full set of individual signature bytes.

The operational claim from Ben-Sasson is that generating a proof for a single block is a job that likely needs to be done once (with optional redundancy), and that the proving hardware could be far cheaper than commercial mining setups. The article further notes that verifying proofs could be feasible on very modest devices, pointing to Lean Ethereum’s specification benchmarks—where proving equipment is described as potentially under $100,000 and verification could run on almost any equipment, even something like a Raspberry Pi.

Ben-Sasson also argues the momentum for ZK STARKs existed among early Bitcoin developers. He claimed that figures such as Greg Maxwell and Mike Hearn were “very bullish about ZK STARKs,” citing their belief that STARKs provide post-quantum security without trusted setup. In the article, he adds that he thinks Bitcoin Core developer Luke Dashjr and Adam Back are aligning more with the idea, though Cointelegraph states it did not receive a response from Back.

One complication raised in the article is that Ethereum researcher Justin Drake has described a desire for Bitcoin to adopt Lean Ethereum’s ZK proof aggregation approach. However, political constraints might make that difficult to implement in practice—even if the technical path exists.

What would it take for Bitcoin to verify STARKs?

The question for Bitcoin is less about whether ZK STARKs are cryptographically credible and more about whether Bitcoin can verify them in a practical, acceptable way. That brings the discussion to Bitcoin Script and governance.

The article suggests a more politically pragmatic starting point may be re-enabling OP_CAT, an opcode Satoshi introduced and later removed. Ben-Sasson argues that if OP_CAT is enabled, it could unlock capabilities needed for STARK proofs and aggregation and thereby support post-quantum security.

Still, while OP_CAT drew attention in earlier months (as the article frames it, 12 to 24 months ago), it has “lost momentum” more recently. It remains a governance-dependent path, with Bitcoin’s deliberative culture cited as a key factor.

Beyond OP_CAT, the article mentions other proposals such as OP_STARK_VERIFY, an opcode-oriented idea designed to verify STARKs more efficiently on Bitcoin, and a concept called BitZip associated with Ethan Heilman. Heilman’s framing (as quoted in the article) outlines two broad routes: enhancing Bitcoin with general-purpose opcodes to support rollup-like constructions, or supporting STARKs at the consensus layer. He also referenced weaker aggregation schemes—like CISA (Cross Input Signature Aggregation)—as potential partial help.

Even if the crypto is strong, the practical gating factor is that Bitcoin Script cannot verify STARKs today. The article quotes Ivezic’s assessment that a base-layer STARK verifier is realistically a 2030s governance conversation, noting that consensus-layer changes carry far more surface area than small signature-related opcodes—even ones like OP_CAT that have already faced years of debate.

By contrast, the article highlights that other networks may find post-quantum transitions easier. It notes that Ethereum is targeting 2029 for post-quantum transition and that Solana has experimented with post-quantum signatures. For Starknet specifically, the article ties StarkWare’s three-phase quantum-secure transition to native account abstraction, which allows upgrades of underlying cryptography without forcing every user to migrate accounts manually.

“On Starknet, we have this big advantage that we have already native account abstraction and smart wallets, which means that nothing is enshrined so its very easy to upgrade the wallets and the infrastructure to be post quantum.“

The strategic implication, as Ben-Sasson presents it, is that post-quantum roadmaps on networks without flexible account layers could be “extremely hard,” while Starknet’s design choices reduce lock-in risk.

For Bitcoin readers, the next watchpoints are straightforward: whether any OP_CAT-related or STARK-verification discussions regain momentum, and whether the community gravitates toward aggregation-first proposals that preserve decentralization—rather than defaulting to block-size increases that may raise node burdens. The cryptography may be solvable, but Bitcoin’s ability to verify it at scale hinges on governance and Script capabilities.