=Nil Introduction to Ethereum zkSharding

=Nil; It is a zkRollup that securely extends Ethereum to 60000+TPS through zkSharding, enabling web3 developers to build scalable, secure, and composable applicationsTL; DREquipped with zkSharding,=nil; Provide horizontal expansion without compromising the advantages of a single execution layer, namely unified liquidity and economic security.By ensuring rapid proof generation through open market competition with=nil, ProofMarket - a proof generation market that does not require a license

=Nil; It is a zkRollup that securely extends Ethereum to 60000+TPS through zkSharding, enabling web3 developers to build scalable, secure, and composable applications

TL; DR

Equipped with zkSharding,=nil; Provide horizontal expansion without compromising the advantages of a single execution layer, namely unified liquidity and economic security.

By ensuring rapid proof generation through open market competition with=nil, ProofMarket - a proof generation market that does not require a license.

Introduction to zkSharding

Nowadays, Layer 2 solutions balance scalability and state fragmentation. We introduced the second layer (L2) design=nil;, It drives the limits of Ethereum scalability without compromising the advantages of a unified execution environment. This solution combines dynamic sharding mechanism and verifiable access to Ethereum data, and is protected by zero knowledge technology. Key elements include:

ZkRollup and Sharding:=nil; The core of is a provable sharding protocol that achieves horizontal scalability without affecting security or efficiency. This method addresses some of the limitations of current vertical scaling (L3, L4, etc.), namely data and liquidity fragmentation.

Direct access to Ethereum data: The ability to call Ethereum raw data from L2 applications allows us to reuse deployed applications. Directly accessing L1 data from L2 ensures a more unified and seamless environment.

By zkSharding=nil; The advantages of monolithic and modular design include:

1. Scalability

There are no scalability limitations as execution is parallel. The estimated throughput is approximately 60kERC-20 transmission per second, with approximately 400 nodes.

By proving the competitiveness of the market, proof generation provides the fastest l1 finality and the cheapest proof generation cost.

2. Unified execution environment

A unified execution environment ensures that there are no security/liquidity shards, as each shard is a part of the entire cluster.

Reduce the need to migrate liquidity from Ethereum=nil; By forcing each validator to maintain a complete Ethereum state as part of deployment, applications are allowed to access data from zkEVM at=nil, providing transparent access to their data.

3. Safety

State transitions are protected by zkEVM and compiled through zkLLVM. It provides auditable security (such as constraint security) because the zkEVM circuit is compiled in high-level language from the EVM implementation used in production, rather than manually written, making the code easy to check,.

Decentralized from the first day, thanks to=nil; Realize decentralized proof generation and proof market.

4. Functionality

A Type-1zkEVM, fully EVM bytecode equivalent zkEVM, is compiled through zkLLVM.

A customized environment for applications with high requirements for time, memory, and algorithm complexity, reducing latency by improving single shard consistency and introducing mandatory per shard application co localization. Examples include decentralized exchanges, proof markets, decentralized sequencers/builders, and shared state applications (also known as autonomous worlds, etc.).

Dynamically composable extension

At a lower level,=nil; The state is divided into main shards and several auxiliary shards. The role of primary sharding is to synchronize and integrate data from secondary sharding. It uses Ethereum as its data availability layer and validator for state transition proof, similar to a typical zkRollups operation.

Assist sharding as a 'worker' to execute user transactions. These shards maintain unified mobility and data through cross shard messaging protocols, eliminating any fragmentation between them.

Each shard is supervised by a committee of validators. These validators rotate periodically between shards. In addition, updates to the sharding status are verified to the main sharding using zkEVM.

To illustrate the transaction process from user initiated to confirmation on Ethereum, please consider the following steps:

1. The user signs the transaction (tx) and distributes it to the network.

2. The validator in the shard S where the user's wallet is located places tx into the memory pool.

3. Then these validators create a new block B (1/S)

4. The hash value (1/S) of B is recorded on the main partition within block B (1/M).

The state transition proof of B (1/S) is generated and verified by the main shard in block B (2/M).

The proof of state transition for 6. B (2/M) is sent to Ethereum for verification and combined with necessary data to ensure data availability.

Once this process is completed, tx will receive confirmation from Ethereum.

This outline assumes that the user's transaction has not activated the cross sharded messaging protocol. However, in this case, the transaction flow remains unchanged, with the difference being that the user's transaction can trigger the creation of new transactions on other shards.

