ZKBase is a high-performance ZK-Rollup based on ZK Stack and multi-gpu prover. This solution enhances transaction processing capability and provides a cost-effective network experience. Its key advantage lies in the adoption of zero-knowledge proof (ZKP) technology, allowing off-chain transactions to be quickly verified and confirmed while maintaining transaction privacy and data integrity. Since all validity proofs are verified on Ethereum, users can enjoy the same security guarantees as in L1. ZKBase operates similarly to Ethereum but with higher throughput and lower fees. Smart contracts are written in Solidity/Vyper and can be invoked using the same clients as other EVM-compatible chains. This article will introduce the core engineering and technical implementation of ZKBase. 1. Key Components of ZKBase Tree and TreeBackup: These components use RocksDB to maintain local copies of the L2 storage tree. The database stays synchronized with the latest state root hash, continuously reflecting the current system state. StateKeeper/VM: Executes transactions and securely stores the enclosed blocks in the local RocksDB database, ensuring data integrity and continuous state updates. Smart Contract: Deployed on the Ethereum mainnet, these smart contracts verify the zero-knowledge proofs (ZKPs) submitted from off-chain. Upon successful verification, these contracts update the account states on the Ethereum network. GPU Prover: A ZK-Rollup technology that ensures secure and efficient transaction verification through zero-knowledge proofs. When a batch of transactions occurs off the Ethereum mainnet, the ZK aggregation system compresses multiple transactions into a single "validity proof" calculated by the Prover, demonstrating the correctness of the batch. This proof is then submitted to the Ethereum network, enabling the rapid and secure confirmation of a large volume of transactions happening off-chain. Bridge: ZKBase provides a bridging mechanism for securely transferring assets between ZKBase and the Ethereum mainnet, ensuring interoperability and asset liquidity between the two platforms 2. ZKBase Workflow Users can initiate L2 requests either through an application programming interface (API) or via contracts deployed on L1. Once submitted, these requests enter a mempool, awaiting execution. Notably, transactions originating from L1 (such as deposits) are stored in a dedicated L1 priority queue to ensure they are processed promptly. The mempool storage structure is a btreeset (a set implemented by a btree). The indexing structure is as follows: Here, fee_data is not involved in the actual score calculation but helps filter out transactions that do not meet the fee requirements. The score is sorted by timestamp, and if timestamps are identical, then by address. Transactions in the mempool are managed by the mempool fetcher component within the State Keeper. Except for expired transactions, standard transactions are fetched from the mempool in the order defined by the btree traversal and recorded in the database. They are then processed by the State Keeper/VM, executed, and used to update the state tree. The block layout diagram shows the organization of transactions within a block and the arrangement of L2 blocks within an L1 batch. To initiate each L1 batch, the operator needs to input key details: the timestamp of the batch, its position in the sequence, and the hash value of the previous batch. The Merkle tree root hash serves as the foundational root hash in this process to ensure the validity of the batch and the authenticity of the transactions. Simultaneously, the State Keeper has the authority to decide when to finalize a specific L2 block or L1 batch, thereby determining its state. This decision is governed by a set of predefined criteria managed by the conditional_sealer module. These criteria include parameters such as transaction count, size limits, and gas usage thresholds. After processing a transaction, the State Keeper checks which sealing condition is met. The conditional_sealer maintains a SealCriteria registry that includes: Transaction count limits,


L2 gas limits,


Upper limits on the amount of published data, among other regulations. There are four decision scenarios: NoSeal, IncludeAndSeal, ExcludeAndSeal, and Unexecutable. In the first two cases, the process is the same, with the post-execution state being updated in the State Keeper. ExcludeAndSeal handles transactions that exceed the predefined batch limits by rolling back the transaction execution and placing it back in the queue to be included in the next L2 block. If an Unexecutable situation occurs, the transaction cannot be executed and will be rejected. At the end of each batch, the bootloader generates a placeholder L2 block to complete the transactions and prepare for the next cycle. Although mostly empty, this block is crucial for internal operations and includes a Transfer event log to record fee movements between the bootloader and the operator. To ensure time accuracy, the timestamps of the batch and the last sub-block are cross-checked with the expected L1 time frame to enhance the system's resilience to time-related issues. Once a batch is finalized, the prover generates a cryptographic proof to verify the block's execution. In ZKBase, the prover's responsibility is to prove the accurate execution of the ZKBase Ethereum Virtual Machine (EVM). This proof is then verified by a smart contract on the Ethereum network. Once the proof is generated, the prover packages it into an L1 transaction and sends it to the ETH_Sender. The ETH_Sender forwards the transaction to the ZKBase contract deployed on the Ethereum mainnet for further processing. The Ethereum mainnet verifies the proof's correctness and, upon successful verification, updates the state accordingly. Throughout the process, EthWatcher continuously monitors specific L1 events, such as deposits and system upgrades, to ensure synchronization with the Ethereum mainnet. 3. Multiple GPU Prover Architecture The architecture leverages a Postgres Database to share data, enabling parallel computation across multiple GPU Provers to enhance proof generation efficiency. The key components include: Operator: The server that provides Layer 2 services. Prover Gateway: A communication module that connects the operator with the proving subsystem. Witness Generator: Generates proof computation tasks and stores intermediate artifacts. Vector Generator: Aggregates all computation tasks into a vector format suitable for GPU computation and sends them to the provers. Prover: Performs the actual computation and verification of proofs. Compressor: Compresses the final proof into SNARK form. Proof Generation Workflow Batch Generation: The Operator collects transactions and generates a new batch. Batch Reception: The Prover Gateway retrieves the new batch from the Operator and begins preparing to generate the zero-knowledge proof. Database Insertion: The Prover Gateway inserts the batch information into the Postgres database. Subsequent data processing directly interacts with the database, retrieving data from the corresponding input tables and placing processed data into the relevant output tables. Witness Generation: This initial stage occurs when a user initiates a transaction, generating a witness. The witness proves the transaction's validity based on network consensus rules without revealing any transaction details. New transaction witnesses are collected and processed in batches. Each batch undergoes the following processes: BasicCircuitsWitnessGenerator


