A lot of rollups and ideas on rollups have emerged in the last 2 years in web3. You have optimistic rollups that rely on fraud-proving schemes to look for transactions that were not calculated correctly, and then we have zero-knowledge rollups that produce validity proofs to prove the correctness of transactions hence giving a cryptographic assurance to everyone. Every rollup's methodology and every rollup project, despite different paths, still want the same thing: to scale Ethereum securely and increase the throughput as much as possible.

Come in =nil; sharded zkRollup – this is a complete game-changer for devs and web3 as a whole as =nil; scales Ethereum through a protocol-level parallel transaction when execution. =nil; leverages horizontal scaling which reduces liquidity fragmentation created by hundreds of other rollups at the moment. The other important part is that there is direct Ethereum data access to L1 data from L2 data, which ensures a more unified and seamless environment than the other current rollup designs. We are going to take a deep dive into the tech but let's discuss the benefits of using =nil; zkRollups first.

1. Scalability: zkSharding promises no scalability limits with parallel execution, boasting impressive throughput capabilities, approximately 60,000 ERC-20 TPS

2. Security and Liquidity: It ensures a holistic security and liquidity model across shards, minimizing the need for liquidity migration and offering transparent access to Ethereum's data.

3. Decentralization and Security: Leveraging Ethereum's staking mechanism and a competitive proof market, zkSharding offers a decentralized, secure, and efficient framework for smart contract execution.

4. Enhanced Functionality: With features like a Type-1 zkEVM fully compatible with EVM bytecode and tailored environments for complex applications, zkSharding caters to a broad spectrum of smart contract applications.

Let’s get into a bit of technical details on how =nil; does it and what the zkSharding looks like. ZkSharding for =nil; is based on some big ideas: zkLLVM. a Placeholder proof system, crypto3 and a Proof Market:

1. zkLLVM is a circuit compiled to translate high level languages, such as C++ and Rust, for circuits for proof systems. By enabling algorithms to be compiled directly without relying on a specialized Domain Specific Language (DSL), it eliminates the need for code duplication and simplifies the development process. zkLLVM's architecture bypasses any intermediary layers, such as zkVMs, linking the algorithm and its final circuit representation more closely. This approach not only minimizes the circuit's size but also speeds up the computation's proving time. The compiler also allows for the direct manipulation of the circuit representation, enabling the generation of optimized verifier code suited for specific virtual machines, thereby boosting efficiency and performance. Built on the LLVM infrastructure, zkLLVM ensures wide-ranging compatibility with extensions based on LLVM IR, providing developers with flexibility and expansive application potential.

2. Placeholder Proof system is a modular framework for Incrementally Verifiable Computation (IVC) that leverages a PLONK-inspired proof system, offering tailored adjustments to meet the demands of specific applications. Its design allows for variations in underlying fields, enabling the shift from standard 256-bit to 64-bit fields for non-cryptographic algorithms, optimizing proving and verification times. Placeholder's modularity extends to the selection of commitment schemes, offering a balance between the need for trusted setups and verification costs, and the use of different lookup and gate generation techniques to minimize overhead and enhance efficiency. This flexibility makes Placeholder adept at reducing L1-layer confirmation times and accelerating zkBridge data provision through quicker generation of IVC-based zkVM and Ethereum consensus proofs, showcasing its potential to adapt and improve blockchain verification processes.

3. Crypto3 is a C++17-based modular cryptographic suite designed to foster innovation in cryptographic research and development.

4. Proof Market is a decentralized platform designed to decentralize the task of zkProof generation by connecting those in need of hardware-intensive proof generation with independent entities such as professional hardware operators, equipment owners, and circuit/hardware designers. It creates a dynamic marketplace where hardware operators meet the demand for proof generation, attracting substantial user engagement and incentivizing large-scale operators to maximize resource utilization. This competitive environment pushes proof producers to optimize their operations, either by scaling infrastructure to benefit from economies of scale or by refining hardware for enhanced efficiency. Producers who manage to offer competitive pricing and rapid service can gain market dominance, encouraging continuous improvement among competitors. Through Proof Market, =nil; zkSharding leverages decentralized proof generation from the outset, clearly separating the roles of validators and proof generators, thereby ensuring efficiency and scalability in its operations.

This is how the Trustless transaction processing work between Main shard, secondary shards, Proof Market, and Ethereum. This Novel mechanism helps in keeping =nil; zkrollup scalable, secure and trustless:

One great question that comes up in mind is how does zkSharding work? zkSharding is the crux of =nil; foundation’s rollup. =nil; uses something called Dynamic sharding where each shard interacts with other shards within the framework of a unified protocol. We have one primary shard that holds the key data about the protocol’s consensus and its current parameters. This primary shard synchronizes and consolidates data from the secondary shards, and also sets the protocol's rules and parameters. The secondary shards have the responsibility to work as “workers”, executing user transactions, and finally, these shards maintain said unified liquidity and data through a cross-shard messaging protocol. Here’s how Cross-shard messaging protocol looks like:

