IOSG Ventures
Published in

IOSG Ventures

dYdX Is Running Away: The Battle Between Appchain and Rollup

TL;DR

  • The main reasons why dYdX left StarkWare: long development cycle of Stark technology, L2 solution sequencer/prover network decentralization still need time, for the sake of composability, Cosmos SDK providing a pretty solid development tool
  • In addition to transaction speed and cost, the imagination of appchain is also reflected in token empowerment.
  • Appchains have better flexibility in terms of fast iterations compared to those generalized public chains.
  • The multi-chain narratives have changed: quality applications present a weak dependance to the underlying chain, while the underlying chain presents a strong dependance to them.
  • In the past, applications would think about how to do user retention, but now it is the turn of public chains to think about “application retention”.

Foreword

On June 22, dYdX announced that its v4 version will be launched as a Layer1 blockchain based on Cosmos SDK and Tendermint, featuring a fully decentralized off-chain order book and matching engine capable of increasing throughput by several orders of magnitude. In addition, $dYdX is proposed as the native token for dYdX v4 (depending on the community though). The team plans to open source dYdX v4 by the end of 2022.

To make it easier to understand, let’s start with an analogy: Ethereum Rollup is like an old building in the city center, with the advantages of the proximity to shopping malls and transportation facilities (composability), and the disadvantage of dilapidated decoration (slow infrastructure iteration), and no owner renovation allowed (no support for application self-customization nodes).

dYdX is a big tenant of this building, who usually has no social life (less dependent on composability), so he decided to move to the suburbs to build a villa. He happened to meet a nice renovation team (Cosmos SDK) that had a big production in the suburbs (Terra), so he hit it off and left Rollup behind.

The Reason Behind

Decentralized derivatives markets hit a bottleneck in terms of trading volume

Take Binance, the largest centralized exchange, for example, whose trading volume of derivatives far exceeds its spot trading volume. (Taking data from 2022.6.26, its contract trading volume for BTC/USDT, for example, is about 8 times higher than its spot trading volume)

Binance spot market trading volume
Binance Derivatives market trading volume

The situation is different on the decentralized market. Comparing spot and derivatives trading volumes, Uniswap V3, the largest spot trading marketplace for long-tail assets on Ethereum, however, outpaces mainstream derivatives trading protocols such as dYdX/Perpetual protocol.

This means that there is still a lot of untapped potential for decentralized derivatives on chain. The biggest impediment to decentralized derivatives trading at the moment, which is also the reason why pro traders prefer to use centralized exchanges, is still mainly because the on-chain infrastructure cannot support the throughput required for derivatives trading. This is why dYdX chose StarkWare in the first place — from a protocol perspective, the off-chain zero-knowledge proof generation + on-chain proof mechanism ensures the high-frequency transactions needed for derivatives protocols, and from a user perspective, Rollup offers a much lower fee compared to Ethereum L1 (about $0.03 in fees per transaction).

And StarkWare makes it. By taking advantage of its validity Rollup, it has achieved real-time reporting in the update of the prediction machine and greatly improved the trading mode advantage of dYdX by separating logic/execution. Compared with L1, the L2 version has achieved a huge jump from 10X to 25X in terms of leverage. — It is the reason we’ve are long-term bullish on Rollup.

StarkWare brings a lot of performance benefits to dYdX, but what exactly caused it to leave StarkWare?

There are 4 reasons:

1. The development cycle of Stark technologies takes time

2. It will take some time for the sequencer/prover network of the L2 to be fully decentralized

3. dYdX’s exploration of future composability

4. Cosmos SDK provides a developer-friendly soil

1. The Development cycles of Stark technologies is too long

Zero-knowledge proof has always been the most difficult subject in cryptography, not only crypto. And one of the biggest problems with a zero-knowledge proof is the generation of a zero-knowledge proof — how to translate computational integrity (a provable statement), through a succinct and transparent circuit, to a verifier-friendly proof, has always been one that academics strive to achieve. (succinct/scalable and transparent here is used to describe Stark, which is the technology underlying StarkWare’s Rollup.) Stark is supposed to be the end game of zero-knowledge proof, but it’s also naturally the most time-consuming and expensive to develop at the practice level.

