# ZKrollups on Bitcoin - notes

At the end of August, a bunch of researchers got together in Palo Alto to discuss how one would implement ZKrollups/ZKPs on Bitcoin.

I set the tone for the meeting:

“The problem with getting a ZKrollup into Bitcoin… is that we have to commit to a single opcode to verify a ZKP with. It’s not like in Ethereum where you can have hundreds of different zkrollup L1 contracts, each with their own upgrade logic, and evolve over time. We basically have to enshrine a single zkrollup proving system into the base-layer itself, and any new upgrade to that would mean a whole new softfork, and consensus on that. The problem is of course that we don’t quite know which proving systems we want to enshrine or which polynomial commitment scheme it should adhere to, let alone which zkVM we want to prove (for people who are outside the ZK domain, this is a discussion around which cryptographic primitives are best and there’s a lot of… politics... involved, because these choices have consequences).”

Members of the StarkWare team were there, and while there are many merits to Cairo and the CairoVM (a VM/language specifically designed to be zero-knowledge-proven), there isn’t any form of consensus within the ZK community that the CairoVM is the most ideal thing either. For example, some ZK researchers have a preference for zkVMs coming out of the Polygon research teams, like Valida — the LambdaClass team that implemented several of the most high-performant parts of the Starknet stack themselves has recognized that Polygon has basically iterated upon the work of StarkWare with their latest VMs and made it better, although there are advancements coming out of StarkWare that are likely to be better than even that…

Meanwhile, if the goal with a ZKrollup isn’t just scaling or to provide an expressive language for DeFi apps, but rather for things like privacy, there are other VMs like Miden that have catered for privacy in ways that the CairoVM has not in its current form. There’s simply not a one-size-fits-all in the world of L2 zkVMs!

So how is the Bitcoin community ever supposed to reach consensus on a enshrining a specific zk-verifying opcode, when the ZK community itself is not in any way in consensus on what type of zkVM would be ideal for Bitcoin for the next year, let alone the next 5 or next 100 years? It is simply not the behavior of Bitcoin to activate any opcodes at all, unless they act as lasting fundamental building blocks for the future. And even if we did try to do such a thing, the technical conversation would get bikeshedded into infinity. I left the meeting feeling less optimistic about ZKrollups on Bitcoin than ever before, recognizing how difficult it would be to get this idea into a compelling technical proposal.

#

Then, later, in Hong Kong, I met two researchers (NEAR, Cosmos) who proposed a very different but also a way more obvious idea on how to approach the problem (now in retrospect it feels stupid that we, the group in Palo Alto, could not think of this immediately ourselves—this being probably entirely my fault for framing the conversation in the way that I did).

Of course we should not focus on enshrining a single zkVM into the Bitcoin protocol and implement an opcode just for that!

Here’s what the researchers proposed:

We need a verifier and a prover for a general purpose VM (like WASM), and that is what we enshrine/softfork into the Bitcoin protocol. Then we can verify any ZKP for any zkrollup; Miden, Cairo, Valida—if you can succinctly verify the WASM VM you can write verifiers *in* WASM that verify ZKPs for all these other VMs—you would not have to commit to a single one. All we would have to commit to is verifying WASM.


Now, there is still some complexity in choosing the verifier/prover for WASM itself. Should it be FRI or KZG-based?

*Slide from Eli Ben-Sasson's presentation at the Stanford Blockchain Conference, August 31, 2023.*

Now, while there's substantial support for STARK/FRI within the L2 community at this point, it's not the purpose of this note to get into the politics of that. I'll just leave it at saying it is a good fit for the culture of Bitcoin, as it requires no trusted setup, no "ceremonies", the underpinning cryptographic assumptions are surprisingly non-exotic and well-understood (it's basically just hashes, from a cryptographic PoV, STARKs are less exotic than ECDSA itself).

*Udi, as usual, he understands nothing.*

The purpose of this note is to promote the realization that in order to avoid endless politicking, a provable WASM VM middle-layer as the enshrined ZKP makes more sense from a backwards-compatibility PoV than any single other zkVM. It provides us with a lot of optionality for the future, and should mitigate the risks with doubling down on a specific ZK-path for Bitcoin.

Upon sharing this insight, [LambdaClass shared today that they'll devote resources to build a STARK-provable zkWASM using Cairo](https://twitter.com/fede_intern/status/1704381847717937226).

Actually trivial!