Pioneering Blockchain Interoperability: Octopus Network’s Adaptive IBC Embraced by Secret Network
After three years of working on heterogeneous IBC implementation, Octopus Network has developed a solution called “Adaptive IBC” to break the extensibility bottleneck of IBC. Secret Network, one of the longest-running confidential computing blockchains, is set to become the first user of Adaptive IBC in the first quarter of 2024. This integration marks a significant milestone as it establishes the first connection between the Cosmos and NEAR ecosystems, expanding the interoperability of the IBC protocol.
On November 21st, 2023, Octopus joined a Twitter Spaces session hosted by Secret Network to discuss this partnership in more detail. This engaging discussion covered why Octopus decided to work on IBC, the idea behind adaptive IBC, why Secret decided to use Adaptive IBC, and what we can expect from the collaboration between Octopus and Secret Network.
To dive deeper into these discussions, check out key excerpts below. For the full experience, the evergreen audio recording is available on Youtube.
Octopus and its Unique Approach to Multi-chain Network
Patrick (Head of Partnerships, Secret Network Foundation): Let’s start with the basics of what Octopus Network is, especially for those within the Secret Network who have never heard of you guys.
Louis (Founder, Octopus Network): Octopus Network is a multi-chain network built around NEAR Protocol. When we started our journey, just like many blockchain developers and researchers, we tried to figure out a way to jump out of the blockchain trilemma, which means breaking the scalability bottleneck while maintaining a sound level of security and decentralization. We found that a multi-chain network is the most appealing approach to us. Individual blockchains can be optimized for specific use cases, resulting in chains with special functions or capabilities. These can include appchains, Oracle chains, private computing chains, storage chains, and even AI computing chains. And then, with an open and pervasive protocol, we can connect all of these specialized appchains into a network. By doing this, we essentially break the bottleneck of performance and customizability.
We learned this multi-chain network vision from Cosmos, but we have a different approach. We believe that the Internet of Blockchain, or the multi-chain network, should be built around a public blockchain. All the appchains, as well as all the special-purpose blockchains, can share security from the Hub. Additionally, all the special-purpose blockchains can aggregate their trading liquidity into this Hub. It’s not a mandatory process, but it will likely be the case, considering the network effects of liquidity, which means liquidity attracts liquidity. We call this design philosophy the “FatHub Thesis”, which is apparently the exact opposite of Cosmos Hub’s minimalism philosophy. We chose the NEAR protocol as the FatHub. And then we built a quite complex collection of smart contracts on NEAR, which facilitate shared security to special-purpose blockchains around it and also serve as the interoperability Hub.
We started to build Octopus network about three years ago. The mainnet went live in October 2021. Now, we have five appchains running inside Octopus Network. They share security from NEAR protocol, and their trading requirements rely on NEAR DeFi. Basically, this is the journey so far.
Patrick: People within Secret are pretty familiar with how the Cosmos Ecosystem has the Cosmos Hub, and then we also have a bunch of different appchains and other Layer 1 networks, all built with the Cosmos SDK technology. So is that kind of a similar relationship that Octopus Network has with NEAR Protocol, with NEAR Protocol being kind of thought of as the Hub. And is it similar to the Cosmos idea of lots of interconnected chains?
Louis : Yeah, we try to mimic the topology of Cosmos within the NEAR ecosystem. The core NEAR Protocol is mainly about a sharding public chain, but from the NEAR Foundation’s perspective, Octopus Network is a complementary infrastructure that allows NEAR Protocol to embrace appchain developers and diversify their offerings to Web3 developers.
Adaptive IBC: The Game-Changer in Heterogeneous Blockchain Interoperability
Patrick: Octopus Network also incorporates a form of the IBC protocol, which I believe is a custom solution that your team came up with called Adaptive IBC. Could you tell us a little bit more about that?
Louis: From the very beginning, we believe that an open, generic purpose interoperability protocol is the heart and soul of the Internet of Blockchain. And IBC stands in a unique position to realize this value proposition. Our cooperation with ICF began three years ago. We signed a grant contract with ICF even before we started Octopus Network. And since then, we have been building the IBC implementation first on Substrate, which is the Substrate IBC. And we are not the only ones working on heterogeneous IBC implementation. There are other teams that have found this heterogeneous IBC implementation meaningful. These include Composable Finance, Data Chain, Polymer, and others. We are not competitors. We believe in the same vision of the blockchain Internet and strive to contribute to the open-source community in our own way.
At the beginning of the Octopus Network, it only supported Substrate-based Appchain. Now we are expanding the coverage to Cosmos SDK starting from Octopus 2.0, which is scheduled to launch next month. Therefore, the first thing we want to ensure is that there is a robust interoperability infrastructure on NEAR to work with the Cosmos chain. As a result, we have initiated the work on NEAR IBC.
Our Substrate IBC and NEAR IBC are based on the concept of Adaptive IBC. This design aims to break the extensibility bottleneck of IBC. IBC is great. And the unique characteristic of IBC is about light client, which makes it trustless. However, this same characteristic makes it challenging to extend to blockchains other than Cosmos. I think Cosmos is an exceptional case because they designed the consensus with the light client in mind. Tendermint, from the very beginning, was designed to be a consensus protocol that supports a node in the blockchain Internet. Therefore, there is very good on-chain light client information for Tendermint. But the other protocols, they do not design their consensus with interoperability into consideration from the beginning.
Lisa (Executive Director, Secret Network Foundation): Because while Cosmos was built with collaboration and consensus in mind, a lot of these other blockchains just were not. I think that’s why what you’re doing is so important, because you’re building those bridges to make up for that lack in the original design, right?
Louis: Right. The IBC extension to other blockchains is very challenging. Even though there are many teams working on IBC implementation besides the Cosmos chain, there is no widely adopted IBC bridge between Cosmos and other blockchains. The main reason is the implementation of light clients and the cost. We need a better-tested on-chain light client, and the verification cost should be reasonable for user interaction. We have been dealing with these difficulties for 3 years. As a result, we have come up with a solution called Adaptive IBC.
The native IBC is about verifying a cross-chain message from the source chain on the target chain by leveraging a light client in the runtime of the target chain. However, this on-chain light client is either too expensive to run or without proper implementation. In most cases, there is no light client that can run inside the Cosmos chain to verify other consensus, such as the consensus of the NEAR Protocol. Our solution is to bring this light client from the target chain to the second chain, which we can also refer to as a proxy chain. Instead of running an on-chain light client on the target chain, we can run a light client on a proxy blockchain with a better cost structure, lower gas fees, and better extensibility. The light client will verify cross-chain messages on the proxy blockchain and provide proof that these messages represent events on the source chain. This solution remains trustless and decentralized because it incorporates a new decentralized system in the form of a proxy chain. The proxy chain is responsible for verifying the integrity and validity of the cross-chain message and provides proof. The target chain only needs to verify this proof obtained from the proxy chain, using a highly cost-effective method. As a result, the cross-chain message is acknowledged as a legitimate message. This is the fundamental concept behind Adaptive IBC.
And when we talk about Adaptive, there are two meanings. One is that this architecture can be adaptive to many blockchains like NEAR, Polkadot, Ethereum, and even others. The first production level of Adaptive IBC will be NEAR, but we have a plan to expand this architecture to cover other blockchains. The other meaning of being adaptive is that we can adapt to the progress of the verification method. Once we have a usable light client that can directly verify cross-chain messages on the target chain, we can do a channel connection upgrade to replace this proxy client with a real on-chain client. Or if we have a workable ZK consensus proof, we can replace this proxy chain with a ZK bridge. So we can embrace the progress of validation technology.
Patrick: So I guess you could say that Octopus Network, while NEAR Protocol is your initial focus, you can think of Octopus Network more as an interoperability hub that will connect a variety of different chains?
Louis: Yes, we help NEAR connect with many other blockchains via IBC, starting from Cosmos-based blockchains. I would say NEAR IBC is a public good that Octopus contributes to the NEAR ecosystem. It is open source and there is no meaningful value capture mechanism in NEAR IBC.
Lisa: I was curious what you see as the next step for the adaptive IBC?
Most likely connecting to Ethereum. So Ethereum is apparently the single biggest target we try to approach. And it’s not only us. There are many teams working on Ethereum IBC or EVM IBC. I think the major credit should be entitled to the Data Chain team. It’s a Japanese developer team. But the most difficult part is still light client verification. By leveraging our adaptive IBC design, I think Octopus has a good opportunity to be the first one to provide an affordable and secure IBC connection between Ethereum and other IBC-enabled blockchain.
Patrick: Is that where the name Octopus comes from? Like, an octopus has many arms connecting to many different networks?
Yes. Octopus is a marvelous creature. They have neural units on each arm. So, essentially, each arm can think independently. It’s a natural form of decentralization.
Upcoming Integration with Secret Network
Vivi (Partner, Octopus Network): I would like to hear from the Secret Network team why Secret decided to use the adaptive IBC. What does the partnership mean for Secret Network?
Alex (CEO, SCRT Labs) :So for Secret, in the past several months, we have realized that our mission in the blockchain space is to extend beyond our own blockchain and offer our unique capabilities to other blockchains. Currently, there are numerous blockchains in existence, with more L1s than applications surrounding them. While I haven’t verified this, it may very well be true. New L1 blockchains are emerging daily, each with their own distinct properties. Of course, we all realize that maybe all the apps will move to one blockchain, but it’s hard to imagine that they will be running on all the blockchains at the same time. So essentially, in the end, it looks like the EVM ecosystem is the bigger one with most of the apps happening there, but there’s a lot going on in Solana, there’s a lot going on in Cosmos, and also NEAR, and some others. We believe that in the end of the day, every L1 will have its specialty, such as speed, cost-effectiveness, security, and the confidentiality that Secret provides. Not only is confidentiality our unique feature, but we are also the oldest and longest-running confidential computing blockchain, so we have a huge head start in this space.
Maybe initially, we had the idea of bringing all the apps to run on Secret. However, we realized it may have been a utopia, or maybe it was a viable dream back then, but now we see that it doesn’t happen. Instead, our focus shifted to bringing Secret to everyone. This means enabling developers on various blockchains to develop privacy-conscious applications, and there are multiple use cases for that. As Louis explained in his technical explanation, connecting between blockchains can be challenging, especially in blockchains that use different paradigms. Recently, with the advent of solutions like Octopus or bridges like Wormhole and Axelar, Secret is able to deliver our technology to developers elsewhere.
So, when we started the conversations with Octopus, we realized that it would be an interesting opportunity to expand to an additional ecosystem. Before that, the EVM ecosystem was our primary goal. It’s still super important for us, and we’re working towards getting developers there. But now, with this partnership, we have another network to work on. Visiting NEARCon and getting exposed to the network, we saw a very lively ecosystem with a lot of different apps. Essentially, this partnership aligns with our overall strategy of expansion and offering Secret’s unique features to developers everywhere, whether it’s Ethereum, NEAR, or other chains. That’s why we’re very excited and happy to work with Octopus on this and make the necessary technology adjustments or changes on our side to enable this integration.
Vivi: What can we expect from Secret to become the first Cosmos SDK chain to connect to NEAR? We know that this is planned for Q1, so could you provide some insights into what we can expect?
Alex: I understand that the first stage of this technology will be just enabling the bridging of assets, which is, for us, half of the story, but it’s a good half of the story. So that would allow people in NEAR to perform things like confidential payments and confidential DeFi. Hopefully, it will allow DEXs on Secret to trade some of the more popular tokens on NEAR in a confidential way to prevent any front-running or snooping. So that’s the first stage. And then the next stage would be to enable general message passing. And that’s, for us, the main goal, the Holy Grail, is actually allowing apps running on NEAR to store confidential information on-chain in a transparent manner by just using this IBC connectivity and passing encrypted messages back and forth and storing and retrieving confidential data and performing confidential compute on Secret smart contracts.
Louis: Yes, to add what Alex said, the first version of the connection will support asset transfer. And we will work with the Secret Network team to pursue the goal of general-purpose message passing between NEAR and Secret Network. Considering IBC is a layered protocol, it’s possible to lay a general-purpose messaging layer on the transportation channel. As far as I know, Axelar even used IBC as a transportation layer when the connections are there. So it’s an achievable goal, provided we work together to pursue it.
Patrick: So we mentioned Q1 2024 is the goal for this integration to happen. One of the things that it relies on is a network upgrade on the secret side. Before anything else, we’ll have to complete a network upgrade to upgrade one of our IBC components, IBC Go. Once that happens, we can go ahead and start connecting to Octopus Network, and start testing that connection. And in parallel with that, we are already working on documentation for privacy-as-a-service applications on EVM. So while we’re developing these application models, basically we can keep in mind that we want this to also work on other things as well, not just EVM but NEAR Protocol, Polkadot, any other ecosystem that we might want to bring this to. So hopefully, by the time this integration is live, we will have these privacy-as-a-service application models better fleshed out and documented, and we can start writing some documentation for how to make them work on NEAR Protocol. At that point, we’ll just have to start reaching out to NEAR Protocol developers, showing them these tools that are available, and helping them build confidential applications on NEAR Protocol to make use of Secret Network via Octopus Network.
The Intersection of AI, Privacy, and Blockchain Technology
Vivi: Would you like to give us some insights on what is the safest path for AI when it comes to privacy, like decentralization and then private infrastructure? What is your plan for that?
Alex: Yeah, so this is a daunting question and a big topic that I’m not sure I have enough expertise to really answer in a totally interesting way, but I’ll give you my view. AI basically consists of two things, right? There is a model, some sort of an algorithm that learns, and then there is the source data that it learns on, right? Both are very important. So if you actually teach the AI on a certain set of say texts that all have a certain worldview, let’s say, some political, right or left, whatever, then the AI would be tending towards that direction. And that is especially dangerous when governments are now starting to implement AI and in a lot of cases, the governments are using private companies to train the AI and then this kind of potential bias may be very hard to detect. So the blockchain, especially a confidential blockchain, might be used to record some sort of proof or a proven list of content that was used to train the AI. But with a network like Secret, this may remain proprietary, remain confidential, but can still be shared with certain agencies or certain people. Because I think that those companies will not be willing to share their data sources with everyone in a public manner, but having it on a confidential blockchain with a way to expose that to an auditor or even to a government agency, that would make sure that there’s no bias or maybe to generate certain proofs. That can be useful. I don’t think today we really know what OpenAI is being trained on. I’m not sure, but I don’t think they disclose the list publicly, and we don’t know whether there are certain biases there or not. And potentially, a blockchain could help with establishing this ground truth of what content was used for training. And a confidential blockchain can make this data selectively disclosable, meaning that not everyone sees it, but only specific people, specific auditors are able to see that list. That’s a way AI could benefit or more. I would say that’s the way humanity could benefit from using blockchains to not control, but to record and keep AI under certain control.
More information for reference:
- About octopus 2.0 and NEAR IBC
- What is NEAR IBC Port? by Vivi Lin
- Introduction to NEAR-IBC | How to Implement the IBC Protocol with Smart Contracts
- Privacy As a Service
Follow Octopus Network!
- Website: https://oct.network/
- Twitter: https://twitter.com/oct_network
- Accelerator Program: https://accelerator.oct.network/
- Medium: https://medium.com/oct-network
- Discord: https://discord.gg/6GTJBkZA9Q
- Telegram: https://t.me/octopusnetwork
- Youtube:https://youtube.com/channel/UCkMYDmXdgjCBTBggSEAy0ZQ
- Github: https://github.com/octopus-network
- Docs: https://docs.oct.network/
