|

|

The Rollup Struggle is Real

The Rollup Struggle is Real

Published on

Aug 7, 2024

It’s 2035. There are millions of EVM rollup chains across a few powerful rollup frameworks, and there still isn’t a neutral and seamless way to connect them.

Each framework is like a giant city-state, with its own labyrinthine rules and regulations.

On a good day, hundreds of millions of dollars are hacked in bridge attacks, so people tend to keep to their ecosystems and not venture out unless there’s a really good reason. Power continues to consolidate in these monopolized rollup frameworks, and there’s no incentive for them to play nice.

In this future, the promise of blockchain technology looks quite different from its potential reality.

Today, Ethereum stands at a similar juncture as the internet in the early 2000s. Back then, each network operated using different protocols, standards, and technologies, making it extremely difficult to achieve seamless communication and interoperability. Almost every aspect of the web that we take for granted was once a fragmented mess, from email to file sharing.

We’re living in the same moment for rollups on Ethereum. They have allowed the network to scale, but they have also created fragmentation between all the different rollup frameworks.

And in a future with potentially millions of EVM rollup chains across dozens of rollup frameworks, there still isn’t a neutral and seamless way to connect them all.

But first, we need to address what’s broken, so we can begin to fix it.

Every Rollup Adds Systemic Risk.

Currently, each new rollup introduces its own security model, which can have compounding negative effects as more chains interact across rollup frameworks. As more bridges are introduced to connect these rollups, they also introduce more risk because there are more interdependencies and potential attack vectors.

This is because there is no single “source of truth” across rollup frameworks and bridging them makes it nearly impossible to discern which transactions on a rollup can be considered part of its canonical history. It’s risky business with cross-rollup transactions, and it’s only getting worse as more rollup frameworks and chains are created.

Every Rollup is an island.

Right now, rollup ecosystems are siloed, and those silos are growing farther apart. Developers are building on isolated rollup frameworks that each have their vision for interoperability — as long as it stays within the walled gardens of their tech stack.

There are no scalable, neutral solutions out there that connect rollups across all major rollup frameworks.

Meanwhile, the user experience across rollup frameworks is virtually nonexistent, except when users roll the dice and bridge their funds.

Sending value across these frameworks should be seamless, without the attack vectors, costs, and delays that occur when using bridges. And users should be able to easily validate multiple chains across frameworks.

Every Rollup Means More Work for Builders

Today, it’s nearly impossible to build dApps, protocol and infrastructure that effectively tap into multiple rollup frameworks simultaneously. If developers want to create omnichain infrastructure that can be used across ecosystems, they have to build and deploy those solutions one-by-one for each rollup framework, expending immense resources and time.

Ideally, there would be a single destination for developers who want to integrate multiple rollups and rollup frameworks into their projects. And from this platform, developers would be able to launch infrastructure and applications across rollup frameworks, all in a unified platform.

Creating a connectivity layer between rollup frameworks is essential, if we want composability and interoperability to be realized at scale on Ethereum. Otherwise, each rollup framework will continue to develop as an island, with a fragmented community, value and liquidity capture, and redundant applications built for each stack.

If we want to build a world where rollups can communicate and transact seamlessly across multiple frameworks and applications, we must build it ourselves.