Understanding sidechains

NOTE: The views expressed here are my own and do not necessarily represent or reflect the views of others or my employer.

Thanks Albert Ni for review and discussion.


Layer 2’s importance to Ethereum is growing by the week, and everyone knows it.

However, “layer 2” is an imprecise label. Right now, when people say “layer 2”, they tend to mean “not on Ethereum layer 1”. But the way something interacts with Ethereum layer 1 matters a lot. Different solutions that are all considered “layer 2” can have wildly different properties. Arguably, layer 2 should only refer to certain things with certain properties (e.g. we probably all agree that something that lives on AWS is not layer 2, but there are projects that arguably have similar security guarantees which are considered layer 2). But maybe that’s a topic for another day.

For this post I want to dig into the properties of sidechains.

Sidechain basically means a system where a set of validators checkpoint the latest state of the chain to a smart contract. These checkpoints are then used by a bridge contract to allow users to deposit and withdraw. There is usually a leader election process among the set of validators to determine who can create blocks. Examples of leader election mechanisms include proof-of-authority (POA) consensus, and Proof of Stake.

Sidechains have played an important role in the the ethereum ecosystem. They’ve been a stopgap solution for scalability and usability while the research community was still working on better solutions. Products like xDai at hackathons have highlighted the need for better UX which has trickled into the rest of the space.

However, sidechains do not have the security properties the broader Ethereum community expects. That doesn’t mean they should never be used. If people using sidechains are fully aware of the lack of certain properties, and still want to use them, that’s their prerogative. It may be worth the tradeoffs. It gets dangerous when people are not aware. The hope of this post is to provide information. If everyone was already aware of these properties, then another post about it can’t hurt. But if this helps people realize mistaken assumptions, that’s a good thing.

What are the security properties sidechains lack? Almost all sidechains do not provide:

  • Censorship resistance
  • Finality
  • Guarantees about owning funds

If you want more of these properties, seeking alternatives to sidechain-based solutions is one path forward. It is also possible to improve on these dimensions while still using the core sidechain architecture.

My hope is that an open discussion of these properties will benefit everyone.

Censorship resistance

It should not be controversial to say that sidechains have weaker censorship resistance properties than (well designed) blockchains. Otherwise, there would be no need for blockchains. However, let’s break this down a bit further.

If N validators are involved in a sidechain, and a transaction can be censored as long as M validators agree to do so, then N-M is the number of validators that need to collude in order to censor a block. This leads to a tricky balance where making it harder to censor transactions makes it easier to censor blocks. Given that both transaction censorship and block censorship are undesirable, this makes it fundamentally difficult for sidechains to have strong censorship resistance properties.

This concern extends to when proof-of-stake is used. It potentially gets worse as the numbers involved are weighted by stake, which means the number of distinct entities required to reach certain thresholds is likely even lower (at best, stake is perfectly uniformly distributed, in which case it’s just like the non-proof-of-stake case).

Data Availability Guarantees

We know that N-M validators are able to create a block. We also know that all other validators need to have data about the whole state in order to validate the new state. So if N-M validators are malicious, they can

  1. Create a new block
  2. Refuse to share the data with the honest validators
  3. Effectively remove N - (N-M) = M honest validators from consensus. Thus capturing the system.

How likely is this to happen? It obviously depends on many situation specific details, but we can start by considering what the incentives are for a rational validator to share data with all other validators. For traditional proof-of-authority, there is likely to be a reputational cost to not doing so. With proof-of-stake based sidechains, there may be stake at risk. However, it’s not easy to make this work, because there is no way to prove that some data was left unavailable without someone else putting all the data on chain. If this sounds like optimistic rollup, it is, which means sidechains with better security properties essentially reduce to optimistic rollup.

In most sidechains, validators receive some form of payment for being validators. For honest validators, this reward is shared among N validators. For dishonest validators, this same reward is shared between N - (N-M) = M (most importantly M < N here), so the there is incentive for validators to not share updated state with others.

An overall concept to keep in mind is it is very difficult to diagnose data availability attacks. To honest nodes, they are often indistinguishable from sync problems.


Imagine a series of state transitions as follows

state_1 => state_2 => state_3

Where each => involves a bunch of transactions being applied as part of updating state. Finality is the idea that once applied, a transaction cannot be undone.