This also seems to be the case when it comes to practice — dYdX Founder suggests that Rollup’s nodes are not performing enough to support the TPS they need (TPS is critical for orderbook)

It is interesting that the original sentence quoted in the blog is off-chain and decentralised, but the only way to achieve both off-chain and decentralised is through ZK technology. So is dYdX going to leave StarkWare completely in the future? Even whether dYdX will return ZkSync belonging to the same ZK faction is a question mark. Or dYdX try to build a ZK chain on Cosmos, but that’s not very logical.

2. Time still Needed for a fully decentralized Node Operator

Currently, Rollup network has the problem that Node Operator/Sequencer is not decentralized enough, and Vitalik has proposed some solutions to this problem, such as sequencer auction, random selection from PoS set, DPoS voting, etc. (see: An Incomplete Guide to Rollups).

This is also a problem in the StarkWare network, where the number of sequencer is very small and deployed by the StarkWare labs themselves, although this is a common status quo in Rollups, but in reference to the previous incident where the arbitrum sequencer went down, the dYdX team is not comfortable with this very centralized sequencer setup, as it represents a huge risk for both traders and protocols. Traders are profit-oriented, and if any security concerns arise, the retention rate of the platform will face a big challenge. Of course, in the long run zk Rollup + Ethereum L1 brings much higher security than Cosmos. But the security, although guaranteed, is completely dependent on StarkWare (development progress).

At the beginning of this year, dYdX showed its determination and confidence in wanting to be decentralized in its roadmap outlook at the beginning of the year. This explains why dYdX is not going to another Rollup solution that is currently also relatively centralized.

3. dYdX’s exploration of future composability

Currently dYdX is built on StarkEx, which does not support composability between dapps. StarkNet, on the other hand, is a general virtual machine that not only allows dapps within the ecosystem to be composable, but also allows interaction with smart contracts on Ethereum L1 (currently known forms of interaction are relatively simple asset interactions), but dYdX has not yet migrated to StarkNet.

In addition, with the development of DeFi, a series of composable products based on decentralized derivatives trading market, such as structured products, are the new direction in the future. dYdX naturally does not want to miss such an opportunity because of the current technical limitations of StarkWare. (There are currently arguments that the derivatives market relies more on the oracle to provide real-time value updates than on composability. This theory makes some sense, and composability may not be as high a priority for the derivatives market as tps)

4. Tendermint is regarded as a very complete set of tools for developing L1, which greatly helps developers lower the threshold for developing public chains. There are some excellent Layer1s developed based on this, both the relatively independent Terra and EVMOS within the cosmos ecosystem. In addition, IBC has opened up a bridge for communication between heterogeneous chains, and established a foundation for dYdX to use BTC as collateral on the Cosmos chain in the future.

Most importantly, dYdX can ensure the professionalism of the autonomy, which are the nodes owned by the public chain itself, provided by Tendemint. Compared to StarkWare self-owned nodes, dYdX can ensure that these nodes have a certain professionalism (specialised) rather than StarkWare kind of generalised, because prover nodes have to deal with the need for off-chain proof for not only one project, but other projects as well, and there is currently no strong proof indicates that StarkWare intends to provide technical support for dYdX’s needs — orderbook matching.

dYdX clarified the need for custom nodes in an earlier blog post

Moreover, in terms of token value capture, the value positioning of L1 tokens far exceeds that of a dapp, while at the same time the nodes can capture a large amount of MEV value that is captured by the native nodes of StarkWare in L2’s economic model and has no value for dYdX tokens.

Another possible reason: no strong sense of belonging natively to the StarkWare ecosystem

Cairo and Solidity are two completely different programming languages. Logically there is no interoperability: one is mainly to write zk circuits, one is to write smart contracts. To attract more developers, StarkWare engaged a third-party compiler, helping complete the compilation from Solidity to cairo. At that time, basically, StarkWare labs helped dYdX finish writing the whole Cairo code (Cairo is the language developed by StarkWare itself). Therefore, from the project’s perspective, there is not much sense of belonging to the language and even the ecosystem.

