Zero-knowledge (ZK) rollups are coming to Bitcoin. Recently, two different projects took turnkey steps into turning this development into a reality for the original cryptocurrency, an advancement that could help Bitcoin scale even more and also provide additional privacy assurances to users that decide to use it.
Chainway last week announced the open-sourcing of their data availability (DA) adapter, a piece of technology that allows developers to leverage Bitcoin’s security and finality to develop rollups with the Sovereign Software Development Kit (SDK). Sovereign provides bundled services for developers to build different kinds of rollups, and Chainway’s launch seeks to enable Bitcoin’s first ZK rollup.
Kasar Labs teamed up with Taproot Wizards to coincidently release a DA adapter for Bitcoin at the same time. The adapter lets developers plug the Madara stack into Bitcoin to run a Starknet-based rollup, leveraging the Cairo programming language created by StarkWare.
Rollups take transactions that are not standard Bitcoin transactions, for example transactions for some sidechain, batch them together and publish it to the block of a baselayer blockchain, like Bitcoin. This reduces dramatically the computational cost of verifying those transactions, while benefiting to some extent from the security of the Layer-1 blockchain. In that sense, rollup transactions live on Bitcoin. Users would then run a node for that sidechain that knows how to interpret the data posted to Bitcoin and build up an account balance. However, this would mean that everyone would need to run a full node of that other protocol –– which is not scalable. This is where the ZK part comes in.
ZK rollups leverage zero-knowledge proofs, a cryptographic proof that ensures computational integrity without compromising privacy. It allows a prover to prove with mathematical certainty to a verifier that a computational statement is correct without revealing details about the specific pieces of information used to compute that proof. This is important in the context of rollups because it lets any observer verify those statements –– or transactions –– by needing to know only the final proof. The use of ZK proofs enables those using the rollup to get proof of the latest state with mathematical certainty from Bitcoin, while retaining complete privacy.
Benefits of ZK rollups include no need for users to be online to receive payments –– only needing to grab payment data on chain when possible, no need for managing liquidity, and it doesn’t depend on low fees on the Bitcoin base layer. Additionally, with a ZK rollup, developers could add any programming environment desired –– for example Turing-complete smart contracts –– on top of Bitcoin.
There are two main mathematical tricks used for ZK proofs: SNARKs and STARKs. The former, Succinct Non-interactive Arguments of Knowledge, predates the latter and is used in cryptocurrencies such as Zcash, providing a great level of privacy to users. Scalable Transparent Arguments of Knowledge were developed later on, and sought to provide better security and scalability on top of the desired privacy. This is because SNARKs rely on a trusted setup to generate the proof, while STARKs aims to be completely trustless –– hence the transparent nudge. Finally, while SNARKs are vulnerable to quantum computing, STARKs are post-quantum secure.
Given Bitcoin’s history of nearly flawless uptime and deep reorg resistance, it is the best suited cryptocurrency to be relied on for rollup transactions, as they rely on the mainchain to access crucial data from which users need to spend. The mainchain also ensures the rollup stays alive and is available.
In order for ZK rollups to be implemented properly on Bitcoin and allow users to trustlessly bridge their BTC to and from the rollup, there would need to be a soft fork to Bitcoin. This soft fork would add a new opcode to the oldest cryptocurrency, making Bitcoin natively aware of and capable of verifying the ZK proofs. If this was to happen, users would need to run only Bitcoin nodes to be able to trustlessly verify the proofs posted by a given rollup, know their accounts and balances, and be able to withdraw from the rollup.
The two projects mentioned in the first section do not make the assumption that there is going to be a consensus change to Bitcoin. Instead, they leverage the Ordinals Protocol to go around the need for a new opcode. More specifically, they leverage the concept of inscription envelopes, an innovation brought about by Ordinals that lets developers and users encapsulate any type of data by using a specific flag and a few opcodes. In the case of Ordinal inscriptions, this flag is “ord”.
The flag at the start of the envelope paired with the opcodes serve a double purpose. First, they let Bitcoin nodes know they can skip that envelope of information, as that’s not relevant to the Bitcoin network. Second, they do the opposite to users and apps aware of that envelope, letting them know something of their interest is there. In the case of the ZK rollups, users are able to scan Bitcoin blocks for these envelopes to know the rollup’s latest state, verifying it mathematically with the ZK proof.
Now that we’re caught up on ZK proofs, let’s go back to the two projects mentioned in the previous section and explore the unique aspects to their design.
The Sovereign SDK itself has three main goals. First, it seeks to provide a standard interface for rollups to communicate with DA layers, making it easier for rollups to deploy on new DA layers and for new chains to support existing rollups. Second, it integrates with cryptographic compilers, converting the code’s business logic into cryptographically verifiable form. Finally, it provides default implementations of common blockchain primitives like tokens, NFTs and bridges.
As mentioned previously, Chainway’s DA adapter aims to make it easier to connect applications built with the Sovereign SDK to Bitcoin. In other words, the adapter lets Sovereign rollups leverage Bitcoin as their DA layer, something that wasn’t possible before. Data availability is crucial for rollups as it allows for trustless verification of computations happening outside the main chain, and is a requirement for users to be able to verify or modify their balances as well as withdraw from the rollup.
In order for Sovereign rollup transactions to be included in Bitcoin blocks, users relay their transactions to what is known as the sequencer. The sequencer, which in the case of Chainway’s DA adapter design is to be ran by the foundation itself, is in charge of making this connection between the sidechain and Bitcoin by making sure all transactions relayed by users get published to Bitcoin with ZK proofs.
That sounds a bit centralized, and it is. However, given the presence of the validity proofs technology –– ZK-STARKs –– there is little the sequencer can actually do to act maliciously. This is because the proofs privately confirm the legitimacy of the transactions and anyone can verify. The sequencer cannot misappropriate user funds, for example, nor can they perform unauthorized transactions. But they theoretically can censor users’ transactions by not including them in a Bitcoin block and withholding that data. If this happens for some reason, the user has the option to post their transaction data to Bitcoin themselves by inscribing that information to Bitcoin.
In the future, Chainway says they plan on enabling decentralized sequencing through a small network of sequencers, where participation will be permissionless and based on staking.
Similarly to Sovereign, Starknet also seeks to allow the buildout of rollups. However, Starknet is a much more opinionated ecosystem, with clear components of which developers leverage to build on top, including Cairo, CairoVM, and Madara.
Starknet is a ZK rollup currently operating on top of Ethereum, meaning that the rollup relies on the blockchain created by Vitalik Buterin as its DA layer. It leverages STARK proofs to provide the privacy and security assumptions needed for users, as well as the increased scalability and lower transaction costs through the batching of transactions before publishing the proof and new state to the Layer-1.
Cairo (CPU Algebraic Intermediate Representation) is Turing-complete programming language for writing provable programs, where one party can prove to another that a certain computation was executed correctly without the need for this party to re-execute the same program. It is the first production-grade platform for generating STARK proofs for general computation.
The Cairo Virtual Machine (VM) takes the bytecode produced by the compiler, and runs it on a computer. The output of this run is the trace of the program which can then be sent to a STARK prover in order to prove the validity of the statement expressed in the Cairo code.
Madara is a sequencer for the Starknet stack, helping developers power their Starknet-based ZK rollups.
Up until recently, all this software stack could only be used on top of Ethereum. Now, Kasar Labs and Taproot Wizards have launched a DA adapter for Bitcoin that seeks to allow developers to anchor rollups built with an open source version of Starknet to the original and most secure cryptocurrency network.
Inherently, Bitcoin doesn’t need much. It arguably works very well the way it is today, and there is little argument for why Bitcoin needs to change dramatically to continue solving the double spend problem as an electronic cash system. On the other hand, scaling is a real need, and things such as the Lightning Network have proven very useful in allowing greater participation from users that could otherwise not be able to partake in economic transactions with bitcoin.
ZK rollups provide an alternative lens through which to look at Bitcoin. The two projects listed above don’t demand any actual change from Bitcoin itself to work, but if the full capabilities of this technology were to be actualized, a consensus change would be necessary to introduce a new opcode. For now, it seems this research into the zero-knowledge based rollups space is attempting to push the boundaries of what’s possible to do with bitcoin –– a good thing if the goal is to, similarly to the Lightning Network, increase the possible pool of Bitcoin users.
The parallels drawn with Lightning are evident, given that rollups also function by batching several transactions together before publishing a single source of information to Bitcoin. Certainly, ZK rollups take a very different approach than Lightning, and rightly so. The technology doesn’t seek to compete with the tried and tested cheap payments Layer-2 that Bitcoiners have grown to love. Rather, rollups look at other problems, and attempt to devise other solutions.
Another scaling technology for Bitcoin that eventually enables private, complex computations that relies on mathematical proofs sounds appealing for those who seek to do more with their bitcoin. Again, the ability to bridge BTC fully trustlessly in and out of the rollup would depend on that opcode. But even so, the idea is there.
It is unclear whether ZK rollups would gather any traction on Bitcoin. There already is a sidechain to Bitcoin. Liquid has been active on Bitcoin for years, and it has yet to see huge transaction volumes. It could be argued that the presence of a federated model in the case of Liquid is a liability, and ZK rollups take the edge on this case. Perhaps a rollup could see the same fate as Liquid, low volume and low interest –– as Bitcoin users continue to choose to simply “stack sats and HODL.” Or it could enable a new frontier of Bitcoin development and use.
Nonetheless, exploring these developments with high quality research is both a natural and necessary endeavor, regardless of whether the end result is success or failure. There is something to learn from either outcome. In either case, one thing is certain –– Bitcoin will continue hashing and producing blocks, allowing all its users to enjoy the monetary certainty of hard money and not caring about any of this. Such a beautiful thing.
Blog powered by G6
Disclaimer! A guest author has made this post. G6 has not checked the post. its content and attachments and under no circumstances will G6 be held responsible or liable in any way for any claims, damages, losses, expenses, costs or liabilities whatsoever (including, without limitation, any direct or indirect damages for loss of profits, business interruption or loss of information) resulting or arising directly or indirectly from your use of or inability to use this website or any websites linked to it, or from your reliance on the information and material on this website, even if the G6 has been advised of the possibility of such damages in advance.
For any inquiries, please contact [email protected]