Sidechains checkpoint blocks after they have been agreed upon via the consensus on Ethereum mainnet. This may lead one to think that sidechain finality basically is equivalent to Ethereum finality. Specifically, that in order to revert blocks on a sidechain, you would need to revert blocks on Ethereum. This is not the case.

This is because Finality is about reverting transactions, not about replacing an old state with a new one. So N-M validators are able to perform the following transition:

state_1 => state_2 => state_1

(replacing state_3 with state_1, thus reverting the supposedly finalized state_2 without requiring Ethereum mainnet reversion).

Guarantees around ownership of your funds on a sidechain

Assume there exists a state where state_1 = \{\text{Alice}:1000, \text{Bob}:0\}

So Alice has 1000, and Bob has 0. What happens if Bob is malicious and controls (or can effectively collude with) a super majority of POA validators?

Then, Bob can simply perform the state transition state_1 => state_2 where state_2 = \{\text{Alice}:0 , \text{Bob}:1000\}

Of course, this is tantamount to stealing all the funds from Alice and giving them to Bob.

Thus, a sidechain’s defense reduces to saying N-M validators could never be convinced to process such an illegal state transition.

This is well known (or so I believe), but I think it’s useful to remind everyone how this works. Your confidence in a sidechain reduces to your confidence that a supermajority of a sidechain would never do something like this. Most analysis of a sidechain’s security should focus on this.

Now, there may be groups of people (validators) that you would trust in this way. Just like many of us trust various centralized service providers for many things. Sometimes that’s worth the trade offs. It’s just important to be clear that that is the trade off being made.

Issues with governance as defense

An argument is sometimes made that “we can just use governance to solve everything mentioned so far”. This is flawed in that it basically says the whole system degrades to governance. One reason this argument especially concerns me is that it means the other attributes of the sidechain are theater (in which case, why have those attributes at all?). For instance, if governance is the final fallback to protect against the prior issues, then that means proof-of-stake, proof-of-authority, etc., don’t actually matter. The governance of the system is the real proof-of-authority. And, of course, the governance of the system can then still run all the aforementioned attacks.

Where might the properties of sidechains be especially useful?

Aside from the auxiliary properties of sidechains, such as faster block times leading to better UX (though databases give this too ;)), there are some situations where the specific properties of sidechains are arguably especially well suited to the desired properties of the system. For example:

  1. If you specifically want N-M validators to be able to perform arbitrary state transitions. Enterprise applications who want to have a master control switch are an example.
  2. Where M = 0 and you want N validators to be able to perform arbitrary state transitions. For example, in a 4 party game. Though one issue here is that 1 validator can unilaterally halt the chain.

Final thoughts

It used to be the case that sidechains were the only viable solution for certain use cases that wanted to retain a level of Ethereum compatibility and interoperability. Now, as other layer 2 scaling solutions mature, it is a good time to consider how sidechains can be made more compatible with those solutions.

Some additional features / properties that would be great for sidechains to incorporate:

  1. Implement mass migrations without a fee to ensure users can exit without being “stuck” due to costs.
  2. Replace the leader election mechanism with something with stronger anti-censorship properties (proof-of-stake seems to be the wrong direction to go in here – see Against proof of stake for [zk/op]rollup leader election)
  3. Require coordinators to place the diff between two states on chain.
  4. Add fraud proofs to prevent illegal state transitions.

As optimistic rollup tech and the optimistic VM (OVM) mature, the tradeoff space for projects will change. Thus, now seems like a good time to refresh on sidechain properties and their associated tradeoffs.


Excellent starting point in building awareness around this; I think there’s not enough education around the nuance of the risks users take on with many sidechain/bridge solutions.

If N validators are involved in a sidechain, and a transaction can be censored as long as M validators agree to do so, then N-M is the number of validators that need to collude in order to censor a block. This leads to a tricky balance where making it harder to censor transactions makes it easier to censor blocks. Given that both transaction censorship and block censorship are undesirable, this makes it fundamentally difficult for sidechains to have strong censorship resistance properties.

I didn’t quite follow this: can you sketch out the relationship b/w tx censorship cost and block censorship cost a bit more?


