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 it 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:
1. Long time consumption problem of zero-knowledge proof
2. Compression processing problem of zero-knowledge proof
3. Support general contractual problems
Technology improvement of zkTube
- Bulk packaging and state root isolation
ZkTube separates the process of submitting batch to Layer2 for trading and of submitting the state root by the way of independent bulk packaging.
Different from the previous ways, zkTube separates batches, sorts them by time, and then proves, verifies, and updates the root state when these batches are submitted to 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 the 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, the 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 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 resistant 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 characteristics in specific scenarios, including deposit, withdrawal, 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 the 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 much 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.
Conclusions
We have optimized and improved the above aspects to provide a better Layer 2 scheme for zkTube. But from the perspective of long-term development, we also need to optimize the circuit scheme constantly, so that it can be proved in less time consumption and cost reduction. Of course, from the perspective of our optimized effect, this is where we are more advanced than zksync. With a view of promoting the development of this industry, we intend to release our source code after the mainnet is launched, and provide some reference for this industry.
If you want to know more information about zkTube, please feel free to contact us in the following ways.
Follow Us
Web: paytube.io
Mainnet: https://zktube.io (off-line)
Telegram: https: //t.me/zkTubeGlobal
Discord: https://discord.gg/YSXSRps5
Twitter: https://twitter.com/zktubeofficial
Medium: zktube.medium.com
Facebook: https://www.facebook.com/zkTube.io/
联系我们
Contact us
Email: [email protected]