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: zkTree and… today, we’re excited to introduce zkMint, Polymer’s solution that optimizes IBC across all major chains.
Context and Background
In our most 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 an industry wide shift towards verifying consensus proofs instead 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.
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 a Tendermint 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, we tried optimizing the signature scheme of the tendermint light client algorithm to 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 but still 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 engine that can produce multiple signed headers per round of consensus. With zkMint, Polymer can optimize the header format for any execution environment that 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 be backwards compatible with light clients already deployed in the wild. The consensus engine for an IBC transport hub like Polymer needs to be adaptive to various execution targets making 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.