TL;DR
Today, layer-2 solutions trade-off scalability for state fragmentation. We introduce a layer-2 (L2) design, =nil;, that pushes the limits of Ethereum scalability without compromising the benefits of a unified execution environment. The solution combines a dynamic sharding mechanism with verifiable access to Ethereum data, secured by zero knowledge technologies. Key elements include:
Through zkSharding =nil; benefits from advantages of both monolithic and modular designs including:
Scalability
Unified Execution Environment
Security
Functionality
On the lower level, the state of =nil; is partitioned into the primary shard and several secondary shards. The main shard’s role is to synchronize and consolidate data from the secondary shards. It uses Ethereum both as its Data Availability Layer and as a verifier for state transition proofs, similar to typical zkRollups operations.
Secondary shards function as “workers”, executing user transactions. These shards maintain unified liquidity and data through a cross-shard messaging protocol, eliminating any fragmentation amongst them.
Each shard is supervised by a committee of validators. There is a periodic rotation of these validators across shards. In addition, updates to a shard’s state are verified to the main shard using zkEVM.
To illustrate the transaction flow from initiation by a user to confirmation on Ethereum, consider the following steps:
This outline assumes that the user’s transaction does not activate the cross-shard messaging protocol. However, in this case the transaction flow remains the same with a difference that a user’s transaction can trigger a creation of new transactions on other shards.
With all accounts being distributed among shards, this might seem similar to the data fragmentation issue found in the application-specific rollups approach. However, the key difference is in how cross-shard communication is handled: it’s integrated directly into the overall protocol, rather than being managed by separate, external bridges.
To guarantee the security of each secondary shard, its validator committee is obligated with proving its state transitions to the primary one to ensure no fraud has happened within a smaller validator group. Each shard validators committee has additional tasks beyond shard maintenance. Validators are responsible for tracking specific types of events, namely cross-shard messages, within “near shards”. Near shards are determined based on the Hamming distance in shard identifiers.
=nil;s zkEVM is a Type-1 zkEVM compiled with zkLLVM. To understand the differences between more traditional zkEVMs and =nil;’s zkEVM, we need to discuss limitations associated with the circuit definition process that underlies zkEVMs. zkEVM circuit is a critical part, responsible for a state transition proof to be considered correct, being usually defined with some custom zkDSL or simply a library. Such a circuit definition way brings issues related to:
=nil; zkEVM is effectively addressing all of these challenges by being:
zkEVM compiled via zkLLVM is secure by design, leveraging evmone to ensure complete consistency with the Ethereum’s production-used EVM. The zkLLVM (C++ or Rust) automatically compiles down to the circuit, meaning human error is removed from the circuit definition process.
Moreover, because =nil; zkEVM is compiled via zkLLVM, it is naturally more flexible (and hence, future proof) than manually defined circuits as it is easily adjustable and circuit generation is automatic. It is also more auditable, meaning its security doesn’t come at the cost of including the latest EIPs added to Ethereum.
As the primary shard and the secondary shards are different in regards to their dedicated tasks - secondary shards focus on transaction processing while the primary shard focuses on data synchronization - they have different approaches to data availability (DA), which helps recover state data in emergency situations. This means:
This arrangement is established by launching two kinds of shards at the start: those with a separate, external DA solution and those without. In subsequent phases, only shards of the same DA category can be merged. This means that during its creation, each account must be mapped to a specific DA category.
Additionally, this framework can be expanded to include other types of DA.
One of our primary goals is to optimize for application composability and prevent liquidity fragmentation, so naturally the zkSharding approach would be incomplete without trustless access to Ethereum state. This means =nil; offers full composability and transparent integration with Ethereum through the Data Provider module.
The Data Provider operates independently from the shard’s data storage, synchronizes its information with an external database and injects Ethereum’s fingerprint of the last monitored database state (represented by Ethereum’s block hash) into the shard’s block. The most recent state of this database receives validation from the confirmation module, which uses a zkBridge with Ethereum’s Casper FFG consensus proof.
=nil; and zkSharding are a culmination of products that =nil; Foundation has developed over the last 4 years. Its aim is to be the first composable, scalable and universal Ethereum L2 zkRollup solution. We are excited to share more implementation details over the next several months. Make sure to follow our Twitter to stay up-to-date with our progress!
For the technically inclined, we’ve developed a separate, comprehensive primer that delves into the details of =nil; and zkSharding. This primer is your gateway to understanding the intricacies behind this approach, equipped with all the technical details and preliminaries you need.
Dive into our technical primer now and join the conversation on Discord and Telegram. Let’s explore the limitless possibilities of zkSharding together!
TL;DR
Today, layer-2 solutions trade-off scalability for state fragmentation. We introduce a layer-2 (L2) design, =nil;, that pushes the limits of Ethereum scalability without compromising the benefits of a unified execution environment. The solution combines a dynamic sharding mechanism with verifiable access to Ethereum data, secured by zero knowledge technologies. Key elements include:
Through zkSharding =nil; benefits from advantages of both monolithic and modular designs including:
Scalability
Unified Execution Environment
Security
Functionality
On the lower level, the state of =nil; is partitioned into the primary shard and several secondary shards. The main shard’s role is to synchronize and consolidate data from the secondary shards. It uses Ethereum both as its Data Availability Layer and as a verifier for state transition proofs, similar to typical zkRollups operations.
Secondary shards function as “workers”, executing user transactions. These shards maintain unified liquidity and data through a cross-shard messaging protocol, eliminating any fragmentation amongst them.
Each shard is supervised by a committee of validators. There is a periodic rotation of these validators across shards. In addition, updates to a shard’s state are verified to the main shard using zkEVM.
To illustrate the transaction flow from initiation by a user to confirmation on Ethereum, consider the following steps:
This outline assumes that the user’s transaction does not activate the cross-shard messaging protocol. However, in this case the transaction flow remains the same with a difference that a user’s transaction can trigger a creation of new transactions on other shards.
With all accounts being distributed among shards, this might seem similar to the data fragmentation issue found in the application-specific rollups approach. However, the key difference is in how cross-shard communication is handled: it’s integrated directly into the overall protocol, rather than being managed by separate, external bridges.
To guarantee the security of each secondary shard, its validator committee is obligated with proving its state transitions to the primary one to ensure no fraud has happened within a smaller validator group. Each shard validators committee has additional tasks beyond shard maintenance. Validators are responsible for tracking specific types of events, namely cross-shard messages, within “near shards”. Near shards are determined based on the Hamming distance in shard identifiers.
=nil;s zkEVM is a Type-1 zkEVM compiled with zkLLVM. To understand the differences between more traditional zkEVMs and =nil;’s zkEVM, we need to discuss limitations associated with the circuit definition process that underlies zkEVMs. zkEVM circuit is a critical part, responsible for a state transition proof to be considered correct, being usually defined with some custom zkDSL or simply a library. Such a circuit definition way brings issues related to:
=nil; zkEVM is effectively addressing all of these challenges by being:
zkEVM compiled via zkLLVM is secure by design, leveraging evmone to ensure complete consistency with the Ethereum’s production-used EVM. The zkLLVM (C++ or Rust) automatically compiles down to the circuit, meaning human error is removed from the circuit definition process.
Moreover, because =nil; zkEVM is compiled via zkLLVM, it is naturally more flexible (and hence, future proof) than manually defined circuits as it is easily adjustable and circuit generation is automatic. It is also more auditable, meaning its security doesn’t come at the cost of including the latest EIPs added to Ethereum.
As the primary shard and the secondary shards are different in regards to their dedicated tasks - secondary shards focus on transaction processing while the primary shard focuses on data synchronization - they have different approaches to data availability (DA), which helps recover state data in emergency situations. This means:
This arrangement is established by launching two kinds of shards at the start: those with a separate, external DA solution and those without. In subsequent phases, only shards of the same DA category can be merged. This means that during its creation, each account must be mapped to a specific DA category.
Additionally, this framework can be expanded to include other types of DA.
One of our primary goals is to optimize for application composability and prevent liquidity fragmentation, so naturally the zkSharding approach would be incomplete without trustless access to Ethereum state. This means =nil; offers full composability and transparent integration with Ethereum through the Data Provider module.
The Data Provider operates independently from the shard’s data storage, synchronizes its information with an external database and injects Ethereum’s fingerprint of the last monitored database state (represented by Ethereum’s block hash) into the shard’s block. The most recent state of this database receives validation from the confirmation module, which uses a zkBridge with Ethereum’s Casper FFG consensus proof.
=nil; and zkSharding are a culmination of products that =nil; Foundation has developed over the last 4 years. Its aim is to be the first composable, scalable and universal Ethereum L2 zkRollup solution. We are excited to share more implementation details over the next several months. Make sure to follow our Twitter to stay up-to-date with our progress!
For the technically inclined, we’ve developed a separate, comprehensive primer that delves into the details of =nil; and zkSharding. This primer is your gateway to understanding the intricacies behind this approach, equipped with all the technical details and preliminaries you need.
Dive into our technical primer now and join the conversation on Discord and Telegram. Let’s explore the limitless possibilities of zkSharding together!