Foresight Ventures: Application Chain > On-chain Applications?

2022-10-05 11:34:46

Collection

The transformation of on-chain applications into application chains is undoubtedly a trend, which can bring better sovereignty, token value capture, and enhanced experiences within the chain.

Scan with WeChat

Author: msfew, Foresight Ventures

0. More Rollups, More Chains

As the narrative of Rollups gains more attention, and the entire industry demands higher performance, sovereignty, and deployment for App-chains, StarkEx's App-rollup services, Celestia's reusable Layer1 security layer, and other high-performance DA solutions have become mainstream choices for building App-chains.

Past App-chain = App as an L1: Previously, an application needed to create its own chain, which required significant development costs. If it used a PoS mechanism, there would also be additional capital expenditures to launch the initial nodes. Despite the existence of various SDKs and consensus engines, creating a chain remained a very cumbersome task.

Now and Future App-chain = App as an L1 + App as a Rollup + App as a Validium…: There are currently 25 Layer2 solutions based on Ethereum. This includes half of the application chains (or App-rollups, such as the former dYdX) and general Layer2 Rollups (like Arbitrum). As projects like Celestia mature, I believe several times more new Rollups will be built in the future.

In addition, App-L1s on Cosmos and Subnets on Avalanche will also emerge in abundance.

Whether existing application protocols transform into App-chains (like Uniswap potentially becoming Unichain) or applications launch directly as App-chains (dYdX launching as an App-rollup and transforming into App-L1), it ultimately means that in the next year or two, there could be dozens of new chains (L1, App-chain, App-rollup, Subnet).

1. Application Chains > On-chain Applications

Recently, Dan Elitzer analyzed why Uniswap would inevitably transform into a separate application chain, using Uniswap as an example.

The seven-day average fees collected by the Uniswap protocol are second only to the Ethereum mainnet, surpassing the total of BSC, Aave, Bitcoin, and GMX. As such a stable revenue-generating, well-functioning, widely used AMM protocol, why might Uniswap transition from an on-chain Protocol to an App-chain?

There are four main benefits for Uniswap:

a) Token Value Capture

The UNI token is essentially a Meme Coin, currently only usable for governance. This greatly limits UNI holders' ability to directly capture the growth and revenue of the Uniswap protocol and ecosystem. The fundamental reason, I believe, is mainly regulatory issues. Due to the sensitive nature of the product's functionality, Uniswap's organizational structure is also quite unique for compliance.

Both Uniswap V2 and V3 have the concept of Protocol Fees, but the Fee Switch has not been activated through governance. If activated, intuitively, it could directly bring hundreds of millions of dollars in revenue to UNI holders in a year (not considering the side effects on LP revenue and liquidity). This would be a huge boost to the value of the UNI token.

Additionally, if Uniswap becomes a PoS chain, the UNI token could serve as both a staking token and a gas token, positively impacting UNI's value capture.

b) Protocol Economic Mechanism

For a Uniswap Pool, the two most intuitive participants are users and LPs, but for the overall protocol usage, participants also include network nodes and MEV Bots.

For a user, executing a Swap incurs various transparent and opaque fees:

Swap Fee: paid to Liquidity Providers. ~0.171%.
Gas Fee: paid to Ethereum network nodes. ~0.235%.
MEV Tax: paid to MEV Bots and Ethereum network nodes (over 50% of the transaction volume in the above image is from MEV Bots, which secretly extract user profits). ~0.254%.

These fees combined are quite high compared to centralized exchanges.

Currently, Uniswap has no direct control over these three fees.

However, if Uniswap transitions to an App-chain, it could directly optimize Gas Fees and MEV Taxes:

Gas Fee: paid to UNI network nodes. < 0.235%
MEV Tax: paid to MEV Bots and UNI network nodes. A new mechanism could also be introduced to reduce the total MEV Tax. < 0.254%

After this, Uniswap would gain control over transaction fees and the protocol's economic mechanism, allowing for proactive adjustments through governance and other means.

c) Trading Experience

As an independent App-chain, Uniswap could fully leverage new technologies for protocol construction without needing to consider EVM compatibility or general contract deployment. All on-chain experiences would directly empower the protocol's functionality and the surrounding ecosystem's construction.

For users, they could experience:

Higher TPS: The chain could be specifically optimized for transactions and other operations.
Lower fees: Reduced MEV Tax + potentially zero Gas Fees like the future dYdX.
A better overall system: The ecosystem would be more vertically constructed, all focused on the chain and Uniswap itself.

d) Application Sovereignty

Just like dYdX's escape from StarkEx, if Uniswap becomes an App-chain, it can gather the above advantages and gain more control over its tokens, the functionality and upgrades of the entire protocol, governance of the network and protocol, and the construction of the entire ecosystem and infrastructure.

