zkSharding for Ethereum

TL;DR

• zkSharding combines a sharded architecture with zero knowledge security
• Dispensing with the modular vs monolithic framework, zkSharding introduces a new paradigm - horizontal scaling for Ethereum
• zkSharding introduces a three-tier security architecture and is designed for decentralization
• =nil; Foundation is leveraging zkSharding to build =nil; - an Ethereum L2 designed for high-load applications, such as DEXes, autonomous economic agents, decentralized compute marketplaces, and on-chain autonomous worlds

Why zkSharding

The Ethereum community is currently addressing scalability through the modular vs monolithic framework. This framework, while useful to a certain extent, is also limiting.

But, let’s start with the basics.

Ethereum itself is a monolith - validator nodes run consensus, data availability, and execution. Everything is integrated so there’s no fragmentation. However, hardware and infrastructure constraints hinder Ethereum's speed and increase its costliness.

Modularity has emerged as the prevailing solution for Ethereum scalability. Speed and scale are offloaded onto layer 2 chains, which, in turn, handle security through Ethereum.

A modular approach does introduce a certain level of scalability into the ecosystem, but it comes with its own important trade off - fragmentation. The rollups of today function within silos and are (barely) interoperable through often vulnerable bridges. 

So, how do we solve state, liquidity, and user fragmentation, while still scaling Ethereum?

Counterintuitively, the answer isn’t better interoperability. It’s better scaling. 

zkSharding innovates on the modular design by introducing horizontal scaling, with interoperability baked into the protocol from the beginning. 

How zkSharding Works to Enable Horizontal Scaling

There are two schools of thought in blockchain scaling: a) scale through architectural improvements, and b) scale through software improvements. Traditionally, the former is classified as horizontal scaling, while the latter is vertical scaling. 

Horizontal scaling increases a system's capacity by distributing the workload across multiple nodes, often achieved through sharding. On the other hand, vertical scaling increases the hardware utilization or hardware requirements of individual nodes. 

Vertical scaling inevitably demands the hardware requirements of a full node to increase, thus trending towards centralization of power. Sharding has been touted as the ultimate scaling technology for blockchains and high-load applications because horizontal scaling allows the network to scale beyond the limitations of a single machine. 

One of the major benefits of zkSharding is that it allows for both horizontal and vertical scaling techniques without compromising on decentralization:

1. Horizontal scaling: A zkSharded network can scale without limitations by adding more shards as needed.
2. Vertical scaling: Each shard can be further scaled through software optimizations such as parallelized VMs that boost intra-shard scaling. 

zkSharding additionally introduces succinct zero knowledge validity guarantees for each shard's execution. This mitigates the severity of the weakest chain vulnerability that all sharded blockchains face. 

So, what does a network that uses zkSharding look like?

For example, the =nil; L2 splits the work between the main shard and the execution shards. All shards are interconnected and function as a whole: execution shards process transactions in parallel and generate ZKPs while the main shard verifies data, communicates with Ethereum, and synchronizes the state of the network across all validators. The main shard also manages the distribution of validators and accounts across the execution shards.

Let’s dive deeper into =nil;’s zkSharding implementation.

Security

The =nil; L2 is run by a validator set that’s split into subsets (i.e. committees). All validator full nodes participate in the global consensus protocol run by the main shard. Additionally, at every validator-rotation-epoch, validator full nodes are randomly sampled and assigned to participate in an execution shard's committee.

zkSharding has a three-tier approach to security.

On the first level, validator committees run a local consensus (HotStuff-2 based) to build blocks in each execution shard. 

On the second level, the execution shard committees generate a ZKP for the last N blocks they built. All committees send their proof to the main shard, where they are verified for correctness via a global consensus protocol (HotStuff-2 based).

Finally, the main shard aggregates all the execution shard proofs into a master ZKP and sends it to Ethereum for verification, after which the global state of the =nil; network is verified and reaches finality. 

Network Topology 

The =nil; L2 has cross-shard communication baked into the protocol from the start. Cross-shard messages are validated as transactions by each shard’s validator committee. 

