In our post back in October,we shared our commitment to furthering open-source ZK research. Since then, we’ve made tremendous progress on 2 major fronts:zkTreeand… today, we’re excited to introduce zkMint, Polymer’s solution that optimizes IBC across all major chains.
【资料图】
Context and Background
In ourmost recent article, we demonstrated how multi-hop IBC over an IBC transport hub like Polymer can bring the IBC transport layer to Ethereum and its ecosystem of rollups. To bring IBC to Ethereum,we need to be able to prove Tendermint consensus in the EVM.
In general, there has been anindustry wide shift towards verifying consensus proofsinstead of more centralized solutions. This improves upon the trust assumptions in the state layer. However, there are 2 primary challenges with verifying consensus proofs on-chain:
1.Are there any efficient light client algorithms for verifying the state of a counterparty chain?
2.Are the on-chain gas costs of verification practical?
With these 2 challenges in mind, Polymer set out on a journey to identify the most optimal solution.
The Journey
Before landing on zkMint, our team evaluated several potential solutions to the problem of proving Tendermint consensus in the EVM.
Our first approach was to directly verify Tendermint consensus on-chain. While there exists aTendermint light client implementation in solidity,it is impractical due to gas costs.Non-adjacent header verification costs more than 26 million gas per header.
Afterwards, wetried optimizing the signature scheme of the tendermint light client algorithmto be more EVM friendly. By swapping out ed25519 signatures for secp256k1 signatures, we were able to bring the gas costs down to 1.3 million gas per header. This was a nice improvement butstill not enough to be practical.
In addition,we evaluated threshold signatures and BLS m-of-n signature aggregation.The signing algorithm scaled extremely poorly with the size of the signing set in threshold signatures which ruled out this option. It implied requiring the use of a small subset of our Polymer validators for each signature. With EVM BLS pre-compiles currently nonexistent, on-chain verification is prohibitively expensive. Using BLS signature aggregation also required making every signers’ voting power equal.This would require CosmosSDK staking module changes, something we wanted to avoid.
Lastly, we looked at using zero knowledge proofs.There were challenges associated with converting the Tendermint light client algorithm into a circuit. The default algorithm requires protobuf serialization, several merkle proof inclusion checks, merkle root computations, and additional material changes.Instead, we modified Tendermint’s consensus algorithm to be SNARK friendly, creating what we call zkMint.This resulted in on-chain costs of 300k gas, a significant optimization of ~98.8%.
zkMint’s verification circuit for non-adjacent tendermint light client header verification algorithm
zkMint: the Solution to Connecting Cosmos and Ethereum
zkMint is Polymer’s multi-signature Tendermint BFT consensus enginethat can produce multiple signed headers per round of consensus. With zkMint, Polymer canoptimize the header format for any execution environmentthat Polymer connects to. For example, when connecting to the EVM, zkMint can choose an elliptic curve that is EVM friendly such as bn128. zkMint also allows Polymer to bebackwards compatible with light clients already deployed in the wild. The consensus engine for an IBC transport hub like Polymer needs to beadaptive to various execution targetsmaking zkMint the ideal solution.
Keep a lookout for the zkMint whitepaper that Polymer will be publishing soon. The paper includes an overview of Tendermint BFT consensus and formal proofs around the security of multi-signature Tendermint. You can also find our co-founder Bo Du presenting zkMint at ETH Denver on February 27th and 12:20pm on the #BuidlHUB Mainstage.
本文经「原本」原创认证，作者鸵鸟区块链，访问yuanben.io查询【4KQPCO1E】获取授权信息。