Why Sharding Is Not the Same as Rollup-Centric Scaling

In his post last week, Vitalik argued that Ethereum’s rollup-centric roadmap was consistent with execution sharding since the “underlying approaches … are exactly the same.” While we agree that these two approaches share properties, this view understates differences between execution sharding and the rollup-centric roadmap. It’s precisely these differences that need to be considered when talking about Ethereum scaling.

The =nil; Foundation team has spent the last two years developing the sharding approach to finally arrive at zkSharding–an execution sharding solution that leverages zk to scale Ethereum horizontally. We aim to push the conversation around sharding forward by introducing a novel idea: a sharded L2, combining the best of both approaches examined by Vitalik. 

Shifting the Perspective

While the view that rollups are like shards is true from the perspective of Ethereum, from the lens of the end user rollups differ from shards considerably in terms of security guarantees, interoperability, and addition of shard/rollup governance.

Execution sharding is a technique that can be used to scale a blockchain, whether that’s an L1 or an L2. With a rollup-centric approach, we scale the L1 by introducing sovereign shards with little to no interoperability. The task of scaling the L2s still remains, which can be done by employing horizontal or vertical scaling techniques. 

When we think about scaling Ethereum, the more salient way to come to a sustainable solution for all parties is to consider a system which brings together the benefits of both sharding and rollups. 

The Benefits of Sharding

A sharded network provides stronger security guarantees (shared security) and native interoperability that’s missing in an ecosystem of rollups. Let’s examine these two key differences and the process of creating new shards vs rollups.

Shared Security

When you interact with a sharded blockchain that has a shared validator set, shard homogeneity, the same protocol and consensus layer, it’s clear what security guarantees you’re accepting. This is not the case between rollups–switching from one rollup to another means changing your trust assumptions. 

In execution sharding, each execution shard has only N/S validators at any given time, where N is total validators and S is the number of shards. This is obviously a weaker assumption than N parties validating a single shard. But to prevent a single-shard takeover, which could compromise the entire network, sharding protocols use random sampling, where validators are randomly selected to the committee of execution shards. This randomness enables sharded blockchains with shared validator sets to trivially offer 99.999%+ probabilistic guarantees about honest majority conditions (source). Furthermore, we can use ZKPs to get even stronger mathematical guarantees about correctness by proving state transitions (as is the case in zkSharding).  

“The result is that even though only a few nodes are verifying and creating blocks on each shard at any given time, the level of security is in fact not much lower, in an honest or uncoordinated majority model, than what it would be if every single node was verifying and creating blocks.” - Vitalik (Dec 2017)

Like rollups, shards share a common settlement layer (i.e. Beacon chain) but shards have the additional benefit of sharing a common protocol and validator set. This shared security model plays a critical role in promoting trust across the network whether that be functionally in passing messages between shards or coordinating across the social layer. Furthermore, homogenous sharding, where each shard runs the same state-transition function (such as the EVM), ensures consistency of network upgrades, which is a critical functionality for the longevity of any network as we will discuss further below. 

Native Interoperability

Given the proliferation of modularity, it appears evident that horizontal scaling is the end game for blockchain scaling. Horizontal scaling techniques like modularity and sharding alleviate blockchains of the following self-imposed constraint: “a blockchain cannot process more transactions than a single node can.” 

It’s impossible to service any global scale application under this assumption without forcing infeasible hardware requirements on nodes. Sharding is the strongest form of horizontal scalability that we know of today–it reduces the computation demands of a full node from O(c) to O(c/S) and unlocks what’s often referred to as quadratic scaling or linear scaling. 

At its core, this scaling law is enabled by native interoperability between shards, meaning a) any address can arbitrarily call any other address regardless of source and destination shards, and b) cross-shard communication is an inherent feature of any shard. There are several different ways in which sharding can handle native interoperability: light clients, shared validator committees across shards, or through a main chain (e.g. Beacon chain). However, every protocol by definition offers this functionality. Shards are interoperable by default. 

