A Sovereign ZK Rollup on Bitcoin: Full Bitcoin Security Without a Soft Fork
From the emergence of Ordinals to the rise of ZK rollups, 2023 has undeniably been a year of innovation for Bitcoin. While the discussions and developments regarding zero-knowledge proofs have been a significant part of Bitcoin, what truly stands out now is the culmination of developments over the past five years that have made building a ZK rollup, fully secured by Bitcoin, possible.
The chain of events began with the implementation of Bitcoin soft forks: Segwit and Segwit v2 (aka Taproot). These updates made Ordinals possible in 2023 as the capacity of the blockchain to store amounts of arbitrary data expanded. In the midst of these developments, a new type of rollup emerged: Sovereign Rollups. A sovereign rollup is a distinct type of rollup that operates without relying on a settlement layer to establish its canonical chain or set its validity rules. Instead, its canonical chain is defined by the nodes within its peer-to-peer network, ensuring that settlement takes place within the rollup itself, not on a separate layer. A sovereign rollup operates without relying on smart contracts or a settlement layer for its verification processes. This means that sovereign rollups can be implemented on blockchains that don’t support smart contracts, like Bitcoin. Zooming out, we can now see what Chainway is up to. We are combining the developments of the last five years in Bitcoin and the rollup technology to build a ZK rollup that is fully secured by Bitcoin. We are leveraging the Ordinals Protocol to make building a ZK rollup fully secured by Bitcoin possible without the need for a new opcode.
First things first: What is a ZK rollup?
Rollups are a Layer 2 scaling solution, aimed to enhance the transaction capacity of blockchains. In rollups’ design, the actual execution of transactions is shifted off-chain. However, the state root and necessary transaction data is stored within the blocks of a parent blockchain, in this case Bitcoin. This architecture is distinct from other Layer 2 protocols like state channels and sidechains, which largely keep transaction data off-chain.
There are two primary types of rollups: Optimistic rollups and ZK rollups. These classifications are based on the methodologies employed to validate state transitions.
Optimistic rollups operate on an assumption of truthfulness. Every transaction is deemed valid unless an invalid state update is detected. Consequently, the system relies on at least one honest node to be online and watching the rollup smart contract to submit a challenge for potential invalid state updates. This challenge is achieved through a process known as “fraud proof,” wherein the invalid state can be contested within a specified timeframe. While Optimistic rollups work on trust, believing all Layer 2 transactions are legitimate until proven otherwise, ZK rollups use validity proofs to attest to the legitimacy of transactions upfront. By ensuring that only transactions with a valid proof are added to the rollup, the system minimizes trust dependencies and ensures a high degree of security.
The genius of ZK rollups lies in their use of zero-knowledge proofs. The transaction verification occurs through a cryptographic conversation between a prover and a verifier that the prover convinces the verifier of their knowledge without revealing the specifics of the transaction. The information provided between the prover and the verifier is known as the “witness”. The prover must show they possess the accurate knowledge of the witness and the verifier must determine whether the prover truly possesses this knowledge. Through these cryptographic conversations, ZK rollups compress thousands of transactions into a single succinct Zero Knowledge proof that allows instant verification of these transactions. ZK Rollups send only ZK (validity) proofs to Bitcoin as well as some compressed data called state difference. This not only reduces data requirements to be posted on Bitcoin but also ensures swift verification times on the client side.
There are two zero knowledge technologies used for ZK proofs: SNARKs and STARKs. While SNARKs were introduced earlier and have seen widespread adoption, they rely on elliptic curves for security and necessitate a trusted setup. Concerns regarding elliptic curves arise from potential vulnerabilities in side-channel attacks and the looming threat of quantum computing. The trusted setup, as the other limitation, is the initial event where the keys for creating and verifying proofs are formed. A key concern is that if the secrets used to create these keys in this setup aren’t eradicated, they can be exploited to forge transactions, undermining the system’s integrity. STARKs, on the other hand, present distinct advantages. STARKs are technically based on hash functions, as opposed to relying on elliptic curves. This makes them inherently resistant to quantum attacks. Additionally, STARKs eliminate the need for a trusted setup, mitigating potential security risks. Considering the significant security and scalability advantages, we are using STARKs for our ZK rollup.
Now that we have a high level understanding of ZK rollups and ZK proof technologies, we can dive into how Chainway manages to build a ZK rollup fully secured by Bitcoin.
Bitcoin’s First ZK Rollup: Bitcoin Security Without a Soft Fork
Bitcoin is the most battle-tested blockchain and has demonstrated robust security and decentralization with the highest number of nodes compared to other blockchains. Considering Bitcoin’s remarkable track record of consistent uptime and robust resistance to deep reorganizations, it stands out as the most reliable blockchain for anchoring rollup transactions. However, to achieve Bitcoin equivalent security on the sovereign rollup’s native assets, the rollup needs to do more than just using Bitcoin as a data publishing layer.
How can we manage to inherit liveness, re-org resistance and censorship resistance from Bitcoin without relying on a soft fork? The answer is the combination of a sovereign rollup (aka client side validation), recursive ZK proofs and a forced transaction mechanism using inscription-like envelopes.
To guarantee that client-side validation fully inherits Bitcoin’s security, we need to ensure not only recursion in our proof system but also existence and completeness of all previous proofs supplied on the DA layer, Bitcoin. This stems from the fact that light clients cannot determine the correctness or completeness of the initial state without verifying the previous proofs and goes on like this all the way back to genesis. This leads to loss of the light clients’ instant synchronization and verification property. While we manage to verify the full rollup in a single proof with recursive ZK proofs, we are also feeding the rollup state with each Bitcoin block. This is ensured by a mechanism called ‘ValidityCondition’ which checks consecutive block headers. This makes sure that our prover scans every single Bitcoin block, without skipping, and verifies the proofs in circuit. Consequently, our rollup proofs become strictly tied to Bitcoin headers. So far, we have covered how we inherit liveness and re-org resistance from Bitcoin. We still need to explain how we inherit censorship resistance.
The issue of censorship in a rollup stems from nodes called sequencers. Sequencers’ only responsibility is to include the Sovereign rollup’s transactions in rollup blocks. Those rollup blocks are batched together and proved in our zkVM. Then, using Chainway’s Bitcoin DA adapter, this proof with state differences is inscribed into Bitcoin. The sequencers cannot misappropriate users’ funds or initiate unauthorized transactions. This is because the validity proofs attest to the legitimacy of transactions upfront and anyone can verify them. However, there’s a catch: sequencers can potentially censor users’ transactions by not including them in a rollup block. Censorship resistance is what measures a cryptocurrency’s genuine decentralization and its strength to stand against centralized actors. This is the reason Bitcoin was born and this is the reason we are fully inheriting Bitcoin’s censorship resistance.
If for some reason a sequencer censors users’ transactions, users are able to inscribe their transactions directly to Bitcoin and the sequencer has to include them to the rollup block. We are able to do this thanks to zk-STARKs and our forced inclusion mechanism. The sequencer has to supply inclusion and completeness proof for the transactions that were inscribed directly to Bitcoin to the prover. If the sequencer fails to include these forced transactions and corresponding inclusion and completeness proofs, zero knowledge circuit constraints won’t be met and proof generation will fail. To sum up, our zero knowledge circuit is configured to scan every Bitcoin block and include forced transactions as well as previous valid state proofs.
By leveraging the advancements in zero-knowledge proofs, sovereign rollups and Taproot update, it is now possible to achieve a fully secured ZK rollup on Bitcoin without the need for a soft fork.
Through the use of validity proofs, ZK rollups ensure the legitimacy of transactions without compromising on security. The adoption of STARKs as the underlying technology further strengthens the security and scalability of our rollup, eliminating concerns associated with trusted setups and potential vulnerabilities. With the use of inscription like envelopes, we ensure that our ZK rollup fully inherits Bitcoin censorship resistance.
Our approach highlights the importance of being up to date with the latest developments in blockchain and pushing the boundaries of what is possible. The concept of a ZK rollup fully secured by Bitcoin becomes a tangible reality with the successful combination of developments in zero knowledge proofs, Bitcoin, and rollup technology. We are aiming to increase the number of Bitcoin users by providing fast financial applications with low fees, secured by the most valuable block space in crypto, Bitcoin.