I’d hesitate to impose the properties you list on all constructions with the “sidechain” label, since unfortunately, “sidechain” is at least as imprecise a term as “layer 2” (cc Jorge Stolfi). Many (including yours truly) informally refer to optimistic rollup constructions as a type of sidechain, and as you hint at, ORUs don’t have any of the limitations you discuss (if they’re designed accordingly).

I tend to think we should just all get in the habit of always using qualifers w/ “sidechain”, i.e, “trustless/non-custodial sidechain,” “POS sidechain,” “federated sidechain,” etc.


Let’s take two scenarios with different values (v) for the number of validators nodes that are malicious: one where N - M < v < M, and one where N - M < M < v

If a transaction is submitted that the malicious validators want to censor, and they have N - M < v < M nodes, they can only reject the block containing it.

If they have N - M < M < v nodes, they can do better than rejecting the block: they can submit a new block that excludes the transaction, and the remaining N - M validators don’t have enough weight to reject it.

Does this fit what you had in mind, @barryWhiteHat?

Maybe in the section called “Censorship Resistance” it should read M where it reads N-M (and vice-versa)–or else those terms could be swapped in the section called “Data Availability Guarantees.” If N-M validators are needed to collude to censor a block (as it says in “Censorship Resistance”), then M (not N-M as it says in “Data Availability Guarantees”) validators are needed to create a block–right?

Why do we think that a Proof-of-Work blockchain has a lesser chance of having >33% or >67% colluding attackers than a Proof-of-Authority blockchain?

We’d run into the same problems if Proof-of-Work had those levels of collusion, right?

Its not that one costs a lot and once costs little. Its that you can not make both expensive you can only choose one to cost a lot. Let me give an example.

Lets say we have n = 7 m = 2. This means that there are total of 7 validators and 2 of them need to agree in order to include any transaction in a block. This means two things

  1. You have to get 2 validator to agree to include any transaction. EASY
  2. if 7 - 2 = 5 of them disappear (or agree to censor all transactions) then no more blocks can be made. HARD

So if we say that getting 2 validators to agree is too easy ie we want to make it harder to get transactions included we can reduce m = 5 and n = 7.

So now you have to get

  1. 5 validators to agree in order to include a transaction. Its harder to censor transactions. HARD
  2. 7 - 5 = 2 of them need to disappear in order to censor a block. But its also harder to censor blocks. EASY
1 Like

If proof of work finality of a block is forever being proved. Every time you build upon a block that is proving that block , and all blocks before it are finalized in your view. If you have 33% or 66% malicious they can make an invalid chain or they can perform invalid state transitions. But they need to continue doing this forever. This is a cost that they must pay of maintaining 66% hash power of the rest of the network. If they stop doing this the honest miners will eventually catch up to the malicious tip of the chain and invalidate it.

TLDR it comes down to how you recover from failure modes. With proof of work you can recover from this with side chains its more difficult.

This is a good answer. It’s easy to imagine in PoW how the blockchain can regain decentralized control after a temporary malicious takeover by concentrated power, but there’s no defined way for a PoA chain to regain decentralization once it’s lost. The remaining validator nodes could plausibly claim that there was no collusion. The network would be reduced to a battle of some community members claiming censorship happened and some denying it.

So I’m not sure if I’m understating the importance of what’s being said, as it sounds like this mostly boils down to, if N-M validators are malicious (or just M), bad things happen (plus some common misunderstandings). I didn’t see any mention of the (un)?trusted bridge to and from sidechains, which I don’t totally understand, but I’ve read that they basically reduce to the same N-M validator problem, with some caveats for waiting for finality on each chain to be considered valid. I claim what’s been said:

  • if M of N validators are mally, there’s transaction censorship vulnerability
  • If N-M validators are mally:
    • there’s block censorship vulnerability
    • there’s data availability attack vulnerability (which is hard to detect by honest validators)
    • Bob, member of the big bad supermajority (N-M?) cartel, can steal Alice’s funds (this would be true POA or POS afaik)
  • There’s a misunderstanding that sidechain finality <=> ethereum finality, when actually the forwards direction implication is much slower/weaker
  • Some people misbelieve that (presumably off-chain) governance mitigates N-M risk, when really, governance is a reduction of on-chain consensus to an off-chain layer of POA

So from that, I claim most of the criticism boils down to:

a sidechain’s defense reduces to saying N-M validators could never be convinced to process such an illegal state transition.

Plus highlighting those misconceptions.