This means from a user perspective, execution sharding can unlock an integrated user experience whereby users only need to manage one address/wallet in perpetuity as the system scales out. 

This is very different from the properties of rollups, which require permissioned setups and strict configuration rules to communicate with each other. Due to the weakest chain vulnerabilities and the lack of real-time validity proofs, rollup interoperability requires all participating rollups to fully trust their counterparties. This is true regardless of the form factor of cross-rollup communication, such as shared sequencers, L3 architectures, and based sequencing. 

Essentially, rollups face the same interoperability challenge that has plagued crypto with $2.8B of bridge hacks. In fact, we believe that cross-rollup interoperability will be even more difficult to achieve than across L1 blockchains (we elaborate further below). Ultimately, this means rollup interoperability is highly permissioned. 

Shard vs. Rollup Creation

In all forms of shared security or transparent sharding (i.e. where shards are abstracted from the developer experience), shard creation is at the discretion of the protocol or social layer. Even in non-transparent sharding, such as Polkadot, where developers can create their own parachains, there are strict requirements for doing so set forth by the protocol. The Cosmos SDK is the most “open” form of sharding and anyone can run a Cosmos appchain, however, shared security is dependent on a certain amount of lobbying. 

Generally speaking, shard creation is permissioned. This trade-off not only impacts interoperability of shards but also the network’s ability to abstract away scaling complexity. 

Creating a new rollup is permissionless. There are many stacks a developer can choose to create their own rollup. 

To summarize the trade-offs between sharding and rollup-centric scaling:

• Sharding has strong shared security guarantees and trades permissioned shard creation for native interoperability.
• Rollup-centric scaling has weak shared security guarantees and trades native interoperability for permissionless rollup creation.

A note on asynchronous programming 

Many have criticized sharding as a viable scaling solution because it necessitates asynchronous programming for cross-shard calls and transactions. However, when we compare rollup-centric scaling vs sharding, it’s obvious that both require some asynchronicity to function. 

Contrary to this criticism, a sharded blockchain actually has the upper hand in developing a better developer experience because 1) the network is homogeneous so it's easier to establish standard DevEx practices and 2) all shards share the same social layer of operators so it’s easier to push upgrades. Similar to the DevEx comparison made in the modular (fragmented) vs monolithic (integrated) framework, sharding shares the same quality of DevEx as monolithic chains but with greater horizontal scalability than modular ones.

The Challenges of a Rollup-Centric Roadmap

More diversity means less security overall 

Rollups are great because they can be anything. Modularity means freedom. Every app will be a rollup. 

These phrases have been touted by the modular community so often that it seems most people have lost touch with why we fought for L2s to begin with. Beyond the obvious need for scale, L2s allowed for a diversity of solutions to compete in an open market. This “freedom” is motivated not strictly so everyone can deploy an L2, but also for ensuring that competitive forces drive the best outcomes for end users.

There is no controversy in acknowledging that the Ethereum L2 ecosystem is severely falling behind in terms of DevEx and UX to high-performance, monolithic L1s. The ecosystem is riddled with state fragmentation, weak or no interoperability, and growing security risks. Nearly every rollup provider has pushed the app-specific rollup narrative, claiming that new rollup L2s and L3s scale their “ecosystem”. And many applications are following suit. But why? 

We believe most applications are moving to app-specific infra because:

1. current general-purpose rollups do not offer sufficient execution scale (namely congestion fee mitigation) and 
2. they can fetch a valuation premium in the market by classifying as “infra.” 

General purpose execution environments have been empirically proven to be sufficient for the overwhelming majority of applications (80%+)--just take a look at Solana’s ecosystem. 

Customization has been considered an important feature in the modular world, but there’s an often overlooked consequence: opaque security disclosures. Security is a function of awareness and control, the more you have, the more security you can ensure. As rollups proliferate, the ability of everyday users to keep track of diverging security guarantees quickly drops to zero. Moreover, this security risk will compound regardless of whether or not applications customize their execution environment for must-have VM or consensus-level features. Even within a single rollup stack, there is an explosion of rollup security risk divergence.  