Interoperability between the shards leads to a fully integrated UX experience. Developers can tap into the power of many blockchains running in parallel without worrying about bridging risks or managing their own infrastructure.

However, there might be some applications that require two contracts to call each other without any latency that comes with cross-shard communication. Contract co-location allows developers the flexibility to pay for contracts to live on the same execution shard, thus mitigating this overhead if necessary.

Data Availability

There are two types of shards: execution shards and the main shard. Execution shards are responsible for processing transactions over their local state and propagating messages across the network. The main shard is responsible for synchronizing and verifying all execution shards.

The main shard employs Ethereum for DA, while the execution shards use in-protocol DA from validators. However, =nil; Foundation is actively researching how specific execution shards might support alternative DA solutions if application developers demand it. 

This arrangement could be established by launching two kinds of shards: those with a separate, external DA solution and those without. This effectively creates a heterogeneous sharding environment based on the DA solution of a particular shard. The trade-off here is in the subsequent network phase: only shards of the same DA category could be merged through dynamic sharding.

Further, execution shards send their block hash to the main shard. Given the main shard has full DA guarantees from Ethereum, there is a strong data integrity guarantee from Ethereum for the whole network. This means that while execution shards that opt for in-protocol DA run some risk for an availability attack, it only takes one honest full node to restart that shard. 

zkSharding Benefits and Trade Offs

zkSharding is a decentralized network architecture that proposes a new framework for Ethereum scaling. Some of the benefits of implementing zkSharding:

• Global scale: zkSharding enables both horizontal and vertical scaling. 
• Unified global state: No state or liquidity fragmentation because any address can arbitrarily call any other address, regardless of shard location. =nil; Foundation is also working on research for L1+L2 composability to further minimize state fragmentation between =nil; and Ethereum.
• Cost-efficiency: Reliably low-cost transactions and fast finality block times (<1sec).
• Security: zkSharding as implemented by =nil; Foundation features three security tiers in terms of consensus and block generation. 

For developers, zkSharding introduces a network design that’s highly secure, decentralized, and integrated from the start. They can build apps without worrying about scaling limitations or fractured liquidity or user base. 

For users, zkSharding presents a unified user experience within a single environment, without constant bridging and swapping of assets.

What are some zkSharding trade offs?

zkSharding introduces complexity to network administration and development. Generally speaking, this overhead can be abstracted away from the end user. However, inherent to sharding is asynchronous communication between shards. This breaks the atomicity that’s possible in synchronous execution blockchains. 

=nil; Foundation has three ongoing research efforts that can help mitigate the severity of this trade-off. 

• Contract co-location: Enables developers to persistently co-locate contracts on a shard for a premium fee. 
• Enshrined proposer-builder separation: Allows =nil; to create a cross-shard slot thus pushing atomicity/synchronous execution to the builders. 
• Parallelized VMs: Allows for greater intra-shard throughput thus mitigating the need for cross-shard calls.

What You Can Build on the =nil; L2

The technical design of zkSharding allows =nil; to offer developers an environment that reliably and deliberately safeguards open global participation, permissionless innovation, decentralization, and censorship resistance. In other words, there are no social contracts to rely on. zkSharding means you don’t have to trust - just verify.

=nil; is ideal for the development of applications that have high demands related to time, memory, and algorithmic complexity. Examples include decentralized exchanges, decentralized compute markets, on-chain autonomous worlds, crowdsourcing applications, and autonomous economic agents. 

Additionally, =nil; is uniquely capable of handling high-volume public events and facilitating micro-markets that were once buried by regulatory capture and market inefficiencies. 

What’s Next?

=nil; and zkSharding are a culmination of products that =nil; Foundation has developed over the last 4 years. The =nil; L2 unlocks the power of zkSharding to allow for composability, security, and efficiency for both users and developers.

Stay tuned for a series of articles where we dive deeper into the =nil; zkSharding implementation and in the meantime, read our comprehensive zkSharding technical primer. 

Join the conversation on Discord and Twitter and learn more about building on the =nil; L2.