S15 E36: Eli Ben-Sasson on STARKs, Rollups & Privacy
The audio keeps playing while you browse the site.
Ask the Archive
In May 2013, a computer scientist walked onto the stage at the Bitcoin conference in San Jose and made a promise to a room that included Greg Maxwell and Mike Hearn. One day, he said, you will fire up your Bitcoin node and skip the whole ritual of replaying every block since Genesis. Instead, "you will download a proof and verify it," a proof "less than one megabyte long" that checks out "in less than a second on your laptop."
That computer scientist was Eli Ben-Sasson. Eleven years later, almost to the day, he joined me live on Twitter and YouTube as the co-founder and CEO of StarkWare, a co-founder of Zcash, and the man who coined the word STARK. The promise from San Jose is still unfulfilled on Bitcoin. Not because the math is missing, he argued, but because the culture is. That tension became the backbone of a wonderfully nerdy hour.
Two Faces of a Zero-Knowledge Proof
I started with the basics. What is a zero-knowledge proof? Eli's definition: a proof in which "you learn that a statement is correct" without learning the secret data behind it. His example was the classic bouncer test: proving "my age is over 21" without handing over your ID.
Then he flipped the coin. There is a second, less glamorous side to these proofs, which deals with "very fast verification of the integrity of a computation." Most people fixate on privacy, and he took some of the blame for that. He and his co-authors on the Zerocash paper popularized the tech through "the privacy angle," but there is also "a succinctness and scalability aspect" that can compress gigantic computations into tiny receipts.
"If Bitcoin Says Yes, I Promise You"
How far are we from that 2013 vision? Closer than you'd think. "You can already verify hundreds of gigabytes of data in less than a second," Eli said, and StarkWare has been doing exactly that in production since the summer of 2020. The catch is that none of it runs on Bitcoin, because Bitcoin nodes do not verify STARKs as part of consensus.
He was crystal clear on where the bottleneck lies. "The technology is out there," he said. It is a question of whether Bitcoin consensus is willing to allow "the implementation of a STARK verifier on Bitcoin nodes." And then came the pledge: "If Bitcoin says yes, I promise you that tomorrow, a lot of the engineering resources" at StarkWare and in the Starknet ecosystem "will be dedicated to doing this very thing that I spoke about 11 years ago."
He called himself an outsider who does not feel comfortable "even advocating for the speed at which it should be adopted," but he still hopes "Bitcoin with all its conservatism" warms up to it, with OP_CAT as one possible door.
OP_CAT, Hash Chains and the Hacky Way In
So is OP_CAT enough? Eli saw it as "the bare minimum that would allow you to just sneak through the door." When I asked about OP_CAT versus OP_CTV, he admitted he did not know enough to give "an informed answer." Fair. As someone who spends way too much of his day reading Bitcoin debates, I told him CTV seems to have broader support while OP_CAT has the louder fans.
What he does know is exactly what a STARK verifier needs. Two ingredients: "32-bit addition and multiplication, modulo prime," plus "basic verification of hash chains" with "a very small amount of state." Computers do this stuff millions of times a day, and he described it as "really something that is very safe." With OP_CAT alone, you can get there, but "in a very hacky roundabout way." His wager: Satoshi would have approved of the cleaner version.
StarkWare has already put money where its mouth is, funding and discussing research into STARK verifiers on Bitcoin, including work by Robin Linus and the ZeroSync team. As Eli put it with a grin: "I'm a STARK maxi, I would like to see it everywhere."
SNARKs vs STARKs: A Venn Diagram Named After Game of Thrones
This was the section where I nearly needed a whiteboard. Eli described SNARKs and STARKs as "a little bit like a Venn diagram." A SNARK requires very short verification and no back-and-forth, but it tolerates a scary setup phase in which "some secret key that can ruin everything if it's revealed is baked into the protocol." That's the infamous toxic waste.
A STARK keeps the succinctness but demands more: proving time "nearly linear" in the size of the computation, and exponentially faster verification. Crucially, no trusted setup. The SNARKs used on Zcash are "snarks that are not STARKs because they require a trusted setup," they are also exposed to quantum attacks and rest on number theory assumptions that he feels "less comfortable with." Meanwhile a commit-and-wait scheme on Bitcoin, using the next block header as randomness, would be a STARK that is not a SNARK. Starknet's production proofs sit in the overlap.
I said it sounded like poetry. Turns out it was on purpose. "I coined the term STARK," Eli said. He liked the sound, and he "was also reading Game of Thrones at the time." Winter is coming, and so is succinctness.
From the PCP Theorem to Zcash to StarkWare
Eli's road to industry began in academia. Around 2008, he started implementing cryptographic constructions based on the PCP theorem (Probabilistically Checkable Proofs). The San Jose talk in 2013 was "the moment I was red-pilled for Bitcoin," and from then on he tried to apply this theory to real blockchains.
He counted three attempts. The first was Zerocash, an academic paper about adding privacy to Bitcoin. The sad realization: getting it on Bitcoin "would involve a lot of politics and social consensus," and "11 years out, it still is not possible to do Zcash transactions on Bitcoin." Toxic-waste SNARKs were also "very much not in line with what Bitcoin is about."
So he co-founded Zcash as its own coin. A second commercial attempt fizzled after a year and a half. Then, in 2018, math breakthroughs like the FRI protocol and STARKs convinced him to try again, this time selling the scalability side. "Everyone today talks about how ZK rollups are the end game for scaling blockchains," he said, but StarkWare was the first to build a company around the idea.
For more on the Zcash side of this family tree, check out my S16 E29 conversation with Zooko.
Peter Todd's Laptop and What Happened to Zcash
Confession time: I own Peter Todd's laptop from the first Zcash trusted setup ceremony, the one Edward Snowden also took part in. I waved its remains on the livestream. Eli congratulated me on owning "a relic from this very important ceremony," while pointing out that this kind of ritual is exactly what you no longer need "with protocols that are transparent," like STARKs and Halo 2.
So why didn't Zcash take over, and why do privacy fans still pick Monero? Eli blamed user experience. Making a shielded transaction on Zcash is "even much harder in terms of UX and UI" than using a Ledger or Trezor on Bitcoin. "We all need privacy" in our finances, he said, "it's just that the UX and UI are very hard to get right."
I gave Zcash credit for kicking off the conversation that later led Ethereum toward rollups and inspired Bitcoin projects like Citrea and Build on Bitcoin. Eli agreed that the ZK approach beats the old dream of trustless sidechains, and he is enjoying the victory lap: after years of "walking in the desert" and "spreading the gospel," validity proofs are now "the gold standard and everyone accepts it."
Quantum Computers and Why Risk It
On quantum computing, Eli avoided doom predictions and went for pure risk management. "If you have a technology that is safer, why risk it?" He does not know whether a quantum computer will break Bitcoin in the next 20 years, but STARK-based tools can replace both signatures and scaling schemes so that if one shows up, "nothing breaks." Post-quantum signatures built on STARKs can also be aggregated "very, very efficiently using recursive STARKs."
He went further than most. Plenty of leading mathematicians, including number theorist Peter Sarnak, believe integer factoring might one day be done in polynomial time on classical computers. Eli shares the hunch: "I also believe that we will be able to factor in polynomial time" much better than today, "in our lifetime." So even without quantum machines, existing systems could crack.
The Block Size War Returns (Sort Of)
I brought up the block size debate, which was flaring up again. Eli said that with an "OP_STARK" opcode, "you would have, again, a thousand fold increase immediately in the TPS without any change to the block size."
Then the outsider spoke candidly. "Here the conservatism has gone just a little bit too much," he said. Storage and bandwidth have grown maybe 10x or 100x since 2008, so he believes Satoshi would have supported "a moderate increase" in capacity. He added that Greg Maxwell, Mike Hearn and Gavin Andresen wanted STARK verification back when they were active, and that he thinks Andrew Poelstra, Ethan Heilman and Pieter Wuille are supportive too. "It's just the culture that changed."
Robin Linus Asks About Data Availability
Robin Linus, creator of BitVM, sent me a question for Eli: what about data availability of the state differences? Eli called it "a very good question" and built a thought experiment. Imagine Bitcoin had an OP_STARK and proofs cost nothing. You could validate a billion transactions, but the UTXO set changes still need to be published, and that "probably would have been much more than one megabyte."
There are escape hatches. If Alice makes a chain of one billion payments, the state diff boils down to a single UTXO change. For the realistic case, Eli offered two answers: a moderate block size increase, and alternative data availability modes like Validium, which StarkWare has run in production for close to four years. Users choose between full Bitcoin-grade security or cheaper storage kept by a smaller set of nodes. He'd settle big things like buying a house on chain, and keep "day to day interactions" on Validium.
"Integrity Should Never Be Assumed"
I asked how StarkWare pulled off such a big raise with such deep-pocketed backers. Eli rejected the founder-misery genre. While others compare startups to chewing glass, his experience has been "pure joy," thanks to "amazing giga brains" sharing one vision, which he said is also Bitcoin's: "integrity should never be assumed. It should always be demonstrated publicly for all to verify."
He admitted that academic friends gossiped behind his back about him "wasting" a decade turning math theorems into code. The last laugh is his.
Starknet, Cairo and the Stark Name Game
For users, Eli said the best demo is to download a Starknet wallet. Thanks to native account abstraction, wallets like Braavos and Argent let you secure keys with smartphone biometrics, or "the Bitcoin way" with secp256k1 signatures. Starknet itself is a permissionless, Turing-complete layer two settling on Ethereum, and its smart contracts are written in Cairo, which he described as "Rust inspired, ergonomic, safe."
His advice to bitcoiners: "go look at Cairo." If STARKs ever arrive on Bitcoin, StarkWare "will definitely pursue it," and Cairo devs will be ready. He also highlighted the next-gen prover built on 31-bit integers over the Mersenne prime, the new Circle STARKs paper by Ulrich Haböck, David Levit and Shahar Papini, and binary field work like Binius from Irreducible.
Then we had fun. Should Elizabeth Stark of Lightning Labs work on STARKs? "It's in her name," Eli laughed, and he'd "be happy to collaborate." He told me he once said the same to Zooko, who changed his name years before co-founding Zcash. Still, the Z came from Zerocash, not Zooko.
We ended after someone in the chat called us scammers, which is the crypto equivalent of a standing ovation. About 1,600 people tuned in live, and I still think more Bitcoin podcasts should cover this stuff. If Bitcoin ever says yes, Eli has already promised to show up.
Listen to Eli Ben-Sasson on Spotify, Apple Podcasts, YouTube, and More
Time stamps:
00:00:35 - Introduction to the Podcast 00:02:03 - What is a Zero-Knowledge Proof? 00:04:09 - Vision for Bitcoin Node Synchronization 00:05:44 - Current State of Zero-Knowledge Proofs 00:06:38 - Challenges in Implementing Zero-Knowledge Proofs 00:09:19 - Importance of OP_CAT Opcode 00:12:04 - Comparison of OP_CAT and OP_CTV 00:13:13 - Differences Between SNARKs and STARKs 00:17:47 - Popularity of SNARKs and STARKs 00:19:52 - Eli's Journey to StarkWare 00:23:50 - The Future of Zcash 00:24:17 - The Importance of the Zcash Ceremony 00:24:38 - User Experience Challenges with Zcash 00:26:13 - Impact of Zcash on Zero-Knowledge Proofs 00:27:03 - Scaling Solutions: Sidechains vs. Rollups 00:27:20 - STARK Technology as a Gold Standard 00:29:19 - Quantum Computing Threats to Bitcoin 00:31:55 - Proactive Measures Against Quantum Threats 00:32:25 - Benefits of STARKs Beyond Quantum Security 00:33:34 - Resurgence of the Block Size Debate 00:34:15 - Future of Bitcoin with STARKs 00:35:12 - Cultural Shift in Bitcoin Development 00:37:02 - Data Availability in Blockchains 00:40:34 - Scalability Solutions and State Differences 00:42:33 - Founding StarkWare: Joy and Challenges 00:46:02 - Drivechain and STARK Integration 00:47:02 - Efficient Operations for STARKs 00:48:22 - Bitcoin's Conservative Approach 00:49:55 - Integration with Bitcoin 00:51:00 - User Experience with STARKs 00:53:43 - Understanding StarkWare and Starknet 00:54:49 - Starknet's Features and Capabilities 00:56:11 - Opportunities for Bitcoin Enthusiasts 00:58:56 - Potential Collaboration with Elizabeth Stark 01:01:20 - The Future of STARKs 01:04:29 - Following Starknet and StarkWare
Verify this episode
This is the SHA-256 fingerprint of the MP3 as published here, timestamped in the Bitcoin blockchain with OpenTimestamps. If one byte of the file changes, the fingerprint changes.
- SHA-256
2a499cedf06749f387d49cce2e736ca19e7106e37f4b2f177e1997f3f76d1f82- Proof
- 2024-05-23_s15_e36_eli_ben-sasson_on_starks_rollups_privacy_-_23.05.2024_01.18.mp3.ots · all episode hashes (proof)
- Status
- Anchored in Bitcoin block 974,312
How to check it yourself
- Download the MP3 and the proof into the same folder.
- Run
sha256sum 2024-05-23_s15_e36_eli_ben-sasson_on_starks_rollups_privacy_-_23.05.2024_01.18.mp3(on a Mac:shasum -a 256 2024-05-23_s15_e36_eli_ben-sasson_on_starks_rollups_privacy_-_23.05.2024_01.18.mp3). The result must match the SHA-256 above. - Install the OpenTimestamps client (
pip install opentimestamps-client) and runots verify 2024-05-23_s15_e36_eli_ben-sasson_on_starks_rollups_privacy_-_23.05.2024_01.18.mp3.ots. It hashes the MP3 again and checks the proof against your own Bitcoin node, then prints the block and the date the file existed by. Without a node,ots info 2024-05-23_s15_e36_eli_ben-sasson_on_starks_rollups_privacy_-_23.05.2024_01.18.mp3.otsshows the block height to look up in any block explorer.
Related
S15 E58: Liam Eagen, Robin Linus & Jonas Nick on Shielded CSV, Private Client-Side Validation & the Future of Bitcoin Privacy
Liam Eagen, Robin Linus and Jonas Nick explain Shielded CSV: private client-side validation with ZK proofs, BitVM bridges…
S15 E57: Orkun Kilic on Citrea, ZK Rollups & Building the Bitcoin Economy
Days after the Citrea testnet launch, Orkun Kilic explains ZK rollups vs sidechains, BitVM's trust model, drivechains, StarkWare…
S17 E22: Jeremy Rubin on CTV, Char & Relentless Building in an Adversarial Environment
Four years. That is how long I have been chasing Jeremy Rubin for an interview, and it took the Bitcoin 2026 conference…
Comments
Comments run on my own server. No ads, no trackers.