A more practical solution is to distribute these gas fees among the applications.
Author: Andre Cronje
Compiled by: Deep Tide TechFlow
It all started with a tweet:
Why L2 as application chains are not very reasonable for developers:
Almost no infrastructure support at deployment, such as stablecoins, oracles, and institutional custody.
Lack of support from foundations or labs.
Centralization, making it vulnerable to attacks.
Leads to fragmented liquidity, requiring reliance on bridging.
Lack of user and developer communities.
Time spent dealing with these issues instead of focusing on applications and users.
Weakens network effects.
Still has long transaction confirmation times (some providers won't work with you).
Developed alone, without team support.
This experience 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 excites me greatly because there are many new solutions I hadn't encountered before, and I've always been eager to learn new technologies, so I began to delve deeper.
The idea of having my own tech stack, including native stablecoins, oracles, proof systems, network effects, bridging, and interoperability, sounds too good to be true.
It seems somewhat unrealistic (but not entirely so), so I started with what I believe are the two biggest obstacles: **native stablecoin issuance and trusted **oracles. Going through this process when Sonic was recently launched (and spending over $5 million) made me realize how humbling and somewhat embarrassing it would be if I could get all of this for free.
Among the recommendations, noble.xyz intrigued me the most because it claims to provide native USDC and CCTP for any IBC-enabled chain. First of all, it's a cool product, but it’s not native USDC or CCTP; it’s a bridge that issues assets through its blockchain and then transfers them to other integrated chains via IBC (the interoperability version of the Cosmos ecosystem, which is excellent). This is neither automatic nor free, and certainly not native or CCTP.
That said, we can also look at other solutions like LayerZero and AcrossProtocol, which are both great protocols. We have collaborated a lot with LayerZero, and they are excellent; I highly recommend any chain to work with them, but this is still not native issuance. I know this may seem nitpicky, but after experiencing various issues with bridges, nothing is better in terms of trust and scale than native issuance. If you want native issuance, you need to be prepared with funding.
Regarding oracles, I received recommendations for skipprotocol, storkoracle, and redstone_defi, but unfortunately, these products are not plug-and-play and require integration, and I'm not sure if there would be additional costs. Here, I feel it's necessary to discuss the scale issue. My assumption is that anyone wanting to become L1 or L2 would hope to break into the top 50, 20, or 10 (whether by trading volume, total locked value, or market cap). However, this is not always applicable; some applications do not need to be that large. I experienced this with the Keep3r network, where everyone expected it to become another Yearn, but it was never intended to be that way. Yearn is akin to an asset management company, while Keep3r is a niche operational tool, and the two do not require the same evaluation criteria. Therefore, this article is not meant to undermine the value of these products; as I said, they are all excellent, but if you assume you are launching an L2 or L1 application chain to compete with Arbitrum, Optimism, Solana, Avax, etc., these solutions seem insufficient.
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 major issue, it does add some unnecessary friction.
Finally, there’s the block explorer, and I must mention Blockscout, which is the benchmark for free explorers. There’s not much more to say; they are excellent. However, paid products like etherscan often have advantages because they have dedicated paid teams.
Of course, this does not solve the issues of interoperability or network effects. Take unichain as an example; if uniswap is the only application on that chain (though unlikely, let’s assume), how much trading volume would it have? How much of the volume is arbitrage with other AMMs, how much is liquidating positions in money markets, and how much is other undesirable flash loan activities? Isolated, transaction fees would decrease, and it is precisely composability and interoperability that provide assistance.
I read some content about clusters and superchains, and I admit that either I did not understand it thoroughly (which is very likely), or it has no practical significance in practice.
Now, to say the last sentence, it really doesn’t make much sense. The ability to launch your own L1 or L2 in a few minutes, equipped with explorers, RPCs, bridging, etc., is indeed astonishing. But is it really practical?
Take Unichain as an example (sorry, I’ve been focusing on Unichain; I genuinely think they might be one of the few exceptions because they have huge network effects, but please follow me on this example), one important reason they built this chain is to capture value. Look at the following tweet:
Uniswap alone on Ethereum generated $2.439 billion in gas fees for validators. This does not include MEV extraction (as sorters, they can capture). This $2.5 billion could have been earned by Uniswap itself but instead flowed to the validators. This is a massive 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 RPC in wallets and development tools, or integrating oracles and native stablecoins? What we want to solve is this: we actually want to capture value back to the applications instead of letting it be taken by the network. Isn't there a simple solution to this? In our creator economy, hasn't this problem already been fundamentally solved? The answer is revenue sharing. Platforms like YouTube, Twitch, and X share revenue with creators. Therefore, a more practical solution would be to distribute these gas fees among the applications, right?
I want to ask, what other practical reasons are there? Of course, the low latency issue has basically been solved by modern blockchains (like Sonic, Avax assuming you need EVM, Solana SVM, Sui MoveVM). Our throughput is also high enough; most of the chains I just mentioned are more efficient than the current Layer 2. So, if the problem isn't speed and isn't throughput, then it must be the issue of value capture. Who can blame them? Sorter fees are a new revenue model (essentially keeping all network fees for themselves instead of sharing with decentralized value-extracting validators—just kidding, I actually like validators).
So, revenue sharing, right? This way, all the troubles are solved, and all the benefits are obtained.
Application chains seem to be an engineering solution created to solve a problem. Don't get me wrong; my inner tech enthusiast loves it, but as a practical developer, I can't help but ask: why is this the case?
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
