I recently argued that an Optimium, the fraud-proof-equivalent of a validium, has sidechain-level security and is not an ideal scaling solution for Ethereum.
This debate is meaningful because Optimium chains, particularly Arbitrum AnyTrust chains like Arbitrum Nova, are in production and described as L2s. This post will argue that AnyTrust chains have equivalent security to sidechains by constructing a sidechain design that offers the same security properties as AnyTrust.
My view is that the core problem with sidechains is that validators can collude to directly steal user funds. In this sense, any design that allows any number of colluding validators to steal funds is as insecure as a sidechain. But - reasonable people disagree, so this argument will go further and aim to show that Optimium/AnyTrust offers the same safety and liveness guarantees as a sidechain.
Preliminaries
We care about two properties when we talk about security: safety and liveness.
Safety: no two nodes have a conflicting view of the state of the chain (in the L2 context, the state cannot be the result of the invalid execution of a transaction)
Liveness: a subset of malicious validators cannot indefinitely delay the chain.
Safety guarantees that user funds cannot be stolen by the operators of a chain, while liveness guarantees that user funds cannot be held hostage by the operators of a chain. These properties are typically framed in terms of a threshold; for example, if >2/3 of nodes are honest, safety is guaranteed.
Sidechain Security
On a sidechain, a set of validators process transactions outside of the main L1 chain. Existing sidechains require >2/3 of validator signatures (weighted by stake) for each new block.
This means that >2/3 of validators can collude and steal user funds, simply by producing an invalid block of transactions (fraudulently minting enough tokens to drain the bridge, stealing funds from a user without a signature, etc). This is a safety failure.
1/3 of validators can prevent the chain from progressing by withholding signatures, while 2/3 can launch a data withholding attack. These are liveness failures.
AnyTrust Design
AnyTrust is described in more detail here. It’s easy to understand in contrast to an Optimistic Rollup (OR). On an OR, all transaction data is posted to L1, so anyone can recover the latest state of the chain and create a fraud proof if the claimed state of the OR is invalid.
On an AnyTrust chain, a Data Availability Committee (DAC) attests that all transaction data is available. The DAC is permissioned, with members chosen by governance. AnyTrust requires that N-1 members of the DAC attest that data is available in each block. This means that as long as 2 members of the DAC are honest, we have a strong guarantee that data cannot be withheld from users and funds are safe.
Conversely, if N-1 members of the DAC are malicious, they can steal user funds directly by colluding with the sequencer. Data must be available to create a fraud proof, so the sequencer could include an invalid block (say, minting 1b ETH), as long as the DAC withholds data during the challenge period, and then drain the bridge.
If < N-1 members of the DAC attest that block data is available, then the AnyTrust chain converts to an optimistic rollup and posts data on L1.
The Argument for AnyTrust Security
The argument that AnyTrust is more secure than a Sidechain has two parts.
1. Stealing funds from a sidechain requires corrupting 2/3N + 1 validators, but stealing funds from an AnyTrust chain requires corrupting N-1 validators, so it is more secure for N>6.
2. AnyTrust has better liveness properties, in that it can continue operating as a rollup if members of the DAC go offline. The liveness threshold is 2/N, vs 2/3 N for a sidechain.
But rather than debating these points ad nauseam, if we can construct a sidechain that has the same liveness and safety guarantees as an AnyTrust chain, then we will have shown that AnyTrust has the same security as a sidechain. Let’s do so.
A Sidechain Equivalent to AnyTrust
Sidechains have traditionally inherited their assumptions about honesty thresholds from the BFT literature. But as Daniel Lubarov observed, they don’t have to. Sidechains inherit finality from the L1, just as rollups or AnyTrust chains do.
Therefore, we can build a sidechain that requires N-1 approvals, just like AnyTrust. In fact, we can have an analogous setup to AnyTrust, with a sequencer and a Validity Committee (with permissioned membership, like AnyTrust) that attests that blocks are valid. We require N-1 approvals from the Validity Committee for each block to be accepted by the L1, so funds are safe if 2 members of the committee are honest.
This construction gives an identical safety guarantee to AnyTrust chains because the threshold for safety is the same: 2/N.
Now let’s address liveness. We can add a recovery mechanism similar to AnyTrust, but instead of rollup mode, chain governance simply replaces validators that are unavailable for a long period. I can hear the complaints already, but hear me out.
In AnyTrust, membership in the DAC is permissioned. Governance initially selects the members of the committee and can add or replace members. Therefore, relying on governance to change the committee doesn’t introduce new trust assumptions[1], especially if governance also controls the bridge contracts for AnyTrust chains.
As long as 2/N validators are honest, block data cannot be withheld and the sidechain will not halt indefinitely. Therefore, this construction gives an identical liveness guarantee to AnyTrust chains because the threshold for liveness is the same: 2/N.
This recovery mechanism is arguably superior to AnyTrust because rollup mode forces users to wait for seven days to exit assets like NFTs. For high-usage chains, users might not be able to exit via L1, whereas governance recovery would allow the chain to continue operating after a short time. Governance can select validators with 99.99% uptime, so users should not be impacted by outages.
Debating Trust Assumptions
We’ve given a construction of a sidechain that has 2/N liveness and safety. This construction has equivalent security to AnyTrust as long as it doesn’t rely on additional trust assumptions.
A counterargument that AnyTrust relies on fewer trust assumptions is the following:
The sidechain scheme depends on governance to ensure liveness, but this isn’t necessarily the case for AnyTrust. An “ungoverned” AnyTrust chain can be created, such that governance cannot change members of the DAC after the committee is set. In this case, AnyTrust can recover from a liveness failure without any intervention from governance, whereas the sidechain cannot.
I think that this argument is valid as stated, but in practice, AnyTrust chains will always be “governed.” We aren’t debating the security of AnyTrust as an abstract technology, but rather the security of the AnyTrust chains that will be deployed. There should be a mechanism to rotate keys and committee members on the DAC, controlled by governance, as described here. Without the ability to rotate the committee, there’s a high risk that the chain will be permanently stuck in rollup mode.
Therefore, given that the design of AnyTrust explicitly allows for governance to change committee members, the sidechain construction that we’ve described has identical safety and liveness thresholds as AnyTrust, without any additional trust assumptions.
Another natural response is:
Polygon zkEVM or [insert rollup here] still relies on a multisig for upgrades or accepts governance upgrades without a timelock. Shouldn’t the argument that governance can replace proofs apply equally to those chains?
The crucial difference is that existing rollups have training wheels that protect users until the underlying technology is battle-tested. However, these training wheels are temporary, whereas AnyTrust chains must permanently allow governance to rotate members of the committee; otherwise, if any two members of the committee became unavailable or lost access to their keys, the chain would permanently become a rollup.
Improving AnyTrust
If we’ve successfully shown that AnyTrust is equivalent in security to a sidechain, then it’s fair to say that much of its design is security theater that unnecessarily penalizes users. For example, users are required to wait for the full seven day challenge period to withdraw from the native bridge. This leads to capital inefficiency and duration risk.
Fraud proofs are supposed to guarantee “single-honest-party” safety - meaning that as long as one person in the entire world is honest and able to construct fraud proofs, user funds are safe. However, AnyTrust only has 2/N safety, where N is likely << 100. Therefore, fraud proofs don’t contribute to AnyTrust security in DAC mode.
We can create a better version of AnyTrust by simply accepting that it is a sidechain. We can rename the DAC to “Validity Committee”, and require validators to attest to the validity of execution rather than just data availability. We can completely get rid of fraud proofs and the challenge period, without any additional security assumptions.
Closing
There is nothing inherently wrong with sidechains. The Polygon PoS chain is a sidechain that has filled an essential scaling need for Ethereum. Moreover, sidechains might offer the best tradeoff between cost and security for some apps, like games.
However, the Ethereum community has collectively decided that sidechains are not L2s, and there are other designs that offer greater security at similar cost.
For example, a Validium offers the same cost-savings in off-chain data availability as an Optimium but with greater security. Optimiums require data availability for both safety and liveness (data must be available to construct a fraud proof), but validiums require data to be available only for liveness; safety is guaranteed by a zero-knowledge proof.
These discussions are important because they inform how chain infrastructure is built in the future. Do we want to accept permissioned validator sets and sidechain security, or do we want to build solutions that offer low cost and higher security, protected by cryptography? These are substantive conversations that are worth having in a respectful and considered way.
[1]: An objection here is the following:
AnyTrust can impose a governance delay, such that users can exit the chain in rollup mode via forced transactions before the committee changes. Sidechains cannot support forced transactions.
The sidechain can be modified to impose a governance delay and allow users to force-exit the chain via simulated transactions on Ethereum. Users could provide a merkle path for their account balance and a signature (or a ZKP) and immediately withdraw funds. This scheme could even support simulating more complicated transactions on Ethereum. Note that for the purposes of this argument, it suffices only to show that the sidechain offers the same liveness guarantee as AnyTrust, which it does.
Thanks to Daniel Lubarov for providing feedback on an early draft of this post.