On April 14th, Octopus Network, a Near-based multi-chain network that provides shared security, interoperability & community for Web3 startups, unveils its core plan on Octopus 2.0.
Its founder Louis , who was invited by Near as one of the keynote speakers at the HK Web3 Festival, shared details on Octopus 2.0 that include “$NEAR Restaking” and “Adaptive IBC”.
Octopus 2.0 has showcased the further innovation of the Octopus team and will continue to leverage shared security with $Near, to build adaptive IBC bridges for multi-chain interoperability, as well as to support Cosmos SDK.
For more details, below is the transcript from Louis’ speech:
NEAR has a comprehensive infrastructure to embrace as many Web3 developers as possible. The core is NEAR sharding blockchain with unprecedented scalability and usability, being around by Aurora for EVM execution, Calimero for enterprise use cases, Pagoda for startup facilities, and Machina for decentralized storage. The recently introduced Blockchain Operating System(BOS) unifies the Web3 user experience and provides developer tools to build.
Octopus Network is an essential part of NEAR infrastructure, which was designed to serve application-specific blockchains, aka appchains. The Octopus Network provides shared security, interoperability, critical utilities, and community support to appchains. After two years of improving the current architecture of Octopus, the time has come for a major upgrade. The next-generation Octopus Network will embrace the latest technology and target a broader market.
The first part of Octopus 2.0 is $NEAR Restaking, which will become Octopus’s new shared security supply. Currently, the $OCT token is the exclusive collateral asset to be staked for ensuring appchain security. People may ask us why not use $NEAR directly. The reason is that NEAR has its own layer one staking mechanism, which provides around 10% annual return, a very generous reward, in my opinion. Suppose Octopus Network uses $NEAR as the staking asset. Either appchain rewards are not attractive compared to layer one staking, or appchains must dilute their token heavily to satisfy stakers. Neither case is optimal for Octopus Network.
Several months ago, we learned about restaking from Eigenlayer. The emergence of the restaking primitive has proven to be a delightful surprise for us. It can harmonize the two-sided market of shared security and resolve our dilemma. We can’t wait to incorporate the restaking mechanism into the Octopus protocol. A smart contract named Restaking Base is under activity development and will bring restaking to the NEAR blockchain.
After it goes live, any $NEAR holder can choose to deposit their $NEAR token to the Restaking Base contract. Then those assets will be delegated to the underlying layer one validator pool specified by stakers. All the layer one staking reward belongs to $NEAR stakers.
Once $NEAR holders have set up some stake in the Restaking Base contract, they can choose to restakte to multiple appchains. Their restaking actions establish contracts to provide security for appchains, in which they pledge to operate nodes for these appchains while maintaining consistent online availability. In exchange, appchains offer rewards to them, often in the form of the appchain’s native token, but alternatively in other formats that stakers are willing to accept. The Octopus appchain rewards will be shared between NEAR stakers and OCT holders according to a predetermined ratio. 70:30 is the ratio on our minds now, and NEAR stakers take the bigger pie. Should a staker fail to fulfill their commitments — such as by misconfiguring nodes, attempting to attack the appchain network, or being unable to maintain a stable online presence — appchains reserve the right to slash the staker’s assets, in this case, $NEAR, as a punishment measure. The restaking process is not that complex. But let’s take a step back. Why restaking anyway? Is it important?
There are a few stakeholders in the system. The first is $NEAR holders. For them, the advantages are substantial. Whereas they were previously limited to layer one staking rewards, the same assets can yield multiple staking incentives, enhancing capital efficiency.
For appchains, in comparison to solo proof of stake, OCT staking, or replicated security, $NEAR restaking presents the most affordable, accessible, and flexible source of security. This is due to the rewards they provide merely needing to cover the edge cost of $NEAR stakers. Moreover, with a modest number of stakers, such as 10–20, the appchains network can be successfully initiated. Furthermore, like the NEAR layer one network, appchains allocate validator rewards to $NEAR stakers. This alignment of incentives between appchains and the NEAR ecosystem fosters heightened awareness and support within the community.
For NEAR protocol, it can internalize more value streams, including appchains and middleware chains. Surely it will make $NEAR staking more profitable. By taking more $NEAR from circulation, restaking will positively impact the supply-demand dynamics. The best part is NEAR protocol; its community does not need to pay a penny.
For the Octopus Network, restaking means more people and more assets will participate in the market of security sharing, making the shared security offering more attractive to appchains — a giant leap to boost the network effect of Octopus.
Viewed from a broader perspective, I think Eigenlayer’s invention will be indispensable to any PoS public chain. Some believe that Eigenlayer represents Ethereum’s most anticipated advancement, a sentiment that has garnered considerable popularity within the primary market. Last month, Eigenlayer raised 50 million US dollars. What Eigenlayer brings for Ethereum, the Octopus Network can do better for NEAR. Without modesty, we can assert that we are the pioneers of shared security between blockchains. Since the mainnet launch in October 2021, Octopus has practiced shared security across consensus domains for a long time. We have unparalleled experience in this field.
More importantly, Octopus Network has no intention of monopolizing or controlling $NEAR restaking. Once we are confident in the functionality and security of the Restaking Base contract, we will relinquish control of the contract and make restaking a part of the immutable NEAR base protocol. Any blockchain that wishes to establish its own security foundation through $NEAR restaking directly can use it without the need for Octopus’ permission or pay any fee to us.
The spirit of a multi-chain network lies within its interoperability protocol. IBC is the most comprehensive open blockchain interoperability protocol stack invented by Cosmos. After working on IBC for almost three years, we decided to set up the NEAR IBC port. From there, the NEAR protocol will connect with Octopus appchains and the Cosmos interchain comprising 50+ blockchains. Imagine how many protocol composition opportunities the IBC port can create for NEAR and Cosmos!
In the coming year, we aim to encompass EVM blockchains into the network, Ethereum, Binance Chain, Avalanche, etc. And there is no reason we can’t expand IBC connections to other blockchains, such as Palkdot and Solana, if demand exists. Essentially, Octopus is trying to make NEAR Protocol an intrinsic part of the emerging Internet of Blockchains.
We are not alone in this endeavor. Many teams are building open-source IBC-enabled heterogeneous cross-chain solutions, with Composable Finance and Datachain particularly noteworthy. We greatly respect their work and mutually borrow from each other’s development achievements. This is precisely the charm of open protocols and open-source software. At the same time, we believe that Octopus is best positioned to expand IBC beyond Cosmos. We’re the first to implement IBC on non-Cosmos blockchains — a feat in progress for over three years. This extended period of technological accumulation has forged a secret weapon: adaptive IBC.
We take NEAR and Cosmos as an example. This diagram shows how IBC connects two blockchains together. Many IBC application protocols exist on each blockchain, such as cross-chain token transfer, cross-chain NFT transfer, etc. Please notice that shared security is also implemented as an IBC application protocol. All these IBC application protocols are employed to serve decentralized applications directly. Beneath them lies the IBC TAO, which means the IBC framework.
The underlying light clients are the foundation for making IBC the gold standard for trustless cross-chain communication. As you can see, a Tendermint light client is running inside the NEAR blockchain, allowing the NEAR blockchain to verify cross-chain messages from Cosmos without trust in any third party. The same applies in the reverse direction.
Obviously, the design of IBC is exceedingly elegant. However, the imperfect reality informs us that the most potent component of IBC, light client verification, has become its Achilles’ heel. Verifying a typical block header from a Cosmos chain via Tendermint light client costs a vast amount of gas, making it impractical to use in any production environment.
The adaptive IBC design is to replace the tenement light clients with an off-chain verification proxy and a corresponding proxy client on NEAR. The proxy will maintain the consensus state of the Cosmos chain, verify all cross-chain messages and sign it with its own key. Then on the NEAR blockchain, all the thing that the proxy client needs to do is to verify a single signature. Actually, we do the same trick in both directions, for in the direction from NEAR to Cosmos, a verification proxy is even more necessary since there does not currently exist a NEAR light client that can operate on Cosmos blockchains.
People may question the introduction of verification proxies, positing that it increases the trust assumptions of the system, thereby compromising the security of cross-chain bridges. To some extent, I agree with this perspective. However, simultaneously, this is an inevitable compromise. Unlike those centralized cross-chain bridges, we build verification proxies on a public chain, which we call the proxy chain here. The proxy chain ensures that the verification proxies are decentralized and publicly verifiable. Provided that the security level of the proxy chain is not lower than that of the two connected chains, this additional entity does not necessarily downgrade the security of the entire system.
Adaptive IBC is not only about being adaptive to heterogeneous blockchains but also to technological advancement. For example, once a production-ready NEAR light client in Go is available, it can replace the Cosmos side’s proxy client. Once ZK consensus proof is mature enough, the NEAR side’s proxy client may be replaced by a ZK verifier. A ZK prover will replace the verification proxy in that case. Best of all, client upgrades are only matters of governance, be totally transparent to the upper-layer applications. As you can say, adaptive IBC is a future-proof architecture.
The core developers at Octopus are actively working on developing adaptive IBC. We plan to launch NEAR IBC Port Q2 this year, enabling connections to Cosmos chains and supporting cross-chain asset transfers. In Q3, $NEAR Restaking will go live, offering shared security services to Cosmos chains. We hope everything goes smoothly and all NEAR people support Octopus — may the community be with us!
Disclaimer: This article is for reference only and should not be used as legal, tax, investment, financial or any other advice.
Originally published at https://medium.com on April 14, 2023.
Near Ecosystem’s Key Infrastructure Octopus Network’s Founder Louis Liu Unveils Octopus 2.0 was originally published in NEAR Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.