SNARK friendly Tendermint BFT consensus protocol by Supragya Raj and Bo Du

Hey everyone, my name is Bo. I'm a co-founder at Polymer Labs and I'm here today to talk about ZK Mint, the first ZK friendly tenerint consensus engine. Who here in the audience has heard about IBC? Nice. Who here in the audience has heard about ZKPS?

And who here in the audience has heard about Tenderman consensus? Awesome. Also, a special thanks to Raj from our team who couldn't be here today had some visa issues and he's the original author of the paper that we'll be releasing soon on this subject. So, a little bit about Polymer Labs. We're building the IBC transport hub to connect all chains via IBC starting with Ethereum and its ecosystem of roll-ups.

We're also core contributors to the open source IBC protocol and are working on IBC making IBC the standard transport layer across all chains. I know some of the previous speakers had mentioned that perhaps bringing IBC to Ethereum was impractical. Um we're currently working on on that and Polymer Hub brings just does just that. We're able to both bring the state layer of IBC and also the transport layer of BBC including the applica application layer semantics on top to Ethereum and and its ecosystem. So here are some goals of the talk today.

We're going to cover some background context before talking about some of the issues that we encountered uh in our journey to efficient verification of tenement consensus in the EVM. We'll also go over some of the intuition behind the security proofs in our soontobe released paper and also some of the performance measurements associated with our solution. So what is IBC? IBC is an interoperability protocol. It's currently the most decentralized, permissionless, and secure open- source interoperability protocol on the market.

An interoperability protocol consists of three core functional layers as depicted uh in the diagram here. You can see that there is an application layer which is analogous to HTTP and gRPC. In the OSI model, we can see that there is a transport layer which is analogous to TCP and UDP in the OSI model. And we can see that there is a state layer which is analogous to the physical network links that connect computers. So we're building the IBC transport hub to bring IBC transport layer to all chains.

In order to connect IBC to Ethereum, we first need to establish an IBC connection via light clients as part of the state layer shown here. This requires onchain verification of tenderment consensus which is problematic. So does anyone think there are any issues with verifying tenderment consensus in the EVM? Well, the problem is the gas costs for verifying tment consensus are just too damn high. In the next slide, we're going to go over some of the main cost drivers for verification.

So, starting off, the default tment uh the default signature scheme utilized in tournament consensus is ED25519. Unfortunately, there are no verification pre-ompiles for this signature type in the EVM. Additionally in ten default tenement consensus the validator set is supplied as a Merkel route which means that we end up with a number of Merkel proof op operations in order to check for validator inclusion and also validator set hash equivalents. A nonvm friendly hash function further impacts the performance of these signature checks of these Merkel ops. Tenement headers are also proed protoenccoded before serializ before uh signing.

So this means that we also need to do proto sererialization and des serialization to perform signature checks. In summary, with all these challenges, EVM verification of tenment consensus was previously not feasible. Well, let's embark on a journey together towards efficient verification of tenderment consensus in the EVM. So the first thing we looked at was optimizing the naive tenderment verification algorithm in the EVM. We changed the signature scheme and hash function.

This resulted in the performance gain, but it was ultimately insufficient uh for practical use. Threshold signatures are a subset of MPC or multi-party computation that allow for the sharding of a single private key into multiple secret shares uh to allow for efficient signing via a single signature. When we evaluated this the unfortunately the P2P communication overhead impacted the key generation and also signing algorithm also there was some implementation complexity due to this approach with key regeneration due to valet changes. Signature aggregation is an approach of combining multiple signatures into one. We looked at BLS MAN signature aggregation for our use case.

Unfortunately, there were no uh BLS M ofN verification pre-ompile in the EVM as well as uh some implementation complexity requiring equal voting power between signers cause us to drop this approach as well. Ultimately, we ended up arriving on a ZK approach which appeared to be a a costefficient method of verifying headers and also a viable path forward. So proving a circuit for tenderment BFT consensus is slow. Some of the reasons for this is that you have a large circuit size due to snark unfriendly hash functions, Merkel proof operations for validator set inclusion and validator set hash equivalence, non-native field arithmetic uh and also complicated serialization format. Though proving a circuit for Tenement BFT consensus is too slow.

