The zkSharding concept introduced by the @nil_foundation is by far the most coherent plan we've seen to address the challenges of state fragmentation in the Ethereum L2 ecosystem.

Envisioning a unified execution environment for Ethereum, targeting one of the most pressing issues in the Ethereum ecosystem today.

So, here’s my take on “The zkSharding Thesis”

The Achilles Heel of Ethereum's Rollup-Centric Future

As someone who has been in this space for a while, I've seen the excitement of the Ethereum community around the rollup-centric roadmap over the past few years. Rollups, considered the holy grail of Ethereum scaling, promised to ease the network's congestion, significantly reduce the high gas fees and scale the Ethereum network to accommodate the global demand.

However, as rollup adoption has surged, a new challenge has reared its ugly head: state fragmentation.

It's basically the inability for different pieces of state in the different Layer 2s (L2), such as user addresses or smart contracts, to seamlessly interact across different rollups and L2 networks.

The implications of this fragmentation are far-reaching and threaten to undermine the very network effects that have made Ethereum the dominant smart contract platform.

Liquidity Spread Thin

One of the primary consequences of state fragmentation is the dispersion of liquidity and users across various networks with differing infrastructures. Each rollup or L2 solution operates in a siloed environment, which means that liquidity pools are fragmented. This dispersion leads to several inefficiencies:

• Reduced Market Depth: With liquidity spread thin across multiple platforms, the depth of each market is reduced, leading to higher slippage and less favorable trading conditions for users.

• Increased Costs: Users often need to bridge assets between different rollups, incurring additional transaction fees and delays.

• Fragmented User Base: Users are divided among different platforms, reducing the network effects that are crucial for the growth and robustness of decentralized finance (DeFi) ecosystems.

Cross-Network Security Challenge

Securing cross-network operations presents another significant challenge that comes with state fragementation. The complexity of maintaining security across multiple rollups and L2 solutions increases the risk of vulnerabilities and hacks:

• Inconsistent Security Protocols: Different rollups may implement varying security measures, leading to inconsistencies that can be exploited by attackers.

• Bridge Vulnerabilities: Cross-chain bridges, which facilitate the transfer of assets between different rollups, are often targeted by hackers. High-profile incidents, such as the Wormhole and Poly Network exploits, have resulted in substantial financial losses.

• Increased Attack Surface: The more interconnected the networks, the larger the attack surface, making it more challenging to secure the entire ecosystem comprehensively.

A UI/UX Nightmare

Finally, we come to perhaps the most underappreciated impact of state fragmentation: the toll it takes on developers and end-users.

For developers, building applications that work seamlessly across multiple rollups is a herculean task. Instead of focusing on innovating and pushing the boundaries of what's possible, they're forced to grapple with the idiosyncrasies of each rollup and the challenges of cross-network communication.

Users are often required to manage multiple wallets, bridge assets between chains, and pay varying gas fees, which can be confusing and off-putting. This fragmented experience can deter new users from engaging with the Ethereum ecosystem.

That’s one of the reasons why Liquidity and users are flowing from the Ethereum ecosystem to other L1s like Solana and Sui. It’s a direct consequence of the complexities created by the state fragmentation in the Ethereum ecosystem.

Is there a way to solve this problem? Can we achieve a more unified execution environment for the Ethereum ecosystem?

The technology being developed by @nil_foundation could be a potential solution to this issue.

Horizontal Scaling with zkSharding

Instead of just improving interoperability between fragmented L2 solutions, zkSharding aims to maximize scalability through horizontal scaling of the Ethereum execution layer itself.

By combining the concepts of sharding and zk-rollups (validity rollups), zkSharding enables parallel transaction processing across multiple shards while still maintaining a unified liquidity pool and shared state.

In the zkSharding model, the network is split into a main consensus shard and multiple execution shards. The execution shards act as "workers" that process transactions in parallel, each one maintaining a subset of the overall state. This allows the network to scale out horizontally by adding more execution shards as needed to handle increasing transaction loads.

zkSharding is designed to enable developers to build scalable applications based on EVM without significant rewrites or fundamental design changes. By using a shared state and supporting cross-shard communication, zkSharding provides a seamless experience compared to the fragmented L2 landscape today.

So now let’s get into the technical details of this solution.

The Network Architecture

At its core, zkSharding leverages a multi-layered architecture comprising execution shards that process transactions in parallel, the main shard that coordinates the global state across shards, and all underpinned by zero-knowledge proofs (ZKPs).

Let’s break it down to each layer.

Execution Shards

Execution shards are the workhorses of the zkSharding system, each responsible for handling a subset of accounts and processing transactions involving those accounts. This parallel processing enables the system to scale throughput as more shards are added.

Each shard operates independently, using the Sync HotStuff protocol to reach local consensus. Sync HotStuff is a partially synchronous Byzantine Fault Tolerant (BFT) consensus algorithm that ensures consensus with minimal latency, making it highly responsive. It simplifies the view change process and reduces communication complexity compared to other BFT protocols.

After processing a batch of transactions, the execution shard generates a ZKP, attesting to the validity of the resulting state changes.