What impact will the dYdX’s exodus have on Ethereum and Layer2?

Source:https://finematics.com/yearn-vaults-eth-vault-explained/

Ethereum’s powerful traction lies in its composability and network externality, in addition to its first-mover advantage.

Composability is a system design principle that deals with the inter-relationships of components. A highly composable system provides components that can be selected and assembled in various combinations to satisfy specific user requirements.

Different from the walled gardens built by traditional Web2 oligarchs, composability is the core innovation of DeFi. For example, yield aggregators like Yearn rely on complex composability (lending, liquidity mining, yield farming, etc.) to build strategies that optimize capital efficiency. Imagine if these protocols were distributed across different chains, the complexity and risk of the strategies would grow exponentially.

Whereas dYdX’s main product is a perpetual protocol, the dependence on external parties is limited to oracle’s price feed. The combinability use case for dYdX may be those derivatives aggregators that build structured products based on existing derivatives DEXs, for example, using dYdX’s order book to launch new products, just as Perpetual Protocol takes Uniswap’s trading information as references. However, composability is not indispensable for dYdX when compared to protocols like Yearn, or those more basic ones like lending protocol and DEX.

Network externality refers to the fact that the utility each user receives from using a product is positively related to the total number of users. The larger the number of users, the higher the utility each user receives. The network externality is particularly evident on Ethereum, where a solid user base has made Ethereum the choice for application development over a long period of time.

Similarly, with the consideration of trading depth and slippage, dYdX itself has a network externality, since more users will bring good depth and low slippage; but it does not depend on that much on Ethereum’s network externality. As the top perpetual protocol, dYdX has already accumulated a certain user base, and the trader is a relatively fixed group, which can maintain good user retention. Therefore, it is speculated that after migrating to Cosmos, with further optimization of transaction speed and cost, dYdX may gradually attract more users in addition to the original user migration.

Also, Ethereum’s enormity makes its pace slow, and the development progress is often unknown. After Vitalik proposed the “A Rollup-centric Ethereum roadmap” and “Endgame”, the Ethereum roadmap has shifted to focus on optimizing the base layer to serve Rollup, and proposed a new sharding solution, Danksharding (expected to be implemented in 18–24 months) and an intermediate solution, Proto-Danksharding (expected to be implemented in 6–9 months). In the crypto world, time is money. This is obviously too long, and the development process is still accompanied by many uncertainties.

As the generalized public chain involves many many things, it is impossible to take too big and too fast steps in upgrading and optimization, which is a constraint for projects that need to update and iterate quickly. Appchains are more flexible, and developers are more free to optimize their DApps rather than rely on the underlying chain.

By the same logic, games are other kinds of applications that do not depend on composability. Games have their own self-running ecosystem, and the requirements for external parties are often just related to joining in and leaving the ecosystem. Moreover, user experience is the top priority for games, and if the underlying chain cannot meet the performance requirements, the games themselves have strong incentives to go away.

As for Layer2, let’s look back at the logic of its narrative: Ethereum itself does not have enough throughput to support large-scale applications, and the high transaction costs and low speed hurt the user experience. But under bearish market conditions, gas fees and transaction speeds remain in a relatively reasonable range, which somewhat undermines user demand for Layer2.

In addition, dYdX was originally the top and native project of Ethereum, and as an application that adopted Layer2 very early, its practice of building an appchain will affect other projects. Why do we use Layer2 when we can do it without Ethereum? With this in mind, we may have to lower our expectations for Layer2’s valuation if many top applications follow dYdX and build their own appchains.

Where will the application chain go in the future?

Before dYdX, some projects were already exploring the direction of appchains.

Back in June 2020, Axie Infinity proposed the idea of a Ronin chain in Medium and officially launched Ronin in February last year, with a peak TVL of nearly $1.5 billion since then. However, in April this year, the Ronin bridge was hacked to steal $625 million worth of assets.

In March this year, DeFi Kingdoms launched DFK Chain based on Avalanche, validated by Avalanche’s subnet, and was compatible with EVM.

In addition to transaction speed and cost, the imagination of appchain is also reflected in token empowerment.