We need a version of consensus that is efficient to prove in a snark circuit. And although Tenement offers multiple levers to configure the consensus algorithm, we also need this consensus engine to be backwards compatible with existing tender light clients deployed in the wild. So what is the solution here? Well, we need to improvise, adapt, and optimize our headers for each execution target. And by doing so we get ZK mint.

ZK mint is a multi- signature tenderintment BFT consensus protocol. This means that we can be backwards compatible with existing light clients deployed in the wild as well as generating new headers for uh specialized for various execution targets such as snarks and EVM. This adaptability makes it the ideal consensus engine for an IBC transport hub like polymer. However, multi- signature consensus introduces uh novel attack vectors. So, how can we prove that the new protocol is secure?

So, there's not enough time to go over all the security proofs in our paper. So, we'll try to motivate an intuitive understanding using this diagram here. Tamman consensus is a two-step process. We begin with a lock and then a commit on a particular header. Once a header is locked by two/irds of the honest validator set, then the chain can only ever proceed to this locked header or halt.

This means that we're trying to guarantee that a step forward attack will not cause like clients to fork away from the main chain. A step forward attack is defined as an attack where validator set signs a subset of the headers required for the chain to progress uh thereby tricking the light clients to advance first without advancing the chain itself. But because as you can see in the diagram above, once we've locked on the header in the middle, we can no longer proceed to the header above or the header below. Now that we've gone over some of the highle uh intuition behind the security of the protocol, what what were the actual header optimizations that we made in order to make the it more efficient to prove and verify in a snark circuit? So we started off by picking a snark and EVM friendly signature scheme.

We ended up changing the underlying elliptic curve for EDSA from curve 25519 to BN128. There are alt bn128 pre-ompiles in the EVM for scaler multiplication and addition. The native field and curve used in the snark uh construction matters. And the reason for is for this is because the snark verifier sits onchain and needs to be EVM friendly for optimal gas costs. For elliptic curve pairing based snarks, the verifier needs to perform a few pairing checks in order to verify a proof.

We also selected a snark friendly hash function in MIC7. We also replaced a number of the Merkel proof inclusion checks by supplying the full validator set as a private input to the circuit itself. We also removed proto serialization and replace it with a much simpler serialization scheme inspired by flat buffers. So after all these optimizations, what did the performance numbers look like? Well, with default tenement consensus and a naive approach, we get onchain verification costs of 26 million gas with some optimizations in the signature scheme used.

Uh we can get slightly better numbers with 8 million gas. Ultimately, with our snark construction unoptimized circuit, we can get an onchain verification cost of 300k gas, a prover times of around 3 seconds, and a circuit size of around roughly 500,000 gates. This is a 98% reduction in the gas cost from naive verification. This equates to roughly $6 to $10 at today's Ethereum price and network utilization. Obviously, uh these costs depend on Ethereum price and network congestion.

With these per PF improvements, it becomes practical to establish a state layer connection to Ethereum. So, ZKMin is a first step towards bringing IBC to Ethereum by establishing state layer connectivity. However, state layer connectivity is just the first layer of a working interoperability protocol. What's most important is bringing the IBC transport layer to Ethereum. So unfortunately there are an ever growing number of interoperability protocols in the Ethereum ecosystem.

All of which are inventing new transport layers. The problem with competing transport layer implementations is that they make different interoperability protocols incompatible with one another. A unified transport layer under IBC will make interoperability protocols actually interoperable with one another. Supporting competing transport layers is promoting fragmentation, not interoperability. Promote interoperability instead by building with IBC.

So, it's easy to confuse interoperability protocols with one another as many begin to adopt IBC application layer semantics and state layer semantics. Many of the interoperability protocols launching today are focused on application side and state layer side innovations making them not interoperable with one another. But you don't want to confuse the application layer of the interoperability stack with the transport layer of the interoperability stack. That would be confusing HTTP for TCP. Build with IBC instead.

Thank you. I'll be uh available for for questions uh off the stage. Thanks guys.