Welcome to =nil;
=nil; is an Ethereum layer-2 blockchain powered by zkSharding. The cluster unlocks the power of many machines by partitioning state across shards with cross-shard communications being a built-in feature of the protocol.
The design of =nil; embodies three core qualities:
- Horizontal scalability. State is partitioned across execution shards without state and liquidity fragmentation.
- Modularity. =nil; acts as an execution layer while using Ethereum for data availability and consensus.
- Verifiable security. The entire =nil; network can be verified with a single zero-knowledge proof attesting to the correctness of all shards.
The design of =nil; transcends the typical monolithic vs. modular discourse as it emphasizes horizontal scalability above all else. =nil; scales out beyond the constraints of a single machine's processing power, by leveraging zkSharding, a new type of sharding architecture.
In zkSharding, message processing is delegated to execution shards which contain small partitions of the overall state. Execution shards are managed by the main shard while a special sync committee handles data availability. The sync committee is also responsible for producing zero-knowledge proofs (ZKPs) verifying intra-shard state transitions.
In addition, cross-shard communications are incorporated directly into the =nil; protocol. This means that the issue of state fragmentation is avoided entirely as each shard can call contracts deployed on a different shard.
In =nil; it is only possible to deploy smart contracts on execution shards. The main shard exists for synchronization purposes only.
=nil; offers an effective strategy for scaling Ethereum while avoiding the limitations typically associated with the modular approach such as state and liquidity fragmentation.
Key differences with Ethereum
The following table summarizes how =nil; differs from Ethereum.
Area | =nil; | Ethereum |
---|---|---|
State | State is partitioned between individual shards responsible for message execution | State is not partitioned |
Execution | Support of async message execution | Only sync message execution |
Accounts | All accounts are smart contracts, no EOAs | Separation of EOAs and contract accounts |
Deployment | Support of internal and external deployment without requiring an EOA | An EOA or a smart contract are required for deployment |
RPC | Custom RPC loosely modeled after the Ethereum RPC | The original Ethereum RPC |
Currency and tokens | One native token used to pay for execution; contracts can create and be debited in custom currencies | One native token, support of multiple token standards |
The architecture of =nil;
The materials in this section may describe features and components that are not yet part of the cluster as it is available to developers.