Quantifying the Risk

Today, we have many rollup providers (OP Stack, Arb Orbit, Polygon CDK, etc) and operators (application teams, RaaS, validator services, etc). For the sake of simplicity and keeping this estimate conservative, let’s ignore the operator risk.  

There are at least 4 teams that push the app-specific rollup narrative: Polygon CDK, Arbitrum Orbit, Optimism OP Stack, and zkSync Hyperchains.

When creating a rollup, each stack can be configured for multiple different parameters. For reference, OP Stack has 6 configurable components that match a specific functionality of the rollup stack.

Conservatively, there are at least 4 versions of each component that a rollup operator can run. Versions can add new functionality, patch a security vulnerability, introduce a new architecture, etc. – what’s important is that each version is different (granted some may be more or less different than others).

So we have:

• Rollup stacks: 4 
• Configurable components: 6
• Versions of components: 4

Total possible rollup configurations: 6^4 * 4 = 5,184

That’s 5,184 security profiles. And it appears that we aren’t slowing down. Each provider will continue to push upgrades, thus increasing the number of possible versions, and we are definitely getting more rollup stacks. This current path presents significant risks to the Ethereum ecosystem at large that, as far as we are aware, do not have a solution at present. 

The challenges of agreeing on universal standards are enormous

Vitalik shares what most of us know are the major problems L2s face today:

1) Moving tokens from one L2 to another
2) Cross-chain smart contract wallet support
3) Decentralization validation infrastructure

We will not delve into the specifics of each now–what’s relevant to note is the proposed solutions for all three are universal standards. “Universal” means all rollup stacks agree on this thing, which happens to be some infrastructure standard. Let’s break down what this means in practice.

In order for a universal standard to be agreed upon, all rollup providers (Offchain Labs, OP Labs, Matter Labs, etc) and their respective client implementations must coordinate amongst all rollup operators. The first priority for these providers will be agreeing on intra-ecosystem standards, followed by inter-ecosystem standards. The latter will require thousands of stakeholders to agree on universal mechanisms and standards that will directly impact their earning potential. 

Further, not only do they need to agree on a standard for their existing stacks, but also maintain open relationships and uniformity to ensure all upgrades are streamlined up and downstream to all other parties.

Vitalik says in his post:

“Individual layer 2s don't have a natural economic incentive to build the infrastructure to coordinate: small ones don't, because they would only see a small share of the benefit of their contributions, and large ones don't, because they would benefit as much or more from strengthening their own local network effects.” 

This is not a challenge that can be solved with clever engineering. It can only be solved by navigating the complexity of social, political, and economic factors at play. 

Why Ethereum Should Stick with the Rollup-Centric Roadmap Anyway (And L2s Should Consider Execution Sharding)

Despite outlining what may be interpreted as a case against Ethereum’s rollup-centric scaling roadmap, we are strong proponents of it for the reasons Vitalik outlines in his latest blogs. Additionally, we believe it would be reckless for Ethereum to attempt sharding at this point of development given the complexity it would introduce to the protocol. 

Ethereum is solidifying itself as the canonical source of truth for a burgeoning ecosystem of L2 solutions and by doing so promotes competitive free market dynamics that will ultimately drive the most value to end users. 

However, over the last several years, the Ethereum L2 ecosystem has consolidated into a single architecture: single-sequencer rollups. As outlined above, this has introduced difficult problems for the ecosystem at large and it appears that they will only get worse. 

We believe that sharding can solve these problems and unlock horizontal scaling. This is why we’re building =nil; – a sharded Ethereum L2, based on zkSharding. 

Read more about zkSharding in our high-level overview or dive deep into the zkSharding spec. 

Sharding is dead. Long live sharding.