It all started with a tweet:
Andre Cronje:
· Why L2 as an application chain is not very reasonable for developers:
· Almost no infrastructure support during deployment, such as stablecoins, oracles and institutional custody.
· Lack of foundation or lab support.
· Centralized, easy to attack.
· Causes liquidity fragmentation, needs to rely on bridges.
· Lack of user and developer community. Time is spent on dealing with these issues rather than focusing on applications and users.
· Weakens network effects. There are still relatively long transaction confirmation times (some providers won't work with you) Developing alone, no team support.
This experience has exposed me to many product recommendations, one of which particularly caught my attention (of course, there are many other cool products);
Surprisingly, they launched my own application chain in just a few minutes.
From a technical perspective, this is very exciting to me, as there are many new solutions here that I haven't encountered before, and I've always been passionate about learning new technologies, so I started to delve into it.
The idea of having your own tech stack, including local stablecoins, oracles, proof systems, network effects, bridges and interoperability, sounds wonderful.
This sounds a bit unrealistic (but not entirely), so I started with what I think are the two biggest hurdles: local stablecoin issuance and trusted oracles. Going through this process when Sonic was recently launched (and spending over $5 million), it made me feel both humble and a bit embarrassed if I could get all of this for free.
Among the many recommendations, noble.xyz is the one that interests me the most, as it claims to provide local USDC and CCTP for any IBC-enabled chain. First of all, this is a cool product, but it's not a local USDC or CCTP, but a bridge to issue assets on its blockchain and then transfer them to other integrated chains through IBC (the interoperability version of the Cosmos ecosystem, which is excellent). This is not automatic, not free, and not local or CCTP.
That said, we can also look at other solutions like LayerZero and AcrossProtocol, which are great protocols. We've collaborated a lot with LayerZero, and they're excellent, and I strongly recommend any chain to work with them, but this still isn't local issuance. I know this is a bit nitpicky, but after going through the various issues with bridges, there's nothing better than local issuance in terms of trust and scale. If you want local issuance, you need to be prepared to fund it.
In terms of oracles, I received recommendations for skipprotocol, storkoracle and redstone_defi, but unfortunately these products are not plug-and-play, they require integration, and I'm not sure if there will be additional fees. Here, I feel it's necessary to discuss the issue of scale. My assumption is that anyone who wants to become an L1 or L2 wants to be in the top 50, 20 or 10 (whether in terms of trading volume, total locked value or market capitalization). However, this doesn't always apply, as some applications don't need to be that big. I've experienced this with the Keep3r Network, where everyone expected it to become another Yearn, but it never intended to be. Yearn is like an asset management company, while Keep3r is a niche operations tool, and they don't need the same evaluation criteria. So this article is not meant to diminish the value of these products, as I said, they are all excellent, but if you assume you're launching an L2 or L1 application chain to compete with Arbitrum, Optimism, Solana, AVA, etc., these solutions seem a bit lacking.
Next, let's talk about development tools and wallets, which are compatible with any new chain, but users and developers need to manually configure those RPCs. While this is not a big deal, it does add some unnecessary friction.
Finally, there's the block explorer, and Blockscout has to be mentioned, as it's the benchmark for free explorers. Not much more to say, they're excellent. However, paid products like Etherscan often have advantages because they have dedicated paid teams.
Of course, this doesn't solve the issues of interoperability or network effects. Take Unichain as an example, if Uniswap is the only application on that chain (which is unlikely, but let's assume), how much trading volume would it have? How much of that volume is arbitrage between other AMMs, how much is liquidating positions in the money market, and how much is other undesirable flash loan activity? In isolation, the transaction fees would decrease, and it's the composability and interoperability that provide the help.
I've read some things about clusters and super-chains, and I admit, either I didn't understand it thoroughly (which is likely), or it doesn't have practical meaning in practice.
Now, to the last sentence, it's actually not very reasonable. Being able to launch your own L1 or L2 in a few minutes, equipped with a browser, RPC, bridges, etc., is indeed impressive. But is it really practical?
Take Unichain as an example (sorry, I've been focusing on Unichain, I do think they may be one of the few exceptions, as they have a huge network effect, but please bear with me), one of the key reasons they built this chain is to capture value. Look at this tweet:
Just on Uniswap on Ethereum, it generated $2.439 billion in Gas fees for validators. This doesn't even include the MEV extraction (as sequencers, they can capture it). This $2.5 billion could have been earned by Uniswap itself, but it went to the validators. This is a very large number.
So, what if we could solve this problem more practically, without running our own chain, browser, RPC provider, guiding users and developers to configure RPCs in wallets and development tools, and without integrating oracles and local stablecoins? What problem are we trying to solve? It's actually about capturing the value back to the application, rather than having the network take it away. Isn't there a simple solution to this already in our creator economy? The answer is revenue sharing. YouTube, Twitch, X, etc. all share revenue with creators. So, a more practical solution wouldn't it be to share those Gas fees with the applications?
I wonder what other practical reasons there are? Of course, the low latency issue, which modern blockchains have basically solved (like Sonic, AVA assuming you need EVM, Solana SVM, Sui MoveVM). Our throughput is also high enough, most of the chains I mentioned are more efficient than current Layer 2s. So if the problem is not speed, and not throughput, it must be the value capture issue. Who can blame them? Sequencer fees are a new revenue model (basically taking all network fees for themselves rather than sharing with decentralized value-extracting validators, just joking, I actually like validators).
So, revenue sharing, isn't it? This way, all the hassle is solved, and all the benefits are obtained.
Application chains seem to be an engineering solution to solve a problem. Don't get me wrong, the tech-loving part of me loves it, but as a practical developer, I can't help but ask: why is this necessary?
Welcome to join the official BlockBeats community:
Telegram subscription group: https://t.me/theblockbeats
Telegram discussion group: https://t.me/BlockBeats_App
Twitter official account: https://twitter.com/BlockBeatsAsia
