By @MixWeb3, Organized and created based on @Louis Liu speech content
On February 23rd Beijing time, Louis, the founder of Octopus Network, was invited to participate in the Cosmos Cross-Chain Ecological Summit jointly organized by IBCL and Token DAO. He delivered a speech titled “Making IBC Adaptive by Verification Proxies” and conducted a deep analysis on how to make IBC more adaptive and provided solutions.
Octopus Network is a multi-chain network project built around the NEAR blockchain and is also a builder of the Cosmos ecosystem. We believe that IBC is the best open protocol system for solving general cross-chain issues, so we have been working on IBC development since 2020.
The ICS10 of Cosmos IBC specification is proposed and maintained by Octopus Network. At the same time, we have also proposed ICS11, which is the NEAR Client, currently under review and will become part of the IBC protocol family if approved.
Octopus Network has also organized the production of Chinese documentation for IBC, which was translated by web3crypto.eth, Jeffrey Hu, and some developers from the Chinese Cosmos community, covering all core IBC protocols.
From the end of last year to the beginning of this year, HashKey Capital, Octopus Network, Bianjie.ai, Cosmos Chinese, IBCL Community, and Wanchain Blockchain Labs jointly organized the Cosmos SDK Chinese Developer Training. More than 150 people registered and 35 students were admitted and successfully completed the training. This should be the first batch of Chinese Cosmos SDK developers. We hope that our future Chinese Cosmos developer community will continue to grow and become more active.
Octopus Network has been working on Substrate IBC development since 2020. The project received seven milestones from ICF Grants, and six of them have already been accepted, which means it is close to success. After the final milestone is completed, Octopus will collaborate with Polkadot’s star project Astar to create a Polkadot-Cosmos cross-chain bridge. According to the current plan, this cross-chain bridge is expected to go live in the second quarter of this year. It will be the first IBC cross-chain bridge from Tendermint chain to heterogeneous chain. Octopus is also working on NEAR IBC to connect NEAR to the Cosmos network. Therefore, Octopus hopes to make IBC a truly universal cross-chain protocol, not limited to the Cosmos network. To achieve this goal, Octopus has conducted a lot of practice and reflection, and this sharing is a summary of how to make IBC more adaptable.
IBC is an open and layered cross-chain protocol system. Its protocol framework, called IBC TAO, supports various applications. The first and most widely used is ICS 20, which is Fungible Token Transfers that allows the transfer of fungible tokens between chains. As mentioned earlier, ICS721 can also be used to transfer NFTs in cross-chain scenarios.
At the bottom layer of IBC is the Light Client, which allows two chains, A and B, to run each other’s Light Client on their respective chains to directly verify the consensus of the other chain. A Relayer is needed to transmit cross-chain messages and trust roots between the two chains. The trust root usually refers to the block header of the other chain, which, when obtained and verified, can be used as a trust anchor to verify specific cross-chain messages. The entire design of IBC is based on Light Client verification, which is considered the gold standard for cross-chain security.
In the design of actual cross-chain bridges, we face the impossible triangle problem. This problem is prevalent in the blockchain field and is a framework for making trade-offs among several main factors, which cannot be achieved simultaneously.
In cross-chain design, if the two chains are determined, we need to balance security, cross-chain cost, and cross-chain latency. The cost of cross-chain is mainly caused by the verification cost of the trust root. Why can the verification cost and cross-chain latency be traded off? Because when synchronizing the trust root between the two chains, the higher the frequency, the higher the verification cost, and the faster the synchronization, the more timely it can verify cross-chain messages, so the latency will be smaller. Of course, security is also a dimension to be considered. If the verification limit is relaxed, the cost will decrease. Therefore, in the design of actual cross-chain bridges, there is always a need to make trade-offs among various factors, and it is impossible to fix one attribute completely. For example, the security must be the highest level of security, which may ultimately result in a bridge that is either too expensive to accept or too slow for users to tolerate.
In actual cross-chain design, Cross-Chain Security is not a single point, but a spectrum that needs to be balanced with other factors. Cross-chain technology can be divided into four categories, with the most important being Native Verification and External Verification.
Native Verification refers to the ability of the target chain to directly verify the consensus of the source chain without relying on third parties. The most classic example of this is Light Client verification, which is used in Cosmos IBC. In addition, a series of ZK-based cross-chain designs have emerged, using zero-knowledge proofs to provide an equivalent verification to Light Client. The security level is also basically equivalent to Light Client and is mathematically equivalent.
External Verification means that the target chain does not directly verify the consensus of the source chain but relies on third-party verification. The target chain trusts the third party, which may be a chain-like setting whose security comes from staking. Examples of this type include Axelar, Celar, Ren, and Hyperlane. Alternatively, the security of the third party may not come from staking or cryptoeconomics, but is reputation-based. Examples of this type include Wormhole, Ronin, Avalanche and Ethereum cross-chain bridges, as well as Layerzero.
There are also two sub-categories between the two main categories. OP Verification is essentially intended for Native Verification, but verification costs are too high, so verification is not performed and errors are eliminated through challenges. After submitting the trust root, a challenge period is left. If someone successfully challenges during the challenge period, the person who submitted the false trust root will be slashed. If no one challenges during or after the challenge period, or no one is able to successfully challenge, the trust root can be used for verification. OP Rollup and the main chain’s cross-chain bridge are actually OP Verification. Rainbow Bridge from NEAR to Ethereum is OP Verification in the NEAR to Ethereum direction, and Light Client Native Verification in the Ethereum to NEAR direction. Nomad also belongs to optimistic verification.
There is also a small category called Validator as Oracle, where each validator on the target chain independently observes the consensus of the source chain and votes on the target chain to decide whether to reach consensus on the consensus of the source chain. If consensus is reached, the trust root is approved because it does not introduce a trusted third party. Therefore, it does not belong to External Verification, but rather the trust of the validator set on this chain. This technology is used by Polygon Bridge, Gravity Bridge, and Octopus Bridge. However, this technology should only be considered in special cases where the source chain is particularly important to the target chain, and it is possible for each validator on the target chain to observe the source chain. Therefore, VaO is not a universally applicable general cross-chain technology. However, its security is close to that of Native Verification, and it does not require a trusted third party.
Therefore, in actual cross-chain bridges, it is necessary to balance security, cost, and latency.
The biggest challenge in extending IBC to other chains is the issue of Light Clients. This is because Light Clients were not designed for cross-chain interoperability; they were originally developed, for example, as SPV in Bitcoin, to enable reliable observation and usage of a blockchain on devices with limited resources. The current use case of Light Clients, more accurately called On-Chain Light Clients, involves running a Light Client of another chain on a given chain. However, this design is not the classic use case for Light Clients. While many blockchains consider Light Client Friendliness when designing their consensus mechanisms, they may not necessarily take into account the need for Light Clients to operate on other chains.
Cosmos has been successful in implementing Light Client Verification due to Tendermint’s design for supporting a blockchain internet. Tendermint’s Light Client has already taken into account how to support cross-chain interoperability, giving Cosmos a unique advantage.
Therefore, when extending IBC to other chains, the main issues are whether there is a secure Light Client available and whether the cost of Light Client verification is acceptable.
We believe that the IBC model can be more flexible, so we introduce a role called the Verification Proxy. When a Relayer receives a trust root from Chain A, they call the Verification Proxy for validation, which generates a proof. This proof is then validated on Chain B, rather than directly verifying the consensus of the original chain. With this architecture, various intermediate technologies, including external validation, can be accommodated within IBC, making it more adaptable to heterogeneous chains. Thus, we call this Adaptive IBC architecture.
Adaptive IBC may face two challenges. First, IBC proponents may argue that this is not a Light Client. Does compromising security still qualify as IBC? Later, we will answer this question, as Adaptive IBC does not necessarily sacrifice security.
Secondly, those who are not entirely convinced about IBC may argue that since we have already introduced a verification proxy, why bother with IBC? Why not simply build a cross-chain bridge that uses external verification? Our response is that IBC is an open, layered protocol. We can maintain IBC’s app and framework while evolving the verification layer separately. For example, if it is not possible to implement a Light Client in the short term, we can use a multi-signature-based verification proxy instead. In the future, this can evolve into a POS-based proxy chain, similar to Axelar/Thor Chain’s design. Alternatively, once ZKP becomes cost-effective in proving the consensus of the original chain, we can upgrade the verification proxy to use ZKP. Throughout this evolution, the application layer’s interface can remain unchanged, meaning that application development is not affected. As we know, upgrading applications on a blockchain is very difficult and requires effective governance and special design. By using a layered design and separating the verification layer, communication layer, and application layer, we can make the verification layer evolve independently, enabling it to adapt to more consensus designs of various blockchains and gradually improve security without affecting application development. Therefore, we believe that Adaptive IBC is meaningful.
The purpose of developing this model is not to come up with a new term for external verification, but rather to generate a systematic framework for considering what kind of verification proxy is meaningful.
First of all, it must have a cost advantage. The cost of proxy verification should be much lower than direct verification for the method to be effective. At the same time, Verification Proxy is a part of the cross-chain bridge. Since the degree of decentralization of a cross-chain system is determined by its most centralized part, the verification proxy itself should also be decentralized. Following this logic, many verification proxies are currently being developed as blockchains, which should have Trustless, Permissionless, and Censorship Resistant properties. Therefore, we can evaluate verification proxies through the Adaptive IBC framework.
Some cross-chain bridge projects use TEEs as verification proxies, but I am not optimistic about this design. TEE is a black box, and it is difficult to make a trusted initialization and its state is not visible. In other words, TEE does not have publicly verifiable properties. Even whether a cross-chain bridge is actually running TEE cannot be verified. Regardless of right or wrong, there is no way to verify it. So I feel that verification proxies based on TEE are not very compatible with blockchain or crypto.
We are also considering making verification proxies a dedicated chain, and whether it is possible to implement them on public chains. As long as the conditions for cost savings still hold, then the public chain has Trustless, Permissionless, and Censorship Resistant properties. This is why Octopus is trying to use ICP as a verification proxy, because the verification proxy on ICP is publicly verifiable and has high security. The output of ICP Smart Contract can be threshold signed, and the verification cost is extremely low, which easily meets the cost savings formula.
Moreover, verification proxies do not necessarily sacrifice the security of the cross-chain system. We have two perspectives on the security of decentralized systems, one of which is the “trust set” perspective. For example, IBC only needs to trust the original chain and the target chain, and relies on the activity of the relayer. Now with the introduction of Verification Proxy, the trust set expands, so the security is compromised. From this perspective, the introduction of verification proxies will inevitably reduce security.
There is another perspective to consider, which is quantifiable security. The cost of an attack is always greater than the potential gains, so the system is secure. Therefore, well-designed centralized systems should be able to quantify the cost of an attack. For blockchain systems based on PoS/BFT consensus, the Attacking Cost has two levels: if more than 33% of validators collude, the chain can be deactivated, and if more than 2/3 of validators’ voting weights are controlled, the chain can be compromised. As shown in the above figure, we draw a line, where the security of the original chain depends on its attack cost, and the security of the target chain also depends on its attack cost. If the attack cost of the verification proxy is higher than that of either chain, or even higher than both chains, introducing a verification proxy will not compromise the security of the cross-chain bridge.
中文版｜章鱼网络 Louis：通过验证代理让 IBC 适配非 Cosmos 区块链
Disclaimer: This article is for reference only and should not be used as legal, tax, investment, financial or any other advice.
Follow Octopus Network!
Website: https://oct.network
Doc: https://docs.oct.network
Github: https://github.com/octopus-network
Email: hi@oct.network
Twitter: @oct_network
Telegram: https://t.me/octopusnetwork
TelegramZN: https://t.me/octchinese
Medium: https://medium.com/oct-network
Discord: https://discord.gg/6GTJBkZA9Q
Making IBC Adaptive by Verification Proxies was originally published in Octopus Network on Medium, where people are continuing the conversation by highlighting and responding to this story.