Special thanks to Karl Floersch for feedback and review

The Ethereum layer 2 ecosystem has been expanding rapidly over the last year. The EVM rollup ecosystem, traditionally featuring Arbitrum, Optimism and Scroll, and more recently Kakarot and Taiko, has been progressing quickly, making great strides on improving their security; the L2beat page does a good job of summarizing the state of each project. Additionally, we have seen teams building sidechains also starting to build rollups (Polygon), layer 1 projects seeking to move toward being validiums (Celo), and totally new efforts (Linea, Zeth...). Finally, there is the not-just-EVM ecosystem: "almost-EVMs" like Zksync, extensions like Arbitrum Stylus, and broader efforts like the Starknet ecosystem, Fuel and others.

One of the inevitable consequences of this is that we are seeing a trend of layer 2 projects becoming more heterogeneous. I expect this trend to continue, for a few key reasons:

A big theme is that while applications and users that are on the Ethereum layer 1 today will be fine paying smaller but still visible rollup fees in the short term, users from the non-blockchain world will not: it's easier to justify paying $0.10 if you were paying $1 before than if you were paying $0 before. This applies both to applications that are centralized today, and to smaller layer 1s, which do typically have very low fees while their userbase remains small.

A natural question that emerges is: which of these complicated tradeoffs between rollups, validiums and other systems makes sense for a given application?

Rollups vs validiums vs disconnected systems

The first dimension of security vs scale that we will explore can be described as follows: if you have an asset that is issued on L1, then deposited into the L2, then transferred to you, what level of guarantee do you have that you will be able to take the asset back to the L1?

There is also a parallel question: what is the technology choice that is resulting in that level of guarantee, and what are the tradeoffs of that technology choice?

We can describe this simply using a chart:

It's worth mentioning that this is a simplified schema, and there are lots of intermediate options. For example:

These intermediate options can be viewed as being on a spectrum between a rollup and a validium. But what motivates applications to choose a particular point on that spectrum, and not some point further left or further right? Here, there are two major factors:

Approximately, this tradeoff looks something like this:

Another type of partial guarantee worth mentioning is pre-confirmations. Pre-confirmations are messages signed by some set of participants in a rollup or validium that say "we attest that these transactions are included in this order, and the post-state root is this". These participants may well sign a pre-confirmation that does not match some later reality, but if they do, a deposit gets burned. This is useful for low-value applications like consumer payments, while higher-value applications like multimillion-dollar financial transfers will likely wait for a "regular" confirmation backed by the system's full security.

Pre-confirmations can be viewed as another example of a hybrid system, similar to the "plasma / validium hybrid" mentioned above, but this time hybridizing between a rollup (or validium) that has full security but high latency, and a system with a much lower security level that has low latency. Applications that need lower latency get lower security, but can live in the same ecosystem as applications that are okay with higher latency in exchange for maximum security.

Trustlessly reading Ethereum

Another less-thought-about, but still highly important, form of connection has to do with a system's ability to read the Ethereum blockchain. Particularly, this includes being able to revert if Ethereum reverts. To see why this is valuable, consider the following situation:

Suppose that, as shown in the diagram, the Ethereum chain reverts. This could be a temporary hiccup within an epoch, while the chain has not finalized, or it could be an inactivity leak period where the chain is not finalizing for an extended duration because too many validators are offline.

The worst-case scenario that can arise from this is as follows. Suppose that the first block from the top chain reads some data from the leftmost block on the Ethereum chain. For example, someone on Ethereum deposits 100 ETH into the top chain. Then, Ethereum reverts. However, the top chain does not revert. As a result, future blocks of the top chain correctly follow new blocks from the newly correct Ethereum chain, but the consequences of the now-erroneous older link (namely, the 100 ETH deposit) are still part of the top chain. This exploit could allow printing money, turning the bridged ETH on the top chain into a fractional reserve.

There are two ways to solve this problem:

Note that (1) does have one edge case. If a 51% attack on Ethereum creates two new incompatible blocks that both appear finalized at the same time, then the top chain may well lock on to the wrong one (ie. the one that Ethereum social consensus does not eventually favor), and would have to revert to switch to the right one. Arguably, there is no need to write code to handle this case ahead of time; it could simply be handled by hard-forking the top chain.

The ability of a chain to trustlessly read Ethereum is valuable for two reasons:

Does having a bridge make you a validium?

Suppose that the top chain starts out as a separate chain, and then someone puts onto Ethereum a bridge contract. A bridge contract is simply a contract that accepts block headers of the top chain, verifies that any header submitted to it comes with a valid certificate showing that it was accepted by the top chain's consensus, and adds that header to a list. Applications can build on top of this to implement functionality such as depositing and withdrawing tokens. Once such a bridge is in place, does that provide any of the asset security guarantees we mentioned earlier?

So far, not yet! For two reasons:

Now, let's make the bridge a validating bridge: it checks not just consensus, but also a ZK-SNARK proving that the state of any new block was computed correctly.

Once this is done, the top chain's validators can no longer steal your funds. They can publish a block with unavailable data, preventing everyone from withdrawing, but they cannot steal (except by trying to extract a ransom for users in exchange for revealing the data that allows them to withdraw). This is the same security model as a validium.

However, we still have not solved the second problem: the top chain cannot read Ethereum.

To do that, we need to do one of two things:

The purple links can be either hash links or a bridge contract that verifies Ethereum's consensus.

Is this enough? As it turns out, still no, because of a few small edge cases:

A 51% attack on Ethereum would have similar consequences to a 51% attack on the top chain, but in reverse. A hard fork of Ethereum risks making the bridge of Ethereum inside the top chain no longer valid. A social commitment to revert if Ethereum reverts a finalized block, and to hard-fork if Ethereum hard-forks, is the cleanest way to resolve this. Such a commitment may well never need to be actually executed on: you could have a governance gadget on the top chain activate if it sees proof of a possible attack or hard fork, and only hard-fork the top chain if the governance gadget fails.

The only viable answer to (3) is, unfortunately, to have some form of governance gadget on Ethereum that can make the bridge contract on Ethereum aware of hard-fork upgrades of the top chain.

Summary: two-way validating bridges are almost enough to make a chain a validium. The main remaining ingredient is a social commitment that if something exceptional happens in Ethereum that makes the bridge no longer work, the other chain will hard-fork in response.

Conclusions

There are two key dimensions to "connectedness to Ethereum":

These are both important, and have different considerations. There is a spectrum in both cases:

Notice that both dimensions each have two distinct ways of measuring them (so really there's four dimensions?): security of withdrawing can be measured by (i) security level, and (ii) what percent of users or use cases benefit from the highest security level, and security of reading can be measured by (i) how quickly the chain can read Ethereum's blocks, particularly finalized blocks vs any blocks, and (ii) the strength of the chain's social commitment to handle edge cases such as 51% attacks and hard forks.

There is value in projects in many regions of this design space. For some applications, high security and tight connectedness are important. For others, something looser is acceptable in exhcnage for greater scalability. In many cases, starting with something looser today, and moving to a tighter coupling over the next decade as technology improves, may well be optimal.