Will polymer make connections between EVMs with light clients? or is only the deployment of the vlIBC contracts and the relayers necessary?
I understand that the connection is Ethereum<>Polymer(IBC)<>CosmosHub (using light client). For Optimism<>Polymer(IBC)<>Arbitrum, do you also use light clients, or do you just deploy the vlIBC contracts on both chains and verify the messages using AMB?
Virtual IBC is a way to enable IBC for EVM chains through Polymer, but the connections, channels and packets are actually stored on Polymer on behalf of the virtual chain.
The vIBC core contracts are required to enable async communication of the state stored on Polymer for the virtual chain. But it’s important to understand that most of the action is happening on Polymer.
There’s still IBC clients required to verify that something happened on another chain but “light clients” is often understood as consensus proof based which is not the case when looking at a OP Stack rollup <> Polymer <> OP stack rollup connection (the rollups don’t have consensus but a client is still required).
Remember, the IBC client interface is just the interface. The actual verification methods can and will differ depending on what you’re connecting. See also IBC clients - reimagined | Polymer Developer Docs
Are the relayers permissionless?
They will be, as it’s the expected behaviour for IBC. Initially, the relayer might be centralized but still what it submits will be verified with proofs.
Thank you for your answer. I think I’m a bit confused, because of the IBC topology in Cosmos Chains (which is not the same).
So correct me if I’m wrong, in Polymer I will find this kind of clients (depending on what I connect to) IBC clients - reimagined | Polymer Developer Docs And on the rollup side and on the rollup side the interface?
Let’s say this is trying to emulate the IBC in cosmos?
I realize it can be a bit confusing. The IBC client specification is somewhat complex but let’s try again.
The IBC protocol specification demands an IBC client to satisfy certain interfaces. This is true for ALL IBC clients no matter where you are (chain in Cosmos, rollup on ETH, etc.) Read more about how to implement these here if you’re technical.
Now, in simpler terms what this client does is essentially:
It stores a state root of the chain/rollup it represents that is considered correct
It provides functionality to update the client (either update it with a new state root or freeze the client if there was proof of misbehaviour)
It provides functionality to verify state
Now, as you’ll see: this does not say much about how that state verification happens…
In most Cosmos SDK chains, people call these light clients that work by verifying that the proposed state root updates were signed by enough validators. A consensus proof.
For an OP stack rollup, it could be a proof that data was posted to a DA layer and a state root was proposed to the settlement layer to optimistically update IBC client, with support for fraud proofs.
For a ZK rollup, it could be a client taking validity proofs…