The Main Shard

The main shard serves as the backbone of zkSharding architecture, responsible for managing the global state across the network.

It runs the HotStuff-2 consensus protocol to reach agreement on the validity of state transition (verifying block digests and quorum certificates). The main shard ensures that all state changes are valid according to the protocol rules, without needing to trust the execution shards. Once verified, the aggregated proofs are sent to the Ethereum mainnet for final validation.

The main shard generates a 'master' ZKP attesting to the validity of all state transitions in the cluster, ensuring the integrity of these transitions in a trustless manner without needing to replay transactions or maintain the full state. This hierarchical approach ensures the entire network remains secure and any state changes are accurately reflected on the Ethereum L1.

Additionally, the root hash of the global state tree is periodically published, allowing execution shards to ensure they are working with the latest state.

To enhance security, zkSharding employs a validator rotation scheme. Validators are randomly assigned to different execution shards after each epoch.

This frequent rotation mitigates the risk of adaptive adversaries that may attempt to corrupt specific shards. By constantly shuffling validators, an adversary cannot predict which shard they would need to compromise to successfully attack the system.

Transactions that require cross-shard communication must include all necessary messages to ensure completeness and validity. This design guarantees that all parts of a transaction are processed correctly, maintaining the integrity and consistency of the network. But this (cross shard communication) also introduces some additional complexities.

Contract Co-location

In some cases, applications need multiple smart contracts to interact immediately. However, the system doesn't support atomic or synchronous composability between different shards. This means that communicating across shards can cause delays, which might not work well for these applications.

To avoid these delays, the proposed solution called "Contract Co-location" enables developers to have multiple contracts on the same shard. This co-location helps reduce the time it takes for the contracts to interact.

This solution is similar to the Cross-shard contract yanking proposal. However, it can introduce additional complexities because moving state is always a complex process, and we will have to wait and see what the downstream effects of such a design choice will be.

Sequencing

The sequencing mechanism of the zkSharding architecture is based on a Proposer-Builder Separation (PBS) model, where distinct builders and searchers compete to construct the most lucrative blocks by outbidding others in a relayer auction. In a relayer auction, different relayers (messengers) bid to quickly and efficiently handle the communication between shards, reducing delays.

Each shard manages its own mempool of transactions, accessible to all network members, allowing PBS participants to choose which shard to collaborate with.

Data Availability (DA)

DA is maintained through a synchronization committee on the main shard. This committee ensures, that all necessary data is available and synchronized with Ethereum L1.

The committee's tasks include

• Agreeing on commitments to Ethereum L1

• Requesting proofs from proof producers

• Paying for and verifying these proofsand

• Composing DA transactions.

These compressed transactions are sent to Ethereum for inclusion in blocks.

Validators can join the synchronization committee but must pause their validator role to avoid conflicts. The committee rotates with each epoch, generates state differences, proposes hashes, and votes on them.

If a hash gets enough votes, it and the state difference are sent to Ethereum as a DA transaction. If there are too few transactions, they can be bundled and sent directly to L1 builders and searchers. Execution shards handle their DA by storing snapshots off-chain and sending compressed state differences to Ethereum or a dedicated DA layer.

Transaction Finality

Probabilistic finality is achieved when a data availability transaction from the main shard is included in an Ethereum block. Absolute finality occurs once all ZKPs and state differences are verified, ensuring the transaction is permanently recorded and irreversible.

Ok, so far so good. Now that we understand the architecture, the big question is: What are the trade-offs that most of the solutions involve

Trade offs

In my view, one of the main drawbacks of this architecture is its lack of atomic / synchronous composability between different shards. This means that transactions involving multiple shards can't be completed in a single, indivisible operation, which can create complexities and potential inconsistencies.

For example, if a transaction needs to update data on more than one shard, ensuring that all these updates happen together or not at all becomes difficult.

Moreover, methods like contract co-location, which attempt to place related contracts on the same shard to minimize cross-shard communication, can have unwanted downstream effects. Moving state between shards introduces additional complexities and managing these states becomes challenging and unpredictable.

Additionally, the need for a coordination layer, such as the mainshard, is necessary to handle interactions between shards. However, this coordination layer can become a bottleneck, limiting the overall throughput of the system.

Conclusion

The zkSharding concept introduced by the @nil_foundation is by far the most coherent plan we've seen to address the challenges of state fragmentation in the Ethereum L2 ecosystem.

This solution creates a unified execution environment for Ethereum, targeting one of the most pressing issues in the Ethereum ecosystem today.

This architecture also highlights the possibilities opened up with ZKPs and the potential for even greater improvements in performance and scalability.

The Devnet for =nil; is going live soon.

If you're interested in participating, you can learn more here:

Also, if you want to dive into more details listen to my conversation with Avi Zurlo, the CPO of the @nil_foundation, here's the link:

Do you like our Thesis Approach to understanding crypto and blockchain tech?

Then Subscribe to our Newsletter and we'll deliver a Thesis every week straight to your inbox:

Guaranteed spam-free:)