Thesis

This page explains the rationale behind the architecture of =nil; and provides insight into how =nil; resolves the fundamental monolithic vs. modular dispute.

Problem statement

The rollup-centric roadmap to scaling Ethereum and the rise in the popularity of rollups introduces a significant issue: rampant state fragmentation.

State fragmentation is described as the inability for one piece of state (i.e. user address or smart contract) to arbitrarily call another piece of state within the system of interest. This leads to the following outcomes:

• Liquidity and users are spread across various networks that rely on different infrastructures and frameworks
• Cross-network operations are difficult to secure, resulting in more hacks
• Worsened developer and user experience. It falls either on developers or users to ensure cross-chain operations which adds an unnecessary layer of complexity

Solution

Instead of focusing on improving interoperability (which only produces a 'bandaid' fix to the fragmentation problem), the goal of =nil; is to maximise scalability.

=nil; achieves this by leveraging horizontal scaling supported by the zkSharding architecture.

Definitions

Horizontal scaling refers to improving the throughput of a chain by adding more nodes.

zkSharding is a type of sharding architecture in which execution is delegated to shards acting as individual networks while a special sync committee generates zero-knowledge proofs (ZKP) verifying intra-shard state transitions. There is also a dedicated shard for coordinating execution shards and communicating with Ethereum.

In addition, cross-shard communications are incorporated directly into the =nil; protocol. This means that the issue of fragmentation is avoided entirely as each shard can call contracts deployed on a different shard.