Opinion | How to Understand "Sidechain"?
TechFlow Selected TechFlow Selected
Opinion | How to Understand "Sidechain"?
Once, sidechains were the only available solution for maintaining a certain level of Ethereum composability and interoperability. Now, with the maturation of other Layer-2 scaling solutions, it's time to consider how sidechains can better integrate with these alternative approaches.
Navigating Web3 tides with focused insightsAuthor: barryWhiteHat
Translation: Ajian
Introduction
Layer-2 solutions are increasingly recognized as vital to Ethereum, and this is now widely accepted.
However, “Layer-2” is an imprecise label.
Some people use “Layer-2” simply to mean “not on Ethereum Layer-1.”
But in reality, how a solution interacts with Ethereum Layer-1 matters greatly. Different systems under the umbrella of “Layer-2” can have vastly different properties.
One could argue that “Layer-2” should be reserved for systems with specific security properties (for instance, we’d all agree that something deployed on AWS isn’t a Layer-2, though some projects with similarly weak security guarantees are still considered Layer-2s). However, that’s not the focus here.
Here, I want to discuss the properties of sidechains.
What Is a Sidechain?
At its core, a sidechain is a system where a set of validators periodically submits checkpoints of the latest state of a chain to a smart contract on the main chain. These checkpoints can be used by a bridge contract to enable user deposits and withdrawals.
Typically, there's also a leader election process among these validators to determine who creates the next block at any given time—examples include PoA (Proof-of-Authority) and PoS (Proof-of-Stake) consensus mechanisms.
(Translator’s note: By this definition, the author refers specifically to sidechains that lack validity guarantees designed into the main chain. Under today’s broader usage of “sidechain,” the author is discussing a subset of generalized sidechains. However, the original, narrow concept of “sidechain” aligns precisely with what the author describes here. It depends on whether one treats “sidechain” as a technical term or embraces its extended meanings.)
Sidechains play an important role in the Ethereum ecosystem. Before researchers developed better alternatives, they served as temporary solutions for scalability and usability. Products like xDai highlighted demand for improved user experience and helped spread awareness.
However, sidechains do not offer the level of security expected by the broader Ethereum community. This is not to say sidechains should never be used.
If users are fully informed and willingly accept the trade-offs, it may be a reasonable choice.
But if users are unaware, the risks are significant.
This article aims to provide clarity. If everyone already understands these issues, then writing this adds no harm. But if it helps correct misunderstandings, it will have served a purpose.
So what security properties do sidechains lack? Almost all sidechains fail to provide:
-
Censorship resistance
-
Finality
-
Guarantees of fund ownership
If you require all of these, you likely need an alternative to sidechains. That said, it may be possible to improve sidechain designs along these dimensions while preserving their core architecture. Open discussion benefits everyone.
Censorship Resistance
Clearly, sidechains are less censorship-resistant than well-designed blockchains—otherwise, blockchains wouldn’t be needed at all. But let’s dig deeper. Suppose a sidechain has N validators, and M validators can collude to censor any transaction. Then, only (N-M) validators are needed to censor an entire block. This creates a troubling dilemma: making transaction censorship harder makes block censorship easier. Since both forms of censorship are harmful, sidechains fundamentally cannot achieve strong censorship resistance. (Translator’s note: The logic is as follows—if M validators refusing to sign a block prevents finalization, then M validators can censor a transaction by refusing to build on a block containing it. But this also means that (N-M) validators can always produce blocks excluding certain content, or even go offline collectively.) This concern persists under PoS, and weighting block production by stake may worsen it, as fewer independent entities might control the threshold—even under ideal conditions of perfectly distributed stake, the situation is no better than non-PoS setups.
Data Availability Guarantees
Assume (N-M) validators can produce a block, and honest validators require full state data to validate new states. Then, if (N-M) validators act maliciously, they can:
-
Produce a new block
-
Refuse to share the block data with honest validators
-
Effectively exclude N-(N-M) = M honest validators from consensus, thereby gaining full control
How likely is this? More specifics would be needed for a definitive answer, but consider this: what incentive does a rational validator have to share data? In traditional PoA systems, reputation damage might deter withholding. But reputation mechanisms are weak—there’s no way to prove data was withheld unless all data is published on-chain. Does this sound like optimistic rollup? Yes, exactly. This implies that more secure sidechains essentially “degenerate” into optimistic rollups. In most sidechain designs, validators receive payments for their work. Honest validators split rewards among all N participants. Dishonest validators sharing data only among M = N-(N-M) members get the same total reward divided among fewer parties, creating a strong incentive not to share updated state. (Translator’s note: This calculation may be flawed.) There’s a fundamental challenge: data availability attacks are hard to detect. Honest validators struggle to distinguish between actual attacks and mere synchronization issues.
Finality
Suppose state transitions proceed as: state1 => state2 => state3, with each transition requiring transactions to execute on the prior state. Finality means once a transaction is confirmed, it cannot be reversed. Sidechain checkpoints, once agreed upon by validators, are submitted to Ethereum and finalized via Ethereum’s consensus. Some may assume this gives sidechains equivalent finality to Ethereum—that rolling back a sidechain block requires rolling back Ethereum itself. This is entirely mistaken. Finality means transactions cannot be undone—not that old states cannot be replaced by new ones. If (N-M) validators agree, they can perform: state1 => state2 => state1 (replacing state3 with state1 effectively rolls back state2, which was assumed final—all without requiring Ethereum reorganization).
Fund Ownership Guarantees on Sidechains
Suppose current state is state1={Alice:1000,Bob:0}, meaning Alice owns 1000 units and Bob has nothing. If Bob is malicious and controls (or can efficiently bribe) the majority of PoA validators, what can he do? He can execute a state transition state1 => state2 where state2={Alice:0,Bob:1000}, stealing all of Alice’s funds. Thus, sidechain security reduces to trusting that fewer than (N-M) validators will agree to such invalid transitions. This is widely known (at least I believe so), but bears repeating. Your confidence in a sidechain rests solely on trust that most validators won’t do this. Most security analysis of sidechains should center on this point. You may trust certain parties to some degree—just as many of us trust centralized service providers for various reasons. Sometimes the trade-off is worthwhile. The key is recognizing it as such.
Problems with Using Governance as a Defense
One argument is: “We can use governance to resolve all the above issues.” This approach is flawed because the entire system devolves into governance. What particularly concerns me is that it renders other sidechain properties theatrical (when and why would we need those otherwise?). For example, if governance is the ultimate safeguard, then PoS, PoA, etc., become irrelevant—the real consensus becomes governance itself. And clearly, governance processes are equally vulnerable to the same attacks.
Where Might Sidechain Properties Be Particularly Useful?
Beyond additional features like faster block times (and thus better UX), there are scenarios where sidechain characteristics shine:
-
When you explicitly want N-M validators to be able to perform arbitrary state transitions—for example, enterprise applications requiring high-level administrative control.
-
When M=0 and any N validators can make arbitrary changes—e.g., a four-player game. But the problem is, one validator can halt the chain entirely.
Conclusion
Once, sidechains were the only available option offering moderate levels of Ethereum composability and interoperability.
Now, with the maturation of other Layer-2 scaling solutions, it’s time to reconsider how sidechains can integrate with or evolve alongside them. Certain improvements would suit sidechains well:
-
Enable feeless mass migrations to ensure users aren’t trapped due to exit fees.
-
Replace leader election with mechanisms offering stronger censorship resistance (PoS may be a poor direction—see this thread).
-
Introduce coordinators to resolve discrepancies between two on-chain states.
-
Add fraud proofs to prevent invalid state transitions.
As optimistic rollup and optimistic VM technologies mature, the landscape of trade-offs for projects will shift. Now is a good time to reflect on sidechain properties and their associated compromises.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
