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

Starting point is 00:00:00 This audio is presented by Hacker Noon, where anyone can learn anything about any technology. Technical Analysis on ZKBase, a high-performance ZK rollup for scalable and secure ETH transactions, by ZKBase. ZKBase is a high-performance ZK rollup based on ZKStack 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.

Starting point is 00:00:50 ZKBase operates similarly to Ethereum but with higher throughput and lower fees. Smart contracts are written in Solidity, Viper 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. 1. Key components of ZKBase. Tree and tree backup. These components use RocksDB to maintain local copies of the L2 storage tree. The database stays synchronized with the latest state Ruthash, 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

Starting point is 00:01:32 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 roll-up 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

Starting point is 00:02:21 ensuring interoperability and asset liquidity between the two platforms too. ZKBase workflow. Users can initiate L2 requests either through an application programming interface, API, or via contracts deployed on L1. Once submitted, these requests center 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 B-tree set, a set implemented by a B-tree. The indexing structure is as follows. Here, fee underscore data is not involved in the actual score calculation but helps filter out transactions

Starting point is 00:03:03 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 statekeeper. Except for expired transactions, standard transactions are fetched from the mempool in the order defined by the B-tree traversal and recorded in the database. They are then processed by the statekeeper, 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

Starting point is 00:03:50 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 underscore 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 underscore sealer maintains a seal criteria registry that includes transaction count limits, L2 gas limits, upper limits on the amount of published data, among other regulations. There are four decision

Starting point is 00:04:36 scenarios, no seal, include and seal, exclude and seal, and unexecutable. In the first two cases, the process is the same, with the post-execution state being updated in the statekeeper. Exclude and seal 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

Starting point is 00:05:16 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 timeframe 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, EV 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 underscore sender the eth underscore

Starting point is 00:05:58 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, ETH Watcher 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.

Starting point is 00:06:46 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

Starting point is 00:07:26 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 basic circuits witness generator, leaf aggregation witness generator, node aggregation, scheduler, vectoration. Scheduler. Vector generation.

Starting point is 00:08:06 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 ZKRollup still faces numerous technical challenges. In the future, ZK base will continue to research and explore the implementation of decentralized sequencing and a decentralized ZK computational power network. Thank you for listening to this HackerNoon story,

Starting point is 00:08:56 read by Artificial Intelligence. Visit HackerNoon.com to read, write, learn and publish.

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

There aren't comments yet for this episode. Click on any sentence in the transcript to leave a comment.