LeafAggregationWitnessGenerator


Node Aggregation


Scheduler Vector Generation: The Vector Generator consolidates circuits to produce witness vectors, optimizing the use of GPU computational power. Proof Computation: The Provers utilize GPUs to compute the zero-knowledge proofs, verifying the correctness of the proof computations. Compression: The Compressor module compresses proof to reduce data size, transforming it into SNARK form. 4. Conclusion ZKBase, built on ZK Stack and Multi-GPU Prover, achieves high-performance Layer 2 scalability. However, the Ethereum scaling solution ZK-Rollup still faces numerous technical challenges. In the future, ZKBase will continue to research and explore the implementation of decentralized sequencing and a decentralized ZK computational power network. ZKBase is a high-performance ZK-Rollup based on ZK Stack and multi-gpu prover. This solution enhances transaction processing capability and provides a cost-effective network experience. Its key advantage lies in the adoption of zero-knowledge proof (ZKP) technology, allowing off-chain transactions to be quickly verified and confirmed while maintaining transaction privacy and data integrity. Since all validity proofs are verified on Ethereum, users can enjoy the same security guarantees as in L1. ZKBase operates similarly to Ethereum but with higher throughput and lower fees. Smart contracts are written in Solidity/Vyper and can be invoked using the same clients as other EVM-compatible chains. This article will introduce the core engineering and technical implementation of ZKBase. 1. Key Components of ZKBase Tree and TreeBackup : These components use RocksDB to maintain local copies of the L2 storage tree. The database stays synchronized with the latest state root hash, continuously reflecting the current system state. Tree and TreeBackup StateKeeper/VM : Executes transactions and securely stores the enclosed blocks in the local RocksDB database, ensuring data integrity and continuous state updates. StateKeeper/VM Smart Contract : Deployed on the Ethereum mainnet, these smart contracts verify the zero-knowledge proofs (ZKPs) submitted from off-chain. Upon successful verification, these contracts update the account states on the Ethereum network. Smart Contract GPU Prover : A ZK-Rollup technology that ensures secure and efficient transaction verification through zero-knowledge proofs. When a batch of transactions occurs off the Ethereum mainnet, the ZK aggregation system compresses multiple transactions into a single "validity proof" calculated by the Prover, demonstrating the correctness of the batch. This proof is then submitted to the Ethereum network, enabling the rapid and secure confirmation of a large volume of transactions happening off-chain. GPU Prover Bridge : ZKBase provides a bridging mechanism for securely transferring assets between ZKBase and the Ethereum mainnet, ensuring interoperability and asset liquidity between the two platforms Bridge 2. ZKBase Workflow Users can initiate L2 requests either through an application programming interface (API) or via contracts deployed on L1. Once submitted, these requests enter a mempool, awaiting execution. Notably, transactions originating from L1 (such as deposits) are stored in a dedicated L1 priority queue to ensure they are processed promptly. The mempool storage structure is a btreeset (a set implemented by a btree). The indexing structure is as follows: Here, fee_data is not involved in the actual score calculation but helps filter out transactions that do not meet the fee requirements. The score is sorted by timestamp, and if timestamps are identical, then by address. Transactions in the mempool are managed by the mempool fetcher component within the State Keeper. Except for expired transactions, standard transactions are fetched from the mempool in the order defined by the btree traversal and recorded in the database. They are then processed by the State Keeper/VM, executed, and used to update the state tree. The block layout diagram shows the organization of transactions within a block and the arrangement of L2 blocks within an L1 batch. To initiate each L1 batch, the operator needs to input key details: the timestamp of the batch, its position in the sequence, and the hash value of the previous batch. The Merkle tree root hash serves as the foundational root hash in this process to ensure the validity of the batch and the authenticity of the transactions. Simultaneously, the State Keeper has the authority to decide when to finalize a specific L2 block or L1 batch, thereby determining its state. This decision is governed by a set of predefined criteria managed by the conditional_sealer module. These criteria include parameters such as transaction count, size limits, and gas usage thresholds. After processing a transaction, the State Keeper checks which sealing condition is met. The conditional_sealer maintains a SealCriteria registry that includes: Transaction count limits, L2 gas limits, Upper limits on the amount of published data, among other regulations. Transaction count limits, Transaction count limits, L2 gas limits, L2 gas limits, Upper limits on the amount of published data, among other regulations. Upper limits on the amount of published data, among other regulations. There are four decision scenarios: NoSeal, IncludeAndSeal, ExcludeAndSeal, and Unexecutable. In the first two cases, the process is the same, with the post-execution state being updated in the State Keeper. ExcludeAndSeal handles transactions that exceed the predefined batch limits by rolling back the transaction execution and placing it back in the queue to be included in the next L2 block. If an Unexecutable situation occurs, the transaction cannot be executed and will be rejected. At the end of each batch, the bootloader generates a placeholder L2 block to complete the transactions and prepare for the next cycle. Although mostly empty, this block is crucial for internal operations and includes a Transfer event log to record fee movements between the bootloader and the operator. To ensure time accuracy, the timestamps of the batch and the last sub-block are cross-checked with the expected L1 time frame to enhance the system's resilience to time-related issues. Once a batch is finalized, the prover generates a cryptographic proof to verify the block's execution. In ZKBase, the prover's responsibility is to prove the accurate execution of the ZKBase Ethereum Virtual Machine (EVM). This proof is then verified by a smart contract on the Ethereum network. Once the proof is generated, the prover packages it into an L1 transaction and sends it to the ETH_Sender. The ETH_Sender forwards the transaction to the ZKBase contract deployed on the Ethereum mainnet for further processing. The Ethereum mainnet verifies the proof's correctness and, upon successful verification, updates the state accordingly. Throughout the process, EthWatcher continuously monitors specific L1 events, such as deposits and system upgrades, to ensure synchronization with the Ethereum mainnet. 3. Multiple GPU Prover Architecture The architecture leverages a Postgres Database to share data, enabling parallel computation across multiple GPU Provers to enhance proof generation efficiency. The key components include: Operator : The server that provides Layer 2 services. Operator Prover Gateway : A communication module that connects the operator with the proving subsystem. Prover Gateway Witness Generator : Generates proof computation tasks and stores intermediate artifacts. Witness Generator Vector Generator : Aggregates all computation tasks into a vector format suitable for GPU computation and sends them to the provers. Vector Generator Prover: Performs the actual computation and verification of proofs. Prover: Compressor: Compresses the final proof into SNARK form. Compressor: Proof Generation Workflow Proof Generation Workflow Batch Generation : The Operator collects transactions and generates a new batch. Batch Generation Batch Reception : The Prover Gateway retrieves the new batch from the Operator and begins preparing to generate the zero-knowledge proof. Batch Reception Database Insertion : The Prover Gateway inserts the batch information into the Postgres database. Subsequent data processing directly interacts with the database, retrieving data from the corresponding input tables and placing processed data into the relevant output tables. Database Insertion Witness Generation : This initial stage occurs when a user initiates a transaction, generating a witness. The witness proves the transaction's validity based on network consensus rules without revealing any transaction details. New transaction witnesses are collected and processed in batches. Each batch undergoes the following processes: Witness Generation BasicCircuitsWitnessGenerator LeafAggregationWitnessGenerator Node Aggregation Scheduler BasicCircuitsWitnessGenerator BasicCircuitsWitnessGenerator LeafAggregationWitnessGenerator LeafAggregationWitnessGenerator Node Aggregation Node Aggregation Scheduler Scheduler Vector Generation : The Vector Generator consolidates circuits to produce witness vectors, optimizing the use of GPU computational power. Vector Generation Proof Computation : The Provers utilize GPUs to compute the zero-knowledge proofs, verifying the correctness of the proof computations. Proof Computation Compression : The Compressor module compresses proof to reduce data size, transforming it into SNARK form. Compression 4. Conclusion ZKBase, built on ZK Stack and Multi-GPU Prover, achieves high-performance Layer 2 scalability. However, the Ethereum scaling solution ZK-Rollup still faces numerous technical challenges. In the future, ZKBase will continue to research and explore the implementation of decentralized sequencing and a decentralized ZK computational power network.

Technical Analysis on ZKBase: A High-Performance ZK-Rollup for Scalable and Secure ETH Transactions

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

5 Reasons Why Layer 2 Solutions Will Overhaul FinTech As We Know It

(1/100) Crypto Countdown: Golem

05/03/2018: Biggest Stories in the Cryptosphere

µRaiden: Micropayments for Ethereum

The Noonification: Have U Been Pwned? (1/12/2023)

0x (ZRX) Analysis : Decentralised Exchange Protocol On Ethereum

5 Reasons Why Layer 2 Solutions Will Overhaul FinTech As We Know It

(1/100) Crypto Countdown: Golem

05/03/2018: Biggest Stories in the Cryptosphere

µRaiden: Micropayments for Ethereum

The Noonification: Have U Been Pwned? (1/12/2023)

0x (ZRX) Analysis : Decentralised Exchange Protocol On Ethereum

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps