Louis: App Roll-up Eventually Becomes Appchain
By MiX, Organized and created based on @Louis Liu speech content
Bnews Character Interview
This interview invited Octopus Network’s founder Louis, who is a senior researcher in mechanism design and cryptocurrency markets, as well as an early Bitcoin investor. The interview revolved around hot topics such as application chains, multi-chains, Octopus2.0, DePIN, etc.
1、Can you briefly introduce Octopus Network?
Octopus Network is a multi-chain network infrastructure built around NEAR Protocol.
Our team was founded in April 2019. We then spent over a year developing blockchain technologies, mainly focused on interoperability and multi-chain architectures, making numerous open source contributions. By late 2020, we chose to build a new type of multi-chain network on NEAR, which later became Octopus Network. The mainnet went live in October 2021 and has been operating for almost two years now, currently with five application chains.
Since last quarter of 2021, we have been developing Octopus2.0, the next generation architecture of Octopus Network, which will be gradually rolled out over the next two to three months. Octopus2.0 mainly includes several new directions: first, supporting application chains built with Cosmos SDK, as Octopus1.0 network only supported Substrate application chains. The second change is transitioning the security source of application chains from $OCT to $NEAR restaking, which can greatly increase the supply level of security for chain leasing.
In addition, regarding interoperability, we will embrace IBC more closely, whether it is inter-chain communication between application chains or external interoperability, IBC will be used. This allows us to connect NEAR with Cosmos chains and various future EVM chains and other heterogeneous blockchains, using the unified IBC protocol.
2、What were the main reasons for choosing NEAR at the time?
When we designed Octopus, Polkadot and Cosmos already existed as multi-chain networks. So why was Octopus still needed?
Application chains are typically one chain per application, with advantages like fast speed, high efficiency, low cost, high customizability and good upgradability. But it also has two major disadvantages: first, when an application chain needs to interact with other chains, cross-chain operations are required; the second problem is that its security needs to be built from scratch. Multi-chain network infrastructure projects aim to solve these two problems. Polkadot achieves shared security through parachains, and Cosmos Interchain Security also launched its first version this year. When we started designing Octopus in the second half of 2020, we believed a more flexible approach could be used to share security, similar to the second version of Cosmos’ Interchain Security.
To share security requires a host chain. We could have developed our own Layer 1 chain as the host, but we believed the core of a multi-chain network should be a hub or relay chain that is a public chain with many DeFi protocols and assets, rather than a minimized pure interoperability network. This is because DeFi is a very important and leading field in Web3, providing asset trading and building a global, open asset trading network. Other types of Web3 projects should be utility-creating economies, whether it is the Greater Economy, Social Networks, or the recently rising DePINs, they all need tokens to coordinate economic activities.
When protocol participants engage in protocol interactions and receive token rewards, or receive airdrops, they often need to convert the tokens. Sometimes they need to liquidate them into fiat to cover costs, and sometimes they need to convert them into other tokens to interact with other protocols. Therefore, token trading is an essential infrastructure for operating Web3.
Centralized exchanges can provide liquidity, but there are still listing issues. If it is an early stage protocol, it may not have the ability or willingness to get listed on centralized exchanges. Therefore, it is best to have decentralized trading infrastructure, so that the entire Web3 can complete its own economic cycle internally. Therefore, we believe the optimal configuration for a multi-chain network is to build around a developed DeFi public chain, with many specialized utility-generating economies surrounding the public chain. In addition to providing security and serving as a cross-chain hub, application chains can combine with DeFi protocols on the public chain from day one.
For Octopus to build on NEAR, we needed to implement functionalities similar to Polkadot Relay Chain or Cosmos Hub via smart contracts. This was obviously very challenging work, so our requirements for the public chain technology were very high, needing powerful computation capabilities and a safe smart contract programming model.
We believe choosing NEAR was the right decision. For the first version of Octopus, it took us about 9 months to finally complete a smart contract with over 7,000 lines of code. Since going live, it has been running efficiently, stably and securely. It’s fair to say Octopus Network has fully utilized NEAR’s efficient, flexible and secure smart contract characteristics.
In summary, as a multi-chain network, Octopus needs to overcome many technical challenges, including shared security, cross-chain operations, transaction access, etc. We chose NEAR as the host chain, mainly based on its advantages in performance, flexibility and usability, while also fully leveraging the extensibility and security of NEAR smart contracts. We believe Octopus will become an important multi-chain network, providing more efficient, secure and sustainable infrastructure for the entire Web3 ecosystem.
3、How can Appchains ensure security?
Security has always been a pain point for appchains. Building their own PoS can ensure security, but this is a traditional approach, and practice has proven independent PoS to be the most expensive option. To maintain basic security of the chain, 5%-10% of tokens may need to be inflated annually. This places tremendous cost pressures on appchains, reflected in the market as constant selling pressure on the tokens.
Using shared security mechanisms, only 1%-2% of tokens need to be inflated annually to ensure chain security, and the security level obtained can be much higher than independent PoS. Why is there this fivefold efficiency improvement? Why haven’t many appchains started using shared security? I think it requires a conceptual shift — most appchain development teams still lack sufficient understanding of shared security. Some teams also believe that if tokens are not used for staking, they lose value. But the market will make a choice in the future, which is appchain tokens should have application value and be able to capture value from the application layer economic system. If a token only exists to ensure chain security while no one uses the application, then it is a useless token.
Currently appchains have multiple options for shared security, including Polkadot’s parachain auctions, Cosmos Inter-Blockchain Communication (IBC), and Octopus Network’s security leasing. I believe Octopus’s security leasing is the most flexible and accessible option. It does not require ecosystem-wide support to launch a chain, and the security level depends only on the amount of rewards provided. At first there may only be dozens of validators providing millions of dollars of security, but as usage grows, token prices increase, and the incentive level will naturally grow, with corresponding improvements in security.
In addition to shared security, there is another idea which is to run Appchains as Rollups, anchoring the security of Layer 1 public chains, mainly Ethereum. This is a complex issue, but in general, Rollup technologies are far less mature compared to appchains, and they may eventually converge.
4、For infrastructure, can Appchains truly interconnect the entire blockchain to some extent?
The balance between appchains and public chains is a topic that has received much attention in infrastructure. Appchains are not a replacement for public chains, nor can public chains completely replace appchains. Because in computing systems, generality and efficiency always need balancing.
The more general a system, the harder it becomes to optimize for specific needs; conversely, optimizing for a particular need naturally limits it to that scenario, losing some generality — this is a fundamental contradiction. Therefore, for an application, it may initially choose to use a public chain. When it develops to a certain stage, specific requirements may emerge, for example in terms of fees or user experience, that public chains sometimes cannot meet, because public chains cannot change for a specific application. The application may then choose to migrate from the public chain to an appchain, and through controlling its own Layer 1, achieve deep optimization. A typical example is dYdX, whose V4 version uses Cosmos as an appchain.
Appchains also have their own challenges. For example, security needs to be maintained from scratch, and it requires interoperability, otherwise it becomes an isolated island. With the evolution of multi-chain network technologies and cross-chain technologies, we believe there is now very good infrastructure to support the continuous growth of appchains. Therefore, I expect to see a large number of appchains in the future, exploring many application areas and Web3 application fields. These appchains will be interconnected through secure, functionally advanced cross-chain protocols into a unified network — this is the vision of an Internet of Blockchains that Cosmos proposed back in 2015.
5、What do you think of the future dispute between multi-chain interoperability and multi-rollup interoperability?
First I want to clarify one thing, Rollups are blockchains, it’s just that currently Rollups do not produce blocks through decentralized consensus. If relying on a centralized sequencer, some of the fundamental characteristics of blockchains will be lost, such as liveness and censorship resistance for Byzantine fault tolerance. Therefore, in order to achieve a decentralized Rollup, many nodes are needed to act as Sequencers, and these nodes should be Permissionless, most likely through a PoS network.
On the other hand, for higher security, PoS Appchains can publish blocks to a DA layer, and submit transaction digests to a public chain that does Settlement.
Think about it, between these two architectures, although one is App Roll-up and one is Appchain, are there any fundamental differences? This is the so-called different routes leading to the same outcome. The core reason is that in the world of modular blockchains, the problems faced by Web3 infrastructure are the same, and the best available technologies are also the same.
6、Vitalik Buterin previously mentioned that some ideas based on ETH2.0 may dilute ETH consensus. What do you think?
I pay close attention to Vitalik’s blogs and tweets, and have participated in some discussions. Why is he called V God? Because he is truly visionary. He does groundwork for important issues in the coming years, clarifying some basic concepts and having in-depth discussions — these are all long-term considerations.
Vitalik proposed not overloading Ethereum’s social consensus. Bluntly put, it means code is law. Smart contract code solves all application layer problems and handles its own rules without needing social consensus to resolve disputes, especially avoiding expanding disputes to the entire Ethereum community.
Preventing social consensus overload is preparing for potential issues. Currently it seems no major Ethereum projects rely on social consensus to resolve disputes. Because relying on social consensus itself is poor design, protocols should be self-consistent. The issues and perspectives raised by Vitalik are very important and somewhat visionary.
7、What was the thinking behind Octopus2.0’s approach to this sector?
Some Web3 applications are more suited to run on appchains. We have always paid attention to non-DeFi applications, because DeFi typically relies on shared liquidity and combinations with other protocols. Non-DeFi applications that we closely follow include blockchain gaming, creator economies, and the recently rising DePINs. Especially DePINs, we believe it is still largely unexplored territory. Its basic idea is to build service networks through protocol-issued tokens and crowdsourcing participation without permission, where users benefit from using the protocol’s network services, service providers and the entire network benefit, thus bypassing the organizational form of companies. Whether DePINs can work depends on whether protocols can coordinate dispersed service providers to form reliable service networks; whether protocol coordination is more efficient than centralized companies building and operating networks — these are still open questions requiring case-by-case analysis.
DePINs are exploring areas like compute, storage, wireless communication, energy networks, sensor networks, etc. We hope Octopus Network can provide specific services for DePIN appchains, such as token economic design, or provide common modules to help early projects build networks and capabilities faster.
8、Regarding tokens across the industry, how do you balance the relationships between projects, markets and VCs?
First I want to talk about the definition and position of tokens themselves in Web3, which is still under intense debate. In my view, although crypto protocol networks can have multiple tokens, there is basically always a primary native token or governance token.
The native token is essentially an ownership certificate of the crypto protocol network.
Ownership mainly contains two rights. On one hand, the profit rights, meaning the inherent value capture mechanisms from running the crypto network will make these tokens appreciate. On the other hand, governance rights, meaning through the native tokens or derived tokens, the community can make weighted decisions on the evolution direction of the protocol network. Some may say that if tokens are defined this way, they are securities. Personally I think this is unavoidable. Regulation needs to evolve along with Web3 economic phenomena. A few years ago, Hester Peirce’s Safe Harbor proposal provided issuers with exemption periods to adapt to new ownership allocation mechanisms. If we distort the essence of Web3 token economies to fit existing regulation, future pitfalls will only grow bigger.
Assuming we agree tokens are ownership certificates of crypto protocol networks, protocol design must then consider different stakeholders in the network, i.e. participants in different roles. Usually only one of these roles are long-term network owners — the Owner role. For example, in a two-sided market Web3 network, service providers should be Owners; in a decentralized B2C network, merchants should be Owners; in a decentralized ride-hailing chain, drivers should be Owners; in a decentralized creator economy network, creators should be Owners. The purpose of determining Owners is to distribute as many tokens to them as possible through the protocol.
In addition to Owners, networks usually also need other contributors to operate, such as developers, projects, communities and institutional investors. With the concept of Owners, I believe token rewards for other contributors should all be viewed as necessary costs to build the crypto protocol network. The mindset for designing incentives for other contributors is: How to acquire enough contributions with the minimal tokens, to meet the early construction and bootstrapping needs. For example, security is a cost for appchains, so ways to minimize security costs while obtaining adequate security should be considered. If the Owner concept goes wrong, then major problems can occur, for example an independent PoS ride-hailing appchain inflating 10% of tokens annually to validators, which could easily result in validators having more governance rights than drivers.
In summary, if we view tokens as ownership certificates of crypto protocol networks, determine the owner roles before protocol design. Treat other contributors, including teams and investors, as suppliers.
9、Many current DePIN projects reference Helium’s dual-token Burn-Mint model, introducing Data Credits or other credits. This seems relatively healthy so far, can you discuss potential risks of such models?
The BME model you mentioned is a burn-mint balancing model, whose main advantages are firstly, fiat-pricing reduces transaction costs, and secondly, protocol revenue Burn and protocol cost Mint are separate, very clear and easy for various roles to evaluate and participate.
The BME model also has two potential risks. First, Burn relies on price oracles, facing oracle attack risks. Second is regarding balance. When token prices fall, service provider returns decrease, less efficient providers will exit first. Then, more efficient providers receive more tokens, achieving profit-loss balance. This is essentially filtering out less efficient service providers during token price declines, completing a metabolism for the system. However, it should be noted that if many service providers exit, the network’s service capabilities may be damaged, leading the system into a death spiral.
中文版｜App Roll-up 最终就是 Appchain｜Bnews人物专访
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
