What is zkTube?
ZkTube is a Layer 2 protocol based on K Rollup (Layer 2 capacity expansion scheme with the zero-knowledge proof). In terms of token trading under the ERC20/ERC721 protocol, it can greatly reduce the transaction cost, and achieve the throughput 200 times than that of Layer1, with the TPS of up to 3000+. ZkTube will become a satisfactory solution for application scenarios with higher requirements on the transaction delivery, timeliness, and high-throughput Dapp.
Both zkTube and zksync are designed based on zkrollup proposal, which aim to Zk Rollup technology was put forward by Barry Whitehat on Github as the [Rollup] concept in an attempt to expand the Ethereum with [SNARK]. Later, Vitalik improved and supplemented this proposal, and then released on Twitter. During this period, all kinds of teams around the world also made different attempts on the rollup technology, and various rollups technologies, such as Optimistic Rollup and zkrollup, were developed.
All protocols built based on zkrollup are facing three core problems as below:
- Long time consumption problem of zero-knowledge proof
- Compression processing problem of zero-knowledge proof
- Support general contractual problems
Technology improvement of zkTube
Bulk packaging and state root isolation
ZkTube separates the process of submitting batch to the Layer2 for trading and of submitting the state root by the way of independent bulk packaging. Different from the previous ways, zkTube separates batches, sort them by time, and then proves, verifies and updates the root state when these batches are submitted to the layer 1 of Ethereum. In this way, operators can submit multiple batches at once, and multiple operators can also submit different batches simultaneously. The advantages of this way are to
- allow multiple sorters to release batches simultaneously to increase the passing rate of review, avoiding the problems of some batches being packaged firstly and others batches becoming invalid.
- In case that a state root is invalid, we can only roll back the state root, instead of rolling back the entire batch, and wait for a new state root of such batch provided by others. This ensures that transactions of the transaction sender will not be rolled back.
- Operator’s audit mechanism
For the purpose of ensuring the timeliness, stability and security of network and improving the enthusiasm of ZKtube operators, zkTube has designed a set of complex algorithm mechanism to conduct the weighted evaluation in accordance with operators’ submission frequency, submission time length, quantity of token mortgaged and other parameters when ensuring that operators don’t carry on the malicious operation, and qualified operators will be rewarded with ZKT in accordance with the zkTube reward system.
Optimization based on PLONK algorithm
The zero-knowledge proof PLONK algorithm is adopted by zkTube on the layer 2. From the theoretical perspective, STARKs algorithm, the safest algorithm, is calculated completely based on the hash value and information theory, instead of relying on the assumption of matching and exponential knowledge, which is also resistance to quantum computer attacks. It accordingly increases the number of proof bytes, from 288 bytes (b) to thousands of bytes (kb), which is not suitable for zkTube to build the general Layer 2 protocol. Secondly, the biggest problem of STARKs is that it is not universal. Different arithmetical schemes are required for different problems or scenarios. It is not practical for zkTube for now. It might be a good choice if applying it on the Layer 2 sharding technology after Ethereum 2.0 is launched in the future.
SNARKs algorithm uses the least number of bytes among all algorithms, but Groth16 is the one that uses the most. Firstly, Groth16 is not universal, and relies on the one-time non-upgradable setting. In case of any changes in the system or minor bugs, new rituals are needed to deploy and repair it. Secondly, different CRS(the Common Reference String) are required for different problems, which is equivalent to different circuits that shall be designed for different scenarios. So, this algorithm is used in specific scenarios, just like decentralized dex, payment and other simple scenarios in the circuit design.
PLONK algorithm uses more bytes than that of SNARKs, but less than that of STARKs. The advantages of PLONK is that it supports universal and upgradable reference character string. In the circuit design, as long as it doesn’t exceed the upper threshold SRS, the SRS can be commonly used in some scenarios and functions, which has a great help to zkTube. ZkTube takes advantage of this characteristic and maximizes such characteristic in specific scenarios, including deposit, withdraw, transfer, buy and sell. Its proof time was shortened about 5 times originally than that of SNARKs, and its proof time is shortened about 15–20 times after the optimization of zkTube
To maximize the use of CPU, we optimize it by reducing the occupied memory and allocating memory reasonably, and try our best to use one universal SRS in the circuit design as far as possible. That’s why we grouped different SRs into different groups in the Merkle Tree, proved them in parallel, and introduced the repeated data calculation as mush as possible to reduce the memory usage. Meanwhile, we use a monitoring mechanism to adjust the allocation of memory. For example, if the time period of a certain circuit has a too high frequency, and there will be special threading to handle pre-store schemes to achieve the effect of allocated memory.
zkTube has optimized and improved the above aspects to provide better Layer 2 diagrams. For long term development we also need to optimize the continuity circuit diagram, so that it can be justified in consuming less time and reducing costs. With a view to promoting the development of this industry, zKtube intends to release its source code after the mainnet is launched and provide some reference information for the industry.
Telegram: https: //t.me/zkTubeGlobal
Writer - lavender06