e) Additional Features of App-Rollup

If Uniswap becomes an Ethereum-based App-rollup, it would gain even more advantages, such as significantly improved performance, faster and lighter chain construction, and remaining closely tied to the Ethereum ecosystem.

However, some of the other advantages may be weakened, such as needing to return most of the value (about 60% of the total L2 cost) as DA Fees to Layer1, and the expenditure on Gas Fees cannot be significantly reduced. In the case of a single Sequencer, it would mean that most of the MEV Tax would be captured by it.

2. Disadvantages of Application Chains

Despite the many advantages of application chains, there are a few minor drawbacks compared to on-chain applications, which also lead us to the interoperability issues we want to discuss in the next section:

a) Consensus and Ecosystem

A chain must have Social Consensus. Currently, if an application emerges and launches directly as a chain, it is challenging to achieve consensus. Therefore, many applications choose to launch on the Ethereum network in the form of protocols or Rollups, leveraging Ethereum's existing security and social consensus.

Taking Uniswap as an example, as an application personally named by Vitalik, it is deeply tied to Ethereum. If it "escapes" from the Ethereum mainnet, it will inevitably face resistance from many Ethereum stakeholders and users.

At the same time, Uniswap's greatest value lies in issuing assets (ERC-20) in the largest decentralized network (Ethereum) without permission. If it were to issue assets on its own chain, its appeal would be somewhat diminished. In contrast, a dedicated Trading Platform like dYdX has more significance in becoming an application chain.

b) Interoperability

Returning to our initial point, there will be dozens of new App-L1s, App-rollups, and App-subnets. If they all become chains and form their own networks, the distinction from Web2 networks will become even smaller.

I also believe that many of the App-rollups among these App-chains will become Sovereign Rollups. Thus, they will lack the Trust-minimized bridges inherently built into the same Layer1, making interoperability more complex. They will need to rely on architectures like Cevmos to achieve interoperability with other clusters or IBC networks, which complicates the architecture and introduces newer concepts.

While this may seem promising, the actual engineering implementation will be quite troublesome. Secured Rollups on Ethereum only need to construct their own L1-L2 Bridge, but now they require Evmos Settlement Layer and bridges with other networks (or between several Evmos).

3. Interoperability Solutions for Application Chains in a Multi-chain Era

Taking Uniswap as an example of interoperability issues, in extreme cases, if its main body becomes a chain, users may need to cross-chain to it for the best quotes, perform the Swap, and then cross back.

For interoperability solutions in the application chain + multi-chain era, I can think of several effective approaches:

a) Copy and Paste

1. Actively Fork Key Protocols on Each Chain

This means continuing the current approach used by Uniswap, deploying a new Uniswap protocol on each chain. The App-chain itself would serve as a dedicated trading add-on. This is similar to the approach taken by assets like USDT and USDC.

This method can be said to not solve the problem of interoperability; it merely clones itself multiple times, with each protocol having fragmented liquidity and trading activity. They all operate under the Uniswap name.

However, I actually support this approach and do not oppose it. Because liquidity in Web2 systems is similarly dispersed, or one could say McDonald's is forked in various cities (though it certainly doesn't need to create its own "App-chain").

b) Create Links

1. Each Chain Connects to IBC

Having each application chain (and chain) connect to IBC is a straightforward solution that can directly address interoperability issues.

The drawbacks of this solution are:

Existing chains may not be able to connect directly (for example, Ethereum would need ZK to connect to IBC), and Cosmos chains may not have sufficient performance (hence App-rollups).
The user experience is actually not as good as the previous solution (although IBC is fast, the back-and-forth still takes several seconds, so the two methods may need to be combined).

2. Each Chain Has a Trust-minimized Bridge

We will ignore interoperability solutions that are not Trust-minimized Bridges. To achieve interoperability securely, we need Light Client Bridges (which essentially operate on principles similar to IBC) or Trustless Bridges between L3s.

The main difficulty with this solution lies in the overhead of various validations (Validator, Signatures), which cannot be performed on-chain (EVM). However, the overhead of validating ZKPs is lower, which is why many companies are currently working on ZK Light Clients.

I strongly agree with this direction, but the implementation difficulty is even greater than the previous one, making it a long-term solution.

4. Conclusion

The transition of on-chain applications to application chains is undoubtedly a trend, bringing better sovereignty, token value capture, and improved on-chain experiences.

However, the addition of dozens of new chains will create liquidity fragmentation and interoperability issues. To solve this problem, we either need to fork infrastructure onto different chains or connect to trusted interoperability protocols.

The popularity of application chains suggests that blockchain may be heading down the path of Web2-era applications "going their own way," but it still does not change the overarching direction of decentralization and transparency.