Announcing Optimistic ZK IBC Connections

Feeling optimistic about Zero-knowledge (ZK) IBC? So are we at Polymer! One misconception we’ve picked up from the community and want to clarify though… Polymer is not only enabling ZK-IBC connections. As mentioned in our modular IBC article, Polymer will enable many flavors of IBC, including Optimistic IBC connections. Let’s revisit the analogy we draw between the interoperability model and the Open Systems Interconnection (OSI) Model to clarify.

• The application layer represents application logic that sits on top of the common transport layer.
• The transport layer of IBC encodes transport, authentication and ordering (TAO) logic, inspired by TCP/IP.
• The state layer defines how state is moved (and proven) from one chain to its counterparty.

Separation of these layers is incredibly important. It allows for modularity and separation of concerns. For Polymer, it also enables other great design principles…

Transport layer standardization. State layer flexibility. Polymer-IBC.

The separation between application and transport layers has been present and broadly understood since the inception of IBC. However, there was no explicit distinction between transport and state layers. As a consequence, many have come to believe that on-chain light clients are the only state layer solution compatible with IBC.

This is where Polymer innovates. We believe the transport layer is the defining layer of any interoperability protocol and transport layer standardization is crucial! Without it, fragmentation will rule the interoperability landscape. The transport layer produces a commitment to all of the messages sent and received from a chain while also enforcing TAO (transport, authentication and ordering) logic. This commitment is called a transport commitment.

Crucially, because of the modular nature of the interop model, transport layer standardization does NOT stand in the way of state layer flexibility and innovations. Indeed, we believe that the different interoperability protocols of today can opt in to become IBC clients in the IBC network of tomorrow.

In a nutshell. Polymer does enable ZK-IBC. But it also enables optimistic IBC. It enables modular IBC. We could continue. Polymer’s endgame is to support any flavor of IBC, on any type of chain.

We strongly believe that transport layer standardization (and the network effects that come with it) goes hand in hand with bleeding edge innovations at the state layer, which allow for design flexibility and addressing trade-offs.

Polymer’s endgame is to support any flavor of IBC, on any type of chain

Optimistic IBC? Yes! ZK-IBC? Yes! Optimistic ZK IBC?? Hell yes!

Bear with us for a moment. Polymer’s zkMint and zkTree innovations provide a considerable reduction in cost to compute and verify consensus proofs on-chain. However, the cost and latency could still prove prohibitive in highly congested networks, requiring different approaches. Remember the design flexibility mentioned before? This is a good example of how we can start thinking about different solutions on the state layer.

Enter Optimistic ZK IBC connections. The high level solution to bypass the cost and latency trade-off is to implement a combination of both optimistic and ZK proof verification.

What’s that now? It’s a solution that looks as follows:

• On the target chain, Polymer (IBC router hub) state roots are optimistically accepted on-chain. This requires leveraging the stake on Polymer for security.
• ZK fault or fraud proofs can be submitted by anyone to prove misbehavior (at any time, even after the fraud window ends).

How does this solution affect the cost versus latency trade-off?

Consider that verifying the cheapest ZK proofs on-chain cost approximately 300k gas in the EVM. As a consequence it can take a long time before enough relayer incentives accrue to make it economical for a relayer to submit a client update.

On the other hand, optimistic verification alone forces an undesirable minimum bound on latency.

Combining both optimistic connections and ZK proof verification techniques however, provides dynamic latency with the following desirable properties:

• An upper bound on latency
• Lower latencies are possible when relayers are properly incentivized
• Reduced cost of connection maintenance

Stay tuned

Further details on implementation and design considerations are to follow, but we’re pretty excited about this announcement and we did not want to keep it from our community. We believe this to be another step towards a vibrant IBC ecosystem with transport layer standardization and state layer innovations.

About Polymer

Polymer is the first modular IBC-based networking protocol. The Polymer chain will enable ZK-IBC connectivity across all integrated chains with a trust-minimized architecture based on light client state proof verification. Polymer believes in a multichain future connected primarily by one open-sourced, community-developed, and maintained industry standard, IBC x Polymer.

Follow our Twitter, visit our Website, and join our community on Discord! Sign up to become a validator here and to take part in Polymers private testnet here.