What makes a blockchain real?
Is it the execution of transactions? The data availability layer? The ZK proofs flying around? Or is it something quieter, something that simply says, “Yes, this happened. It’s final and verified by everyone. You can build on top of it now.”
We’re living in a world where everyone is building their own chain. Ethereum pushes a rollup-centric roadmap, where L2s are the future. Avalanche has Subnets and now even Avalanche9000, making it easier than ever to spin up a custom Layer-1. Cosmos has appchains, Celestia has sovereign rollups.
But with all that fragmentation comes one big question:
WHERE DO THEY ALL AGREE (OR SETTLE)?
Because no matter how many chains you launch, or how optimized they are, they all eventually need the same thing: a shared foundation. A place to anchor truth. That’s where settlement comes in, especially for systems that rely on external trust to function securely.
And if we’re already modularizing everything else like execution, consensus, data availability topics, then why not apply the same thinking to settlement itself?
Because if you look closely, there’s already a system quietly doing the job. One that tracks Ethereum, holds IBC light clients, manages proofs, and stores global state - all without demanding the spotlight. That system is Union
So maybe the real question isn’t where should we settle,
but why not settle on what already sees and verifies everything?
Okay, maybe it sounds dramatic but it’s actually the core idea behind a recent research post from the Union team by Robert , Karel and Hussein
The team basically lays out a modular vision where rollups don’t have to reinvent the wheel every time they want to finalize something.
Instead, they could all just settle onto a common layer that’s already watching, verifying, and syncing with the rest of the world.
Now… I’ll admit, I have my own questions. There’s always that part of me that goes, “Hmm, are we sure this won’t break in weird ways?” But then again—WHY NOT? Why not try to settle on something that already sees everything?
That’s why I wanted to explore this topic in more depth and hear what you think too. Let’s take a look
What even is settlement?
At its core, settlement is agreement—not just that something happened, but that everyone accepts it happened, and we’re ready to move forward from it. In blockchains, that means locking in a transaction or a state update so that it becomes final. Not tentative or reversible—just done.
Technically, settlement is the part of the system that verifies and records the state root. It verifies a proof, checks its validity, and updates its view of the world accordingly.
In Layer-1 chains like Ethereum or Solana, all of this is bundled together. You send a transaction, it gets executed, included in a block, and once finalized, it’s settled. Easy. But that model doesn’t scale well, so we started breaking things apart.
To scale these L1s, we introduced Layer-2s: rollups that handle execution off-chain, then send back a proof to the base layer. In doing so, we outsourced part of the trust. Now, the point is that L1s aren't supposed to be running everything. it’s acting as a settlement layer, verifying that what the rollup says happened actually did.
So far, Ethereum has often played that role. But maybe it doesn’t have to be the only one.
If you’re looking to explore more perspectives on what settlement means across different blockchain architectures, here are a few external resources worth checking out.
**Huge shoutout to my dear friend Yiğit **for support and pulling these together:
So… how would that actually work?
Union says it can act as a settlement layer. It tracks external chains, verifies proofs, and updates state roots all without taking over execution. But here’s the part that makes it possible: light clients.
Let's remember what light clients are
When you interact with a blockchain, you normally need to verify everything yourself --- full node style. But sometimes, that’s not practical. You don’t want to download the entire chain or run heavy computations just to check if something happened.
That’s where light clients come in.
You can think of a light client as a tiny verifier that tracks just enough of a chain to say: “Yes, I trust this state.”
Then someone (maybe a relayer) brings it a new batch of data: a header and a proof. The light client checks whether this new information matches what it expects. If everything checks out, it moves forward to the new state. If not, it stops right there.
You can visualize this in the diagram below:
This simple pattern above —current state + new data with proof and header (Batch) = a new state— is what makes light clients so powerful. They don’t need to see everything. They just need to know enough to say yes or no.
How about Union’s light client use?
This process is wrapped inside a single function:
Too technical? NOT REALLY. Let’s simplify.
The second input "clientMessageBytes" is what we’ve been calling the BATCH: a bundle that includes A HEADER and A PROOF. That’s what the light client uses to decide if a new state can be trusted.
The first input **"clientId" **is there because Union can track many different chains at once. So it needs to know which light client instance this update belongs to.
That’s it. The rest of the logic, from verifying the proof to updating the stored state happens internally.
ALSOOO one promising signal worth checkin' out: in another research post zkGasm-II, the Union team showed that light client updates can already be performed with much lower gas costs compared to other cross-chain systems
And if you want the full picture of how that process plays out across chains, I’ll explain it right below.
1 - Chain A is producing blocks, and the relayer keeps an eye on them. At some point, a block includes something that concerns Chain B like an asset transfer or a cross-chain message.
2 – The relayer fetches a batch from Chain A — this includes the latest header and a proof.
Think of it like the relayer saying:
“Hey, I found something! Here’s what happened, and here’s the proof.”
This batch (header + proof) is what will later be used to convince Chain B that the event is legit.
3 – The relayer brings the batch to Chain B and calls updateClient function.
This is where the light client on Chain B steps in. It already remembers the last trusted header. So when it gets the new batch, it checks:
“Does this proof match up with what I already trust?”
If yes, it updates its internal state. Now Chain B officially believes: “Okay, this really happened on Chain A.”
4 – Now that the state is verified, Chain B can safely process the message like calling recvPacket.
Since the light client update succeeded, Chain B now trusts that Chain A’s message is valid. This is when the actual cross-chain logic kicks in: tokens are released, contracts are triggered, messages are delivered.
All thanks to the light client saying:
“Yep, that proof checks out. We’re good to go.”
WAIT! "Don’t rollups already work like this?"
At this point, if you’ve worked with rollups, all this should start to feel very familiar. These systems execute transactions off-chain and periodically post updates to a base chain. When they return, they bring a compressed version of what happened during that period — a proof verifying those actions, and a new state root that represents the result.
SOOOO, what does the base chain do? It doesn’t re-execute every transaction or try to intrpret what happened. It just checks whether the proof is valid and, if so, accepts the new state as the truth. That’s it. no more questions asked.
SOUND FAMILIAR?
That’s essentially what we saw previously. We started with a trusted state. Then, a batch of new data (a header + proof) comes in. The light client checks whether this data is valid. If it is, it updates its internal state. If not, it rejects it entirely.
Different names, same behavior. The settlement process in rollups and the verification flow in light clients both revolve around the same question:
“Can I trust this new piece of information?”
BUT WAIT!!!!!
the Union team used Scroll as an example in their research post to show exactly how similar this process already looks in today’s rollups. So let’s walk through it quickly.
In a rollup stack, this verification step is handled by the prover. The prover constructs the batch and generates a proof: “Yes, this really resulted in this new state root.”
Then, similar to how a relayer would call updateClient on a light client, the prover sends this batch and proof to the base chain by calling a function like finalizeBatchWithProof
At that point, the base chain acts exactly like a light client: “Does this proof match what I already trust? If yes, update the state.”
Different stack, similar pattern.
And that similarity is what makes Union’s approach to settlement so interesting because the flexibility is already there. Union’s architecture allows extending light client capabilities whether it’s adding support for ZK rollups with execution proofs (like Scroll), or even incorporating fraud-proof logic to handle optimistic rollups
Is everything as smooth as it sounds?
Well... not exactly.
Up to this point, everything we’ve covered sounds like Union could already serve as a perfect settlement layer for rollups, right? In fact, the core flow is very compatible.
But to make this really production-ready and flexible for all kinds of rollups, there are still some pieces that need work. The Union team goes into great detail about this in their research post but I’ll give you the quick version here.
There are basically three key areas to address:
1- Permissionless light client code uploads
Right now, uploading new light client code (especially for new rollups) still requires governance approval. That’s not ideal as you can feel the culture of Web3 🥶. It limits flexibility and innovation.
The goal is to make this FULL PERMISSIONLESSS. This would open the door to supporting many more types of rollups, including ones with different proof formats.
2- Adapting misbehaviour detection for rollups Today’s IBC clients mostly handle misbehaviour in a validator-based model (think Tendermint). But rollups introduce new types of misbehaviour. For example:
-
Execution violation → ZK rollups might submit a proof for an invalid state transition.
-
Dispute → In optimistic rollups, you might have a challenge game between prover and sequencer.
3- More Data Availability flexibility
Union already supports multiple DA layers but DA remains a critical piece for rollup security especially to prevent data withholding attacks.
Supporting even more DA options and ensuring seamless integration with rollups is another key step.
Okay, now I’m curious.
At this point, I can’t help but wonder where this goes next. Can Union really become the layer where all these fragmented systems settle and agree? There’s still a gap between the vision and the production reality but the pieces are starting to click. Anyway, that’s enough of me rambling. If you’ve read this far… you’re probably curious too.
评论 (0)