Patract’s zkMega and ZoPatract provide on-chain and off-chain support for zero-knowledge in Polkadot
This Thursday night, the Privacy On Polkadot online speech event initiated by ZKValidator was hosted by the founder of Patract — Lipeng Yue, the co-founder of Automata Network — Deli Gong, and the co-founder of Phala Network — Marvin Tong, the co-founder of Manta Network — Shumo Chu, the co-founder of zCloak Network — Zhang Xiao, etc. participated in privacy projects in the Polkadot ecosystem.
Here is the share from the founder of Patract — Lipeng,Yue
We are happy to join this event. Let me first introduce Patract Labs, we are a tech laboratory that provides solutions for the Polkadot Wasm contract ecosystem. We hope to accelerate the transition of the smart contract industry to the Wasm technology stack. As members of Kusama and Polkadot councils, we provide infrastructure-level support of tools and services to the community, and ZK is an important part of it.
Patract won’t issue our own tokens or launch our own parachains, but as a technology provider, helping the parachains of the entire community to integrate Pallet-Contracts, which is also called the Wasm contract module developed by Parity, and helping the entire community to develop Wasm DApps more smoothly. Therefore, we organized the Patract Open Platform, and this is the list of the existing members, about 10 parachains and 4 DApps, some of them are focusing on privacy and ZK.
Before introducing how we provide ZK support for Polkadot Wasm contract, we need to first understand the architecture of ZK in Ethereum. In 2017, Ethereum added three pre-compiled contracts through EIP196 and EIP197, which are about the ADD, MUL, and Pairing of the bn256 curve. They are based on the ZCash library and run on the native layer of Ethereum. Developers can continue to use Solidity to write the verification logic of the circuit and the application logic, which run on the EVM virtual machine layer. And continue to develop some off-chain programs for generating proofs.
At present, most of the zk-related Layer 2 projects have chosen to develop on Ethereum because of the three pre-compiled contracts integrated almost 4 years ago, the others tools were all developed by the community in the last 4 years. Therefore, we should first supplement Polkadot with such basic library support.
The parachains in Polkadot ecosystem are all based on the Substrate framework, having one more layer than the Ethereum contract, which is the Runtime layer based on the Wasm virtual machine. The community can develop different types of contract models, including EVM-compatible Frontier, Parity’s Wasm contract, and Libra’s Move contract. So above the Runtime is the contract layer, although we only focus on supporting the Wasm contracts, but the support of Native and Runtime layers can be shared with other contract models.
If a parachain project does not integrate the contract function after auctioning a slot, they can only develop a small number of ZK applications by themselves. And if they integrate contract function and provide the ZK capability of Runtime to the upper-level contract developers, they can support large-scale ZK applications and become a platform that supports ZK.
Native and Runtime communicate through the Runtime Interface, also called the Wasm Boundary. Runtime and Pallet-Contracts communicate through Chain Extension. Due to different running methods, Native has the highest execution efficiency, running 3 times faster than Runtime, and 10 times faster than Contracts. Since the complexity of ZK operations is very high, So the more these ZK basic libraries are placed at the lower level, the higher the execution speed will be, and the higher TPS can be achieved.
Design 1 — zkMega (Native version) in Substrate
Compared with Ethereum which only supports an old bn256 curve, zkMega hoped to also support another more efficient bls12_381 curve from the beginning. Later, Alistair from Web3 Foundation recommended the bls12_377 and bw6_761 curves by using the arkworks library, instead of ZCash. As mentioned above, we definitely hope to integrate the ADD, MUL, and Pairing of these four curves directly on the Native layer, and then provide them to Wasm contract to call through Runtime Interface and Chain Extension step by step. Then merge our changes in the Native layer upstream into Substrate repo.
If each curve has 3 Runtime Interfaces, the number would be large, and the entire Polkadot would also need to hard fork to support new curves, because the hot upgrade powered by the Governance can only update the Runtime layer running in Wasm.
Therefore, it is better to decompose the lower-level shared algorithms of these curves and then integrate them into the Native layer. In this way, the interface will be relatively fixed and the community can add the upper-level curves at any time, But the detailed design remains to be researched. Therefore, even if we develop the Native version, Substrate won’t agree with us to merge.
Design 2 — zkMega (Runtime version) in Substrate
If the Native layer cannot be changed, we can also add a Pallet in the Runtime, but the speed will be much slower. So we did the same work twice in the Native layer and Runtime layer, just the Native version cannot be used in the production environment, but only used as a benchmark comparison with our Runtime version.
Now the ink! contract can call these curves, so we also encapsulated an ink! contract library, including a higher-level Groth16 Verification function and three other small tool functions, making it more easier to develop upper-level applications. These are the commonly used functions of the existing Layer 2 contracts in Ethereum, which were previously written by the expensive Solidity, but now we use the more efficient Wasm or ink! contract to write, maybe 100 times faster than EVM.
Benchmark Result: Native Vs Runtime of Basic Units
By benchmarking the Basic Units of these four curves, the Runtime version is at least 5 times slower than the Native version. It is a big gap, but still acceptable.
Benchmark Result: Native Vs Runtime of Verification
By benchmarking the high-level Verification function, the gap between the Runtime version and the Native version reduced to only 2 times, due to the mixing of additional calculations in ink!, and the actual consumed time is about 60–170ms, which is still far less than 1s of the block calculation time, which is also practical. In the future, we need to work together with W3F to study how to design the Runtime Interface for Substrate to improve the executing efficiency of these basic libraries.
ZoPatract: Off-chain toolbox for zkMega and ink!
The above is our work for v0.1. in v0.2 we added support for off-chain tools. We migrated the famous ZoKrates so that it can support ink! contracts and zkMega. We named this project as ZoPatract, which has also been released. Through ZoPatract, developers can easily do operations such as Compile, Setup, Compute witness, Generate Proof and Export verifier. Our plan for 0.3 was to develop a sample zkRollup transfer application based on zkMega and ZoPatract, but don’t have the time yet. For anything else helpful for the ZK Wasm contract, we will embrace it.
Links about zkMega & ZoPatract
Here are some links about the design, source code and report, we will share it in our groups.
Source code
https://github.com/patractlabs/zkmega
https://github.com/patractlabs/ZoPatract
Proposals
Report
Self development report of v0.2
About Patract
Patract is providing solutions for the development of Parachains and DApps in the Wasm smart contract ecosystem of Polkadot. We help the community to design and develop on-chain contract modules and Runtime support, and provide DApp developers with full-stack tools and services support, covering development, testing, debugging, deployment, monitoring, data provider and front-end development stages.
