Layer1, Layer2, & Appchains — What developers can learn from dYdX's decision to leave Ethereum
An Interview with Louis Liu, Founder of Octopus Network, on the Pros and Cons of Appchains
On June 22nd, dYdX announced it would build an appchain for the upcoming dYdX V4 and migrate to the Cosmos ecosystem, creating shockwaves throughout the Ethereum ecosystem. Meanwhile, a much younger order book DEX protocol, Fusotao, insists on building an appchain from the onset.
In this interview, Octopus Network Founder & CEO, Louis Liu, explores the reasons for dYdX's move, discusses the pros and cons of appchains, compares multichain ecosystems, such as Polkadot, Cosmos, Avalanche, and BSC, and provides advice for Web3 developers in choosing a tech stack.
What are the primary reasons dYdX left Ethereum?
When dYdX founder, Antonio Juliano, Tweeted the announcement to move to a Cosmos appchain, he made it quite clear that he has always been focused on "product."
Antonio is a young and talented developer leading a strong and radical team. In Antonio's interview with Bankless, Antonio mentions that they've always wanted their next-generation product to be 10x better than the previous one. But this wasn't possible to achieve on Ethereum — and they found that building on Layer2 didn't meet their requirements either.
dYdX is mainly for high-frequency traders. When only ten transactions are finalized per second, and the other 99% of transactions are withdrawn, 99% do not generate economic value. Therefore, Antonio thinks dYdX needs 1000 TPS dedicated to a single application on a chain.
For high-frequency traders, it’s also best to minimize gas fees. As long as an appchain has an Anti-Sybil Attack mechanism, it can make its transaction fees zero.
The Order Book DEX Appchain on Octopus Network
dYdX's decision reminds me of a conversation with a developer friend, Zhang Yu. He came to me and said he wanted to build an Order Book DEX on an appchain. We discussed it very deeply because appchains have strengths and weaknesses.
When we designed the Octopus Network, we explicitly said that we wouldn’t support DeFi applications because the composability requirement for DeFi is usually relatively high. We initially felt the loss in composability would be unacceptable for DeFi protocols, even with the added benefits of high performance, low cost, and great customizability.
However, Zhang Yu insisted that he would rather lose composability to gain the advantage of zero-cost transactions. He believed this was essential for an Order Book DEX.
In the end, Zhang convinced me. So, now the Octopus Network has the Fusotao appchain, the only DeFi appchain in Octopus Network. We can see that nothing is absolute, as everything has trade-offs.
Antonio believes the best product is “the best combination of user experience, decentralization, functionality, and security.”
From the beginning, Antonio's said he didn't care which chain dYdX is built on as long as he builds the best product. While he acknowledges the risk in changing the protocol's technical direction, he sees it as an opportunity to make dYdX ten times better than its predecessor in the long run. He openly says he's not afraid to take risks, not afraid to fail, and even admits that this choice could be wrong. Apparently, Antonio is a sober and courageous man.
Everything has trade-offs.
In blockchain design, there are risks with every choice — whether it's scaling, cost, customizability, security, decentralization, or something else.
I think it's essential to be open and honest with the community. You should not only discuss the advantages of your decision but be candid about potential disadvantages as well. There is no panacea, but there are always pros and cons. When you make the considerations transparent to the community, as long as the community approves, there will be no problems with taking risks.
As for whether other protocols will follow, I think protocols should all think independently. dYdX has provided a good example of being responsible for its own community by making decisions that maximize the interests of its own community, rather than the Ethereum community in general.
What are the pros and cons of building on an appchain? What usage scenarios do you feel are more suitable for an appchain?
High Speed & Low Cost
An appchain has three primary advantages over smart contracts. The first includes high speed and low cost. An appchain is independent, and its TPS can be the same as ordinary public chains, such as BSC or Avalanche. But it's much faster because its speed is dedicated to one specific application. Fast speed and low cost are the pillars of excellent user experience.
Customizability
The second advantage is customizability. Appchains are built using very powerful development tools, e.g., Cosmos SDK or Substrate framework. All the parameters and user interactions can be optimized for specific applications.
Protocols implemented on Layer2 that require massive transactions have a higher degree of centralization. However, the degree of centralization is challenging to measure precisely.
The biggest problem on Layer 2 is the centrality of the sequencer with no way to realize censorship resistance, which is the most challenging decentralization property to guarantee.
Evolvability
Another key advantage of appchains is upgradability. Smart contracts pose a contradiction. At the Layer1 level, smart contracts are immutable, guaranteeing verifiability or predictability of execution rules but making the protocol much less flexible.
DeFi protocols in the form of smart contracts are usually upgraded once a year, such as Uniswap V1, V2, V3, etc. Because each upgrade is actually a new Uniswap, it forces the community to move to the new iteration.
Keeping this in mind, we can see that the traditional Internet application of rapid iteration wouldn’t work in Web3 because iterations in Web3 must reach a consensus in the community and then consensus on the chain, so the cost is much higher.
In contrast, an appchain developed with the Substrate framework has a perfect on-chain governance module. As a result, reaching consensus in an appchain community is a programmable process upgradeable for evolvability — an order of magnitude of improvement compared to smart contracts.
Evolvability is the basic ability of a cryptographic protocol to adapt to changes in demand, technological development, and external environments.
Evolvability may not seem important in the early stages of a protocol, but the competition between protocols, in the long run, is not unlike the evolutionary process of living creatures. If a protocol evolves quickly and can promptly adapt to its external environment or internal demand, its competitive advantage over time will be apparent.
Shared Security
Regarding security, we have to look at the environment in which an appchain builds. While a fully autonomous and independent application-specific blockchain may not be able to reach a security level as high as public chains, an appchain on a multichain network has a different experience.
One of the basic services that a multichain network should provide is shared security, which solves the problem of insufficient security experienced by independent appchains.
Regarding multichain networks, appchains have many options, such as Polkadot, Cosmos, Avalanche, BSC, and NEAR. What are the advantages and disadvantages of each ecosystem?
Before looking at multichain ecosystems, it's more reasonable to look at the appchain itself and consider three crucial aspects of the appchain's development. First, you must consider what tools are used to implement the protocol. Next, its security level needs must be determined. Finally, its crosschain interoperability requirements should be explored.
Appchain Development Tools
If you develop a dedicated chain on Avalanche or BSC, but the logic on the chain uses smart contracts, your application won't have customizability advantages. No matter how well built the underlying layer is, if smart contracts are deployed on top, the ability to improve user experience remains quite limited.
Avalanche Subnet and BSC sidechains can only control the application layer logic running inside the VM. For this reason, I think Cosmos, Polkadot, and NEAR have the advantage.
Polkadot and NEAR's Octopus Network use Substrate for appchain development, while Cosmos uses Cosmos SDK. Substrate and Cosmos SDK are very mature tools, but I believe that Substrate is more cohesive than Cosmos SDK. It also has more powerful features — such as native support for WASM and the security advantages of the Rust language. In addition, On-chain Governance and Off-chain Workers are unavailable in Cosmos SDK.
So, from the perspective of appchain development, I think Polkadot and Octopus Network are in the first tier, then Cosmos, and finally EVM-compatible appchains, such as Avalanche and BSC.
Shared Security
Shared security is another important factor when comparing multichain ecosystems. There are multiple approaches to shared security. For example, let's look at the difference between Polkadot and Octopus Network.
Polkadot Parachains have billions of dollars worth of security, so the security level is by far the highest. But the very high cost required for an appchain team to win a Parachain auction slot creates a bottleneck for Web3 innovation, as only very wealthy protocols will be able to obtain an auction slot. But, for now, let's ignore the high-cost issue to say that, in terms of shared security level, Polkadot is №1.
In contrast, Octopus Network has a leased security model. Although the security is not as high as Polkadot, it allows appchains to scale security as needed. If they want more security, they can lease more.
So, in this respect, Octopus Network's security cost is advantageous compared to Polkadot in that more Web3 innovation can be realized on Octopus Network without substantial economic barriers. That being said, Octopus Network cannot provide security at the multi-billion-dollar level. So, let's put Octopus Network in second place.
Cosmos, Avalanche, and BSC have not yet achieved shared security. Once Cosmos' version of shared security is released, I would place Cosmos in second place along with Octopus Network.
Crosschain Interoperability
The third primary consideration is crosschain interoperability. In my opinion, Cosmos ranks first because of the IBC protocol, which is the most widely accepted generic interoperation protocol in the blockchain space.
Octopus Network sits in second place. Why is that? Because while Octopus Network also commits to the IBC protocol, it lags behind Cosmos SDK's IBC in terms of development progress. However, once Octopus Network's Substrate IBC pallet is fully functional, the crosschain capability of Cosmos and Octopus Network will be exactly the same.
When we discuss crosschaining concerning Polkadot, we must distinguish between crosschaining amongst Polkadot's internal Parachains and crosschaining to chains outside the Polkadot ecosystem. XCMP, the standard for communication between Polkadot's internal Parachains, is very powerful. But Polkadot doesn't yet have a solid standard to interoperate with other blockchains.
Polkadot has yet to build a trustless cross-chain bridge with Ethereum. Existing cross-chain bridges with external chains are maintained by individual Parachains themselves, and these Parachain-specific bridges are basically multi-signature bridges, not trustless ones.
Avalanche actually builds an Avalanche bridge for each subnet. It's a multi-signature bridge with threshold signatures, which is advantageous in terms of cost and speed of use. But a multi-signature bridge requires trust, after all. Finally, I’m not familiar with the crosschain solution of the BSC sidechain. It appears Celer will be taking up the role of connecting the sidechains and BNB.
Overall, in terms of crosschain interoperability, I would say Cosmos currently takes first place with Octopus Network in second place — with the rest of the crosschain mechanisms still in various stages of "trust-based bridging."
From a developer's perspective, when deciding whether to build on Layer1, Layer2, or an appchain, can you give a macro-level comprehensive comparison in terms of performance, security, and cost?
The first consideration for developers is to determine the composability requirements. For instance, if a protocol is very dependent on other protocols, such as an NFT Dapp which mainly performs minting, it would be nearly impossible to create a marketplace with great liquidity by itself — If it relies on OpenSea to trade, then it's better to build on Ethereum.
But if you're developing a project that can be somewhat self-sustaining, such as GameFi, especially where the transaction volume is higher and the user experience is more demanding, appchains should be considered.
Blockchain Games with heavy NFT and fungible assets, such as Axie Infinity, perform the vast majority of transactions within their economic system, including players trading with each other. That is exactly why Axie built its Ronin sidechain to service its heavy gameplay.
(It should be noted that if you're building an appchain or Layer2 which requires crosschaining, your Dapp will suffer some loss in user experience.)
Finally, Layer2 is not without its benefits; security is high. But its costs aren't competitive, and its scaling potential is limited.
Some say that in the Web3 era, the value capture potential of the protocol layer is greater than that of the application layer. What are your thoughts on this?
I agree with this point of view. When we talk about trustlessness in Web3, we aren't making any assumptions about whether the counterparty is good or bad. We don't know each other, yet we dare make transactions anyway. This is trustlessness. How is trustlessness achieved? To put it bluntly, trustlessness is derived from collateral.
For example, when you swap tokens on-chain, both parties transfer their tokens to the protocol facilitating the transactions. Then the protocol faithfully executes the will of both parties and distributes the tokens. The process doesn't require trust between you and the counterparty, but the agreement must be able to be performed as expected. In accordance with this expected execution is the embedded expectation that the underlying chain is safe.
If the economic value of your transaction is higher than the economic value of the underlying chain, or if the gain from cheating you on this transaction is greater than the cost of attacking the underlying chain, then the transaction becomes unsafe. Even though not all unsafe situations will be exploited by malicious actors, we still need to eliminate them by design.
So, the premise of performing a trustless transaction lies in the fact that there is enough collateral in the bottom layer. For PoS it means the validator has enough staked and will be slashed if they perform malicious acts, which ensures that the application layer protocols are secure.
But let's assume the underlying chain is secure, which in the context of PoS means there is enough collateral. Where does this collateral come from? The collateral is the economic value of the infrastructure. The economic value of the infrastructure provides the security for all the applications and all the transactions in the upper layer — It has to be big enough.
Does this mean that the total market value of all ERC-20 tokens on Ethereum can never exceed the total market value of Ethereum? Not necessarily. Because it's a static value, you couldn't "steal" the value of all ERC-20 tokens, even if you had control of the Ethereum PoS.
Of course, it's possible the application layer is worth more in the static total, but it must be the underlying layer that provides enough value guarantees for the transaction stream. Therefore, it makes sense that the value capture potential of the infrastructure level is greater than the application layer.
Does the ability to capture value depend on where the largest share of the collateral is placed?
Let me expand by saying, before we had blockchain, making transactions was all about trust, or in abstract terms, social capital (because trust is a type of social capital) and we actually relied on social capital to make transactions. In fact, human civilization is built on this foundation.
But there is a flaw in social capital. As Nick Szabo pointed out, the problem with social capital is social scalability. Social scalability refers to human limitations, not limitations in tech or physical resources. The Internet has made it possible for anyone in the world to do business with each other; the only limitation is social capital.
But blockchain has invented a way to replace social capital with physical capital to provide social scalability via trust minimization. Therefore, whether it's NEAR, SOL, or BSC, as long as we can reach a consensus that a token has value, it can be used as collateral to allow us to conduct business interactions with people we don't know all over the world. This solves the problem of social capital not being able to scale.
Translated, adapted, and edited from the original 0x499 Delight podcast (Chinese) & 中文版本 by MiX.
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/
