How Does a Rollup Prove That It Is Correct?
In the previous article, we asked a simple question:
What happens if a Rollup sequencer lies?
What Happens If a Rollup Sequencer Lies?
A sequencer may process transactions and propose a new state.
But what stops it from simply making something up?
The answer is that a Rollup needs a way to determine whether its proposed result follows the rules.
There are different ways to do this.
Two of the most important approaches are used by Optimistic Rollups and ZK Rollups.
They approach the same basic problem from very different directions.
First, What Does “Correct” Mean?
Before talking about Optimistic or ZK Rollups, we need to define one thing.
What does it mean for a Rollup to be correct?
Imagine that Alice has 10 ETH.
She sends 3 ETH to Bob.
If everything is valid, Alice should have 7 ETH left.
A Rollup processes this transaction and produces a new state.
The question is:
How can we know that the new state follows the rules?
This is the basic problem that Rollup proof and verification systems try to solve.
Two Different Ways to Ask the Same Question
Optimistic and ZK Rollups use different approaches.
An Optimistic Rollup generally starts with the assumption that a proposed result is correct unless it is successfully challenged.
A ZK Rollup takes a different approach:
It provides a cryptographic validity proof showing that the state transition follows the required rules.
The difference may sound small.
It is not.
It changes how the system handles incorrect results.
Optimistic Rollups: Assume It Is Correct
The word “optimistic” gives us a useful clue.
An Optimistic Rollup generally treats a proposed result as correct unless someone successfully challenges it during the relevant dispute process.
That does not mean it blindly trusts the sequencer forever.
There is a period or process during which an incorrect claim can be challenged.
Imagine a sequencer submits:
“The new state is X.”
The system initially treats this claim as valid.
But another participant can say:
“I think this is wrong.”
They can then use the protocol's dispute mechanism to demonstrate that the proposed result does not follow the rules.
This is the basic idea behind fraud-proof or fault-proof systems.
The important point is that the system does not require everyone to prove correctness immediately.
Instead, it provides a mechanism for detecting and challenging an incorrect claim.
Why Would Anyone Check?
This creates another interesting question.
If the system depends on someone noticing a problem, what happens if nobody checks?
The security model assumes that there is an incentive and mechanism for participants to monitor the system and challenge invalid claims.
So an Optimistic Rollup is not simply saying:
“Trust the sequencer.”
It is closer to:
“The sequencer can propose a result, but that result can be challenged.”
This is a very different kind of trust.
ZK Rollups: Show Me the Proof
ZK Rollups take another approach.
Instead of assuming that the result is correct and waiting for someone to challenge it, a ZK Rollup can attach a validity proof to the result.
The proof allows the verification system to check that the state transition followed the required rules.
The name “zero-knowledge” can make this sound mysterious.
But for this discussion, we can keep the idea simple.
The important part is not that the proof necessarily reveals every detail.
The important part is:
The system can verify a cryptographic proof that the computation was valid.
So the basic contrast is:
Optimistic Rollup:
“Assume it is correct unless someone successfully proves otherwise.”
ZK Rollup:
“Here is a proof showing that the result is correct.”
Which One Is More Trustless?
At this point, it may be tempting to say:
“ZK Rollups are better because they prove everything.”
But that would be too simple.
Different systems make different trade-offs.
Optimistic Rollups rely on a dispute process and participants who can challenge incorrect claims.
ZK Rollups rely on generating and verifying cryptographic validity proofs.
Both are trying to solve the same fundamental problem:
How can Ethereum verify that the Rollup followed the rules without processing every transaction itself?
That is the deeper reason these systems exist.
The Sequencer Is Not the Final Judge
Now we can return to our original question.
What happens if a sequencer lies?
The answer becomes clearer.
The sequencer can propose a result.
But the Rollup has another mechanism for determining whether that result should be accepted.
This means the sequencer and the proof or dispute mechanism have different roles.
The sequencer helps order transactions and produce a proposed result.
The verification mechanism helps determine whether the result follows the protocol's rules.
That distinction is important.
A system can allow one participant to perform an important task without giving that participant unlimited authority.
But Does This Solve Everything?
Not necessarily.
A proof can show that a particular state transition is valid.
But that does not automatically solve every problem involving the sequencer.
For example, transaction ordering and censorship can raise different questions.
A sequencer could potentially refuse to include a transaction even if that transaction is perfectly valid.
Depending on the Rollup design, there may be additional mechanisms that help users get their transactions included without relying entirely on the sequencer.
So we should be careful about what a proof actually proves.
A proof of correctness does not necessarily mean:
“The system behaved perfectly.”
It means something more specific:
“This particular result follows the rules being proved.”
That difference is easy to miss.
What Are We Really Trusting?
This brings us back to a bigger question.
People often describe blockchain systems as trustless.
But perhaps “trustless” is not the best word.
In a Rollup, different parts of the system have different responsibilities.
We may rely on a sequencer to order and process transactions.
We may rely on a proof or dispute system to prevent invalid state transitions from being accepted.
We may rely on Ethereum to enforce certain rules.
So perhaps the interesting question is not:
“Do we trust anyone?”
Maybe it is:
“Which actions require trust, and which actions are enforced by the system?”
That is a much more useful question.
Because good system design may not eliminate trust completely.
It may simply reduce the amount of trust any single participant needs.
Conclusion
Optimistic and ZK Rollups solve the same basic problem in different ways.
Optimistic Rollups begin with an assumption of correctness and provide a mechanism for incorrect claims to be challenged.
ZK Rollups use cryptographic validity proofs to show that a result follows the required rules.
Neither approach is simply about making a blockchain faster.
At a deeper level, both are attempts to answer one question:
How can we let a system do work without having to blindly trust the person doing it?
And perhaps that is one of the most interesting ideas behind Rollups.
The goal is not necessarily to make trust disappear.
The goal is to make trust less necessary.