Nascent co-founder Dan Elitzer tweeted about the UNIChain idea: current Uniswap users’ costs are mostly in transaction fees, gas fees and potential MEV spend, the latter two of which are paid to Ethereum miners. If UNIChain is launched, could these two expenses be empowered to $UNI, which has been underperforming despite Uniswap’s $5+ billion TVL and absolute leadership in DEX? Achieving value capture for $UNI through appchains is indeed a good idea.

Of course, Uniswap as a DEX still has strong dependence on Ethereum, after all, most tokens are still based on the ERC-20 standard, and unless cross-chain facilities are perfect enough, UNIChain may only stay in the conception stage.

But this vision can be extended to other protocols. DeFi Kingdoms, which we mentioned above, has gone a step ahead and extended the use case of $JEWEL further from governance tokens to gas fee payments on DFK Chain. In this case, 25% of the $JEWEL collected as gas fee will be rewarded to the validators, 50% will be burnt, and the remaining 25% will be given to the community. As we can see, the adoption of the appchain allows for a broader scope for project’s native tokens.

In addition, security is an issue that appchains have to consider. For example, Aave’s TVL is nearly 7 times its token market cap; it will pose a great risk to the chain’s assets if Aave is separated from the security guarantee of Ethereum.

Therefore, for applications with strong security needs, joining Polkadot or Cosmos’ multi-chain ecosystem is a good choice. At the same time, Polkadot and Cosmos also provide integrated security assurance compared to the potential security risk caused by building chains by themselves.

Developers can develop blockchain based on Substrate, and if they want to join the Polkadot ecosystem, they need to stake DOT to participate in parachain auction or rent parathread to enjoy the shared security provided by the relaychain.

On Cosmos, developers can build appchains based on Cosmos SDK and access to Cosmos ecosystem through IBC. As for security, Cosmos offers Interchain Security, where multiple chains in the ecosystem can share the same validators set, allowing new networks that are weak (the low market value of tokens may raise security risks) to rent the security of mature networks.

Application retention problem: weak dependence of quality applications to the underlying platform

Let’s simply talk about public chain narrative logic: as early as 2017 and 2018, we wanted to build generalized, large public chain, proposed to do the “Ethereum killer”, to achieve “one million TPS”, but those once killers eventually disappeared, or even become helpers; and then since DeFi summer in 2020 the scalability of Ethereum has become a very urgent need, so scaling and multi-chain narrative emerged at that time. Today, after two years, we found that these valuation monsters either postpone or crash, do not seem to be very reliable — and finally applications started to build their own chains.

Source:https://www.dapp.com/dapps/

From the chart above, excluding games, there are still few applications that capture more than 1,000 DAU on Ethereum. For applications, it is more appropriate to have a certain volume and user accumulation first before going for appchains. For applications of small scale, many current public chains can meet their demand for throughput. For new applications, the backing of large public chains can provide certain exposure and convenience (in terms of user learning costs and convenience). Going for an appchain before having a certain scale also brings unnecessary cost.

If the native applications on Ethereum come out to build appchains, they need to consider the migration cost — are the users willing to migrate when the application migrates? What is the replaceability of the products on the original chain? (Just like Uniswap can be replaced by Sushiswap) If more application chains start to emerge in the future, the whole ecosystem will become fragmented, and a good cross-chain infrastructure will be needed.

Further, if we look at the relationship between the underlying chain and applications outside the context of Ethereum and dYdX, the best case is that applications enjoy the composability provided by a strong underlying chain, while quality applications will feed the underlying chain and bring user growth to it.

However, we believe that quality applications present a weak dependance to the underlying chain, while the underlying chain presents a strong dependance to them.

Firstly, in the current multi-chain ecosystem, if the application is good enough, it is not difficult to find a landing point; secondly, the interaction between the underlying chain and the users is mainly reflected in the application layer, other than that, the users’ perception of the underlying chain is only reflected in the speed and cost. If there is only good infrastructure but lack of quality applications, the value of the underlying chain cannot be fully reflected.

In the past, applications would think about how to do user retention, but now it is the turn of public chains to think about “application retention”.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store