Clearing up misconceptions on Citrea
A somewhat unbiased opinion on how we should define rollups...
Good afternoon Insiders. Today, admittedly, I’m double dipping. I’ve been thinking a lot about rollups and their supporting architectures since the start of the OP_RETURN war. So today’s post further expands on a tweet I previously wrote about Citrea’s state transition function.
In case you forgot (you didn’t, but just in case), bitcoin twitter sent Citrea through the wringer due to their impending use of OP_RETURN for their BitVM challenge transaction. It was the genesis of the Core versus Knots war. Everyone was up in arms about arbitrary data being posted to bitcoin. Some complained and suggested Citrea just use Liquid and others accused bitcoin core of “pathing the way for bitcoin rollups”.
Through all of this, it became clear to me that people, from both sides of the aisle, had misconceptions about how Citrea works. So, I decided to review their node implementation and state transition function. Buckle up, we’ve got a few things to cover.
Rollups
Rollups are alternative blockchains that apply their state transition function over data that is posted to bitcoin and made available by bitcoin full nodes. This means they use bitcoin for data availability. Rollups do this so they do not have to bootstrap their own consensus set. Anyone who runs a bitcoin full node can run a rollup full node, query bitcoin blocks, find transactions relevant to the rollup, and derive the entire state of the rollup, from genesis, to come to settlement with other rollup nodes.
Wars have been long fought over defining rollups from the lens of the bridge or the rollup itself. There are two camps. One says you should solely define a rollup based on which data availability layer it uses; for example, a rollup that uses bitcoin for data availability would be a “bitcoin rollup”. The other side says you should additionally classify rollups through the lens of the bridge. That’s why you hear the terms “zk rollup” or “optimistic rollup”. People are adding an additional word to distinguish the rollup based on the bridge that users socially view as the canonical one.
Bitcoin has further confused everyone with teams’ claims that bitcoin rollups are “optimistic zk rollups” even though they’re really neither of these things. Rollups are rollups. Bitcoin rollups are bitcoin rollups.
Why does the distinction matter? When you view rollups as a system that “verifies its state on bitcoin”, you’re led to believe that bitcoin is enforcing the logic of another system. This is not the case. The logic of the alternative system is enforced by its full node set which effectively makes rollups alternative blockchains.
Bitcoin does not enforce state transitions related to rollup systems. Bitcoin is incapable of doing this and is completely unaware of the rollup’s state. To bitcoin, the data that the rollup posts to bitcoin is arbitrary data that needs to be interpreted by another set of nodes and software.
Bitcoin does not enforce rollup state transitions and rollups do not inherit bitcoin’s double spend resistance. For rollups, bitcoin is the data availability layer that sees rollup nodes to derive their state from bitcoin and gives rollup nodes an ability to enforce finality based on the data posted to bitcoin.
When I created the first community site dedicated to bitcoin rollups (now offline), I looked at rollups through the lens of the bridge… which was wrong.
So we’re using this blog as a summary of my past writing to describe, again, how bitcoin rollups actually work using Citrea as an example.
Looking at Citrea’s state transition function
We’re going to break down a previous tweet I wrote on Citrea’s state transition function to show how the rollup comes to “settlement”. Settlement is when the rollup nodes agree on the proposed state transition from the rollup operator and finalize a state update. Additional commentary is italicized.
Citrea is a bitcoin rollup. This means that it uses bitcoin for data availability. It is live on testnet and is approaching mainnet.
To advance Citrea's state, like any blockchain, a state transition function is applied over the network's previous state to generate a new state. This is how it works in Citrea:
A state transition function is a set of logic that rollup full nodes apply over a set of proposed transactions. This means they execute the transactions. If the proposed transactions are valid, then all full nodes will additionally be able to execute them and finalize the state update for the rollup.
Citrea's users submit transactions to a sequencer - an offchain node that is responsible for preemptively ordering transactions and submitting them to bitcoin on behalf of users.
A sequencer is an enshrined node that is responsible for ordering transactions for the rollup network and submitting the transactions as a “compressed batch” to bitcoin. The order of the transactions is not finalized until it is posted to bitcoin. Citrea full nodes consider the transactions “preconfirmed” before they are posted to bitcoin.
As the sequencer constructs these L2 "blocks" offchain, Citrea's full nodes need to agree on the state that the sequencer is proposing. To do this, they connect to the sequencer directly, offchain, receive blocks, and execute/apply the state transition function over the transactions. This means they execute all of the proposed transactions that have been sent to the sequencer. After all of the nodes do this, a new state root is generated.
Periodically, the sequencer posts a commitment transaction with the latest generated state root. This commitment transaction attesting to the most recent state in Citrea, highlighting the differences in the previous state and new state. Full nodes additionally watch bitcoin to ensure that the commitment transaction, in fact, matches the most recent state they generated locally.
After Citrea full nodes verify that the state root in the sequencer commitment matches the one that they generated locally, they consider the state confirmed. This enables the rollup full nodes to come to “settlement”. For new nodes, it enables them to derive the entire history of the rollup from genesis.
The Citrea prover watches these commitments and computes the state differences between each commitment. If valid, it posts proofs of execution to bitcoin. After these proofs are posted, the rollup is considered final from the view of light clients (i.e. bridges). Citrea full nodes are also able to detect any errors in proof submission.
After the proof is submitted to bitcoin, Citrea full nodes view the state as “proven”. The state cannot be reversed at this point.
If the sequencer commitment, or proof submission, was invalid, the network would halt. Additionally, the prover cannot generate an "invalid proof" per se, so any light clients would not finalize as a result. So if the sequencer posted "malicious" data, the network would freeze (as would corresponding bridges).
This means that the sequencer does not enforce settlement/finality of transactions. A sequencer that posts an invalid batch of transactions would halt the system. The rollup nodes, who drive the finalization of the network, would not be able to execute invalid transactions. This means that the sequencer cannot force the rollup nodes to come to settlement on a state update they do not agree to.
Citrea full nodes do not need to keep a full history of this state as the data required to construct the state of Citrea is made available by bitcoin. After the commitments match the locally state generated, Citrea nodes discard the data. If a node went offline, they could sync their node directly from the data made available by bitcoin.
Rollup nodes do not need to keep a full record of the network state as the data is made available by bitcoin full nodes. If a rollup node went offline, they would catch up to the rollup network’s state based on data made available by bitcoin.
And by anchoring its state to bitcoin through SNARKs, Citrea is also able to provide a mechanism to convince bridge programs of the state of the rollup. Thus, finalizing them and giving them the ability to execute withdrawals based on the most recent state of Citrea.
This is the bridge part. Notice that it has nothing to do with rollup settlement and finality! The bridge is an external program that is convinced of the state of the rollup to process user withdrawals. It is a bitcoin contract that needs to be convinced of an argument to execute withdrawals. Remember, bitcoin cannot enforce the rollup state. So the bridge does not enforce the finality of the rollup system. Rollup nodes hold all the power!
Sounds complicated… Why build this?
It might sound complicated, but rollups are actually very simple. Look at it this way - there’s node software that dictates the rules that transactions need to abide by. If the proposed state contains valid transactions, then the full nodes can compute a new state by executing them. That’s it! It’s really how any blockchain works.
Still, bitcoin is really limited in throughput. It doesn’t make much sense, at a high level, to try and cram a bunch of rollup transactions into bitcoin blocks. Why do this?
Bitcoin is the “forever chain”
If you believe bitcoin is the forever chain, meaning that people will always run bitcoin full nodes and be able to make bitcoin transaction data available to other users, including rollup users, then it might make sense to post your systems data there for security reasons 🤷
This is useful for rollups who want to have an extremely strong (some say too strong) guarantee that their data will indeed be made available as long as bitcoin is running.
Rollups can build really good bridges
Okay… now, while bridges don’t directly enforce finality for rollups, rollups can build really good bridge protocols. People want improved bridge protocols so they can move funds into another system for more expressive applications. A lot of developers want to build these applications. Rollups look to satisfy this demand by offering the “best” sidesystem bridge protocol with the least amount of trust assumptions.
But how do they provide this? Let’s break it down:
Not reliant on the economic security of another system
If a rollup posts data to another system, and is therefore a rollup to that system, then we’re reliant on that system’s validators/full nodes to make the data available to rollup nodes to advance the rollup state. If there’s a lot of economic activity on this rollup, and subsequent value locked in its corresponding bitcoin bridges, the data availability layer may want a piece of that! The attack vector here is that the data availability layer withholds the data and doesn’t make it available to rollup full nodes. Without the data, the rollup would effectively halt and the data availability layer could hold the rollup at ransom.
If you post the data to bitcoin, this attack vector is invalid. That’s why bitcoin rollups are considered more secure than rollups to other chains from the lens of a bitcoin user.
Yes, I know you can socially hard fork the alternative DA layer and slash the malicious validators tokens if they did this. But you cannot deny it is an additional trust assumption and would cause quite the headache!
Light clients!
Bridge programs on bitcoin need to be aware of the current blockheight and blockhash, of a given sidesysten, to facilitate withdrawals. This is where a light client, a small program that tracks the blockheight and blockhash but not the full contents of blocks, is useful. A light client is responsible for relaying the latest blockheight and blockhash to a smart contract.
Bitcoin script is not expressive enough to execute a light client in an onchain smart contract. This is why we use BitVM - to execute a bitcoin light client that attests to the current state of the rollup. Because rollups post their transaction data to bitcoin, they only need to execute a bitcoin light client in their BitVM instance. This light client also attests to the sidesytem state root for that given bitcoin blockheight.
If the BitVM bridge is for another system, it must also execute light clients for the other chains. For example, if the BitVM bridge was between a sidechain and bitcoin, then the bridge must also execute a sidechain light client. This light client would follow the sidechain fork with the most economic weight behind it and view it as the “correct” chain.
Sidechain validators could be malicious! If a majority of validators created a private fork that attested to a malicious state that would see the bridge drained, then the BitVM challenge game would be invalidated. This is because the sidechain light client, in this instance, thinks that the malicious state is correct, as the malicious fork has the most economic security behind it.
This sees the bridge rely on a honest majority assumption from that systems’ validators, or a federation, to provide an honest attestation for the alternative chain’s latest state.
Because of this, rollups can build bridges that have fewer trust assumptions than sidechains.
One day… self-proposed exits
I don’t know how this would work on bitcoin, but theoretically, a rollup user could bypass the system's enshrined sequencer node and go directly to a bridge operator to facilitate a withdrawal. As long as 1 bridge operator is willing to work with the user, then the user can exit this system. Teams will argue (rightly) that this enables a users to bypass the rollup operator(s) and rely on the trust assumptions on the bridge alone if they wanted to get their money out. Citrea has designed this.
But… rollups can have many bridges!
Just because a rollup can have a more secure sidesystem bridge from BitVM doesn’t mean it’s going to be the only bridge! There’s no reason that a rollup can’t simply use a federation for its bridge program. It kind of defeats the whole reason to build a rollup, but you could still do it.
Al fin
That’s it! Rollups on bitcoin can be the most trust-minimized sidesystem. They are sovereign systems that use bitcoin for data availability. This enables the rollup full nodes to come to settlement without having to bootstrap their own consensus set, and it lets them build really good bridges if they want to use bitcoin, the asset, on their system.
Of course, this is all theoretical. In practice, bridges and other supporting infrastructure will have their own trust assumptions so a lot of the security assumptions for a user are asset specific. It’s important to analyze these trust assumptions in isolation of the rollup.
If you think anything I said here is wrong, @ me on twitter. This is a hill I’m willing to die on :)
–Janusz