How does it work among shards? A table is defined for a minimal data unit, and an account is characterized by its address and its source code. Each of these secondary shards manages a subset of tables (accounts) and are defined by a deterministic function FS : (pk Mshards) -> idshards . These shards are maintained by a group of validators called committees and are responsible to run a local consensus algorithm to ensure consistency in the shard’s state. There are conditions to be met for dynamic sharding such as “Split Condition” and “Merge Conditions,” which are basically conditions looking for a shard’s block occupancy at its capacity or below capacity respectively.

The advantage of these shards is that the cross-shard communication is done because it’s integrated directly into the protocol rather than being managed by separate bridges. This prevents the data fragmentation on the protocol level, and each committee helps in keeping the cross-shard communication alive through their additional tasks like cross-shard messages within near shards which are determined on the basis of Hamming distance in shard identifiers. At the same time, to maintain consistency and transaction processing time, the protocol relies on “Colocation technique,” which basically ensures that two accounts { pk1 , pk2 } are consistently located within the same shards. So this means we can say that: Fs(pk1Mshards) = Fs(pk2, Mshards) for every possible value of Mshards. Here is an image of explaining how Parallel transaction execution work with =nil;

Finally, we will quickly talk about =EVM++; which is enhance for efficient execution of general purpose algorithms of EVM. It is made for highly optimized state transition proof generation through zkLLVM. =EVM++; is based on three key properties. Firstly, it ensures binary compatibility with existing EVM applications, meaning any application run on =EVM++; will produce the same output as if it were executed on a standard EVM, preserving the integrity and expected outcomes of applications. Secondly, it expands the execution capabilities to include general-purpose programming languages like C++ and Rust, enabling the deployment of complex applications not traditionally suited for blockchain environments, such as shared sequencers. This is facilitated through modifications to the EVM's architecture, including a more versatile set of opcodes that form a superset of the original EVM opcodes, the introduction of opcodes for efficiently handling memory blocks smaller than 256 bits, and adjustments to reduce the limitations of the EVM stack, such as allowing infinite stack depth with manageable gas implications for deeper stacks. Additionally, it incorporates new control flow commands for enhanced programming flexibility. Lastly, =EVM++; focuses on efficient state transition proof generation by aligning its opcode set with zkLLVM, optimizing for both traditional blockchain applications and more general-purpose computing tasks. This approach not only maintains compatibility with existing blockchain applications but also opens up new possibilities for blockchain technology application, making it a versatile and powerful tool for developers.

There are other things to consider here like Type-1 secure zkEVM which is not much different from other zkEVM implementations. It has two types of proofs: the State Proof that ensures that operations are performed correctly, and the EVM proof which confirms that the State Proof selected the correct data location. When it comes to the Data Availability layer for L2 solutions, it varies between the main shards and secondary shards. The main shard employs Ethereum as its DA whereas the secondary shards have an option to use Ethereum or to choose another DA like Celestia or Avail Project. The system begins with two types of shards: those with Data Availability (DA) and those without. Only shards within the same DA category can merge, requiring accounts to be assigned to a specific DA category from the start. This setup can later incorporate additional DA types. Utilizing Ethereum as the DA layer offers a cost-effective solution for storing the data necessary to recover Layer 2 (L2) states by using transaction calldata, benefiting from lower storage costs due to its non-persistent nature. This approach ensures data from shards is archived, with metadata maintained for easier access and retrieval. A shard's state is deemed finalized once its corresponding transaction on Ethereum is completed. DA transactions are divided into two segments: the payload for state restoration and metadata for shard identification, with the understanding that the payload, generally not needing direct access, can be archived.

Let’s finally look at it from the end user (developer’s) perspective. A regular developer is interested in direct access to Ethereum data which is based on the Data Provider module within the protocol’s node. Even after all the pieces like zkBridge and =EVM++; coming together, accessing Ethereum data does not differ from any other calls within the original ethereum network This is accomplished by differentiating between traditional Ethereum addresses and =nil; zkSharding addresses within the =EVM++;. When =EVM++; instructions interact with addresses, they determine if the address is part of the Ethereum Network. If so, =EVM++; fetches data from the Data Provider module, bypassing the original database. This is how data access looks like in a diagram:

Key takeaway for all developers building on top is that =nil; is using zksharding to build one of the most composable and scalable Ethereum L2 zkRollup. Using zkLLVM along with crypto3, devs can generate input for any arbitrary ZKP system or protocol, which eliminates the need to write any code in a specific DSL or libraries. Similarly, developers can use Proof Market Toolchain which provides tools for proof requestors and producers and is a game changer for incentivizing proof generations and selling while being reliable and less costly. Everything that =nil; is currently doing will shape up the future of scaling ethereum while keeping developers in the community, getting constant feedback, and to make the whole developer experience very seamless, so that developers don’t have to learn multiple DSLs or new tech!