Due to the fact that all accounts are distributed across multiple shards, this may seem similar to the data fragmentation issue found in application specific roll up methods. However, the key difference lies in how to handle cross sharding communication: it is directly integrated into the entire protocol, rather than managed by a separate external bridge.

In order to ensure the security of each auxiliary shard, the validator committee has an obligation to prove that its state transitions to the main shard to ensure that fraud does not occur within a smaller group of validators. In addition to sharding maintenance, each sharding validator committee also has other tasks. The validator is responsible for tracking specific types of events, i.e. cross sharded messages within the 'near shard'. Near sharding is determined based on the Hamming distance in the sharding identifier.

ZkEVM is secure, auditable, and high-performance through zkLLVM: Type-1

=Nil; ZkEVM is Type-1zkEVM compiled using zkLLVM. In order to understand the difference between the more traditional zkEVM and=nil zkEVM, we need to discuss the limitations related to the circuit definition process based on zkEVM. The zkEVM circuit is a key component responsible for proving that state transitions are considered correct, typically defined using some custom zkDSL or simple library. This circuit definition approach poses the following issues:

Security: Problems caused by the size of the circuit and manual copying of EVM logic.

Auditability: Due to the complexity and ambiguity of the zkDSL used, auditability and limited inspectability are limited.

Compatibility: Due to the differences in behavior between zkEVM and actual EVM, the complexity of implementing actual bytecode compatibility (also known as Type-1) zkEVM circuits often imposes limitations on applications.

=Nil; ZkEVM effectively addresses all of these challenges by:

Security: Circuits should be automatically generated from the same high-level code used in the actual production and operation of Ethereum nodes to ensure that there are no algorithmic differences.

Auditable: Circuits should be represented in high-level programming languages (also known as c++or Rust), which should be written in a way that is easy for ordinary developers to read.

Bytecode Compatibility (also known as Type-1): The circuit compilation of high-level languages brings complete bytecode and EVM behavior compatibility, greatly reducing the time to market of EVM applications and the development time/workload required to achieve this compatibility.

The zkEVM compiled through zkLLVM is designed to be secure and utilizes evmoney to ensure complete consistency with the EVM used in Ethereum production. ZkLLVM (c++or Rust) is automatically compiled into the circuit, which means that human errors are eliminated from the circuit definition process.

Furthermore, because=nil; ZkEVM is compiled through zkLLVM, which is naturally more flexible than manually defined circuits (therefore, futuristic) because it is easy to adjust and circuit generation is automatic. It is also more auditable, which means its security will not come at the cost of adding the latest EIP to Ethereum.

ZkRollup has Ethereum security and data availability

Due to the different dedicated tasks of the main sharding and auxiliary sharding - auxiliary sharding focuses on transaction processing, while main sharding focuses on data synchronization - they have different data availability (DA) methods, which help restore state data in emergency situations. This means:

The main shard adopts Ethereum as its DA.

The auxiliary sharding can choose to use Ethereum or different DAs.

This arrangement is established by initiating two shards at the beginning: those with separate external data processing solutions and those without. In the subsequent stages, only shards of the same DA category can be merged. This means that during account creation, each account must be mapped to a specific DA category.

In addition, the framework can be extended to include other types of DAs.

Transparent Ethereum data access

One of our main goals is to optimize the composability of applications and prevent liquidity fragmentation, so without untrusted access to Ethereum state, the zkSharding method is naturally incomplete. This means=nil; Provide complete composability and transparent integration with Ethereum through the data provider module.

The data provider operates independently of the sharded data storage, synchronizes its information with external databases, and injects the fingerprint of the database status monitored by Ethereum (represented by Ethereum's block hash) into the sharded blocks. The latest status of the database comes from the confirmation module receiving verification, which uses zkBridge with Ethereum CasperFFG consensus proof.

What's next:

=Nil; And zkSharding is the pinnacle of product=nil. The foundation has been continuously developing over the past four years. Its goal is to become the first composable, scalable, and universal Ethereum L2zkRollup solution. We are pleased to share more implementation details in the coming months. Be sure to follow our Twitter and stay updated on our latest developments!

For those with technical tendencies, we have developed a separate and comprehensive introductory tutorial that delves into=nil; Details and zkSharding. This introductory tutorial is an introductory reading material to understand the intricacies behind this method, providing all the necessary technical details and basic knowledge.

Now delve deeper into our technology and join the conversation on Discord and Telegram. Let's explore the infinite possibilities of zkSharding together!