Blockchain Architecture Selection: How to Analyze Pros and Cons?
TechFlow Selected TechFlow Selected
Blockchain Architecture Selection: How to Analyze Pros and Cons?
Rollups and L2s should focus on improving user experience rather than merely being L2s; products should aim to solve real-world problems.
Navigating Web3 tides with focused insightsAuthor: Jon Charbonneau
Translation: Baishuo Blockchain
Recently, the relationship between Rollups, L2s, and L1s has sparked heated online discussions. Some believe that only by becoming an L2 on Ethereum or another major L1 can a chain gain users and applications, while others hold different views. This article provides a detailed comparative analysis of the following three dimensions:
-
L1 vs. L2
-
Rollup vs. Integrated
-
App-Specific vs. General-Purpose
We need a clearer understanding of when to build which architecture. Otherwise, we will continue to see chaotic infrastructure that users cannot understand or effectively interact with.
As Eclipse pointed out in its introductory post ahead of its mainnet launch:
There is currently a mistaken dichotomy—between modular rollup architectures and monolithic chains with massive scale, parallel execution, and shared state capabilities. People often conflate “modular” with “app-specific,” leading to misconceptions that rollups result in chain fragmentation and low throughput. We challenge this view.
Rollups and L2s do not inherently mean poor user experience; fragmented rollups and L2s do. Well-designed rollups and L2s should enhance user experience.
1. Rollups vs. Integrated
All chains may eventually adopt the best available technologies (e.g., DAS + ZK) if proven useful. As discussed in my previous report “Do Rollups Inherit Security?”, the key distinction remaining is roughly as follows:
“Rollups” are “modular”—building logically independent chains that publish data to their host chain (the DA layer), reusing the host’s consensus. “Integrated” means “monolithic”—integrating all components into a single protocol with its own consensus, without publishing data to a separate host chain. (Even if the DA and execution layers are logically distinct parts of a shared protocol.) Solana and Eclipse represent divergent paths, as illustrated in Syncracy’s paper on Solana:
As I recently discussed with Hasu on Uncommon Core, both approaches have long-term value.
Solana takes one path—bundling everything under a single consensus to achieve minimal latency (currently averaging 400–500 milliseconds, aiming for 200 ms in the future) while maintaining a large validator set (~2,000). This is an impressive achievement, but these two goals—maximum decentralization and minimum latency—are fundamentally at odds. Maintaining consensus stability while pursuing maximum speed and throughput is extremely challenging. TowerBFT lacks formal security or liveness analysis, and its role within a proof-of-history model remains unclear. Additionally, the economic model of low-latency systems introduces centralizing incentives.
In contrast, Eclipse adopts a decomposed consensus approach. Rollups can operate in controlled environments with small sequencer sets (even a single operator), improving reliability, further reducing latency, and bringing crypto advantages into Web2-like products. This is similar to deploying payment application Code on Solana using persistent nonces to achieve instant and reliable payments. Beyond excellent near-instant user experience, further time compression is essential for high-value, low-latency financial applications.
Rollups can publish data to another decentralized consensus for stronger validation over longer timeframes. For example, Celestia has a 15-second block time and single-block finality—compared to Solana’s confirmation time (~400ms), reaching finality after 32 slots (~12.8 seconds) isn’t significantly worse.
There is a trade-off between the properties of real-time validator sets (e.g., Solana’s validators vastly outnumbering rollup sequencers) and the guarantees provided. The appropriate level and timescale of commitment form a spectrum. Some engineering challenges remain unresolved, and optimal use cases may vary. Cost is also critical, making scalable DA layers like Celestia (used by Eclipse) necessary.
Eclipse does not replace Solana. They each have strengths and target different markets. Solana remains central to SVM development, with many new applications launching on it. But clearly, in the long run, there won’t be just one SVM chain (Pyth already demonstrates this). The future isn’t about a single chain, but about remarkable advancements in SVM technology. Eclipse is pioneering the trend of bringing SVM to L2s, and other projects may follow.
2. L1 vs. L2
Here, I use the terms L1 and L2 more loosely to include rollups, validiums, etc.
As Vitalik noted in “Types of Layer 2,” bidirectional verification bridges can almost turn any chain into a validium. Beyond that, a social commitment is needed: if Ethereum experiences an anomaly causing bridge failure, the other chain commits to hard fork in response.
The key difference between L1s and L2s lies in how they handle forks. For instance, a validium rolls back if its L1 rolls back a block, and it hard forks if the underlying chain hard forks. To upgrade an L2, governance must exist on the L1 via a bridge contract.
Why choose this approach? Does it make sense for a chain to delegate fork choice to an underlying L1 where the bridge resides?
While it’s widely believed that Ethereum has won the L1 race and all competitors now want to become L2s, Ethereum-based L2s aren’t the optimal solution for every chain.
Ethereum L2s are considered the safest and most scalable way to build chains. However, safety is often misunderstood. Simply posting proofs to Ethereum and delegating fork choice doesn’t automatically make a chain highly secure.
The idea that all chains must deploy as Ethereum L2s to be secure is usually incorrect. In reality, the primary benefit of L2s is leveraging Ethereum’s network effects—a market strategy.
In crypto, capturing attention matters. L2s typically gain access to the most critical developers, users, and media attention. At one point, simply being an L2 was enough to earn such visibility.
However, the attention gained from becoming an L2 is fading. Today, the list of implemented and upcoming Ethereum L2s has grown so large that no individual can track them all. Chains switching to L2 status no longer receive the same attention boost enjoyed by early pioneers like Optimism and Arbitrum. Even long-awaited zkEVM projects struggle to attract users, apps, and value.
Thus, merely becoming an L2 no longer guarantees widespread attention. Yet, if you can attract attention through other means, it may still offer product advantages over standalone chains. For example, turning a pyramid scheme into a square could funnel ~$700 million into a multisig wallet—even without an L2. Alternatively, you could build Ethereum’s first SVM L2.
Assuming you have a compelling product, let’s consider how becoming an L2 helps a chain tap into Ethereum’s user base and deliver better user experience—mainly by favorably leveraging Ethereum-native assets (like ETH) through bridges offering attractive security and/or UX.
This value hinges largely on two core assumptions:
1) Existing Ethereum assets are crucial for specific use cases (e.g., DeFi’s reliance on ETH).
If your app heavily depends on assets within the Ethereum ecosystem, adopting an L2 architecture may be valuable. But if you’re indifferent to Ethereum assets, becoming an Ethereum L2 becomes less relevant. Currently, Ethereum-based assets are vital across crypto, creating strong demand in this space.
At the industry level, the key question is: what will be the future state of crypto?
If the future state gradually decouples from today’s Ethereum state (e.g., unique new states, RWAs, etc.), the appeal of L2s may diminish. If the future state remains closely tied to Ethereum’s current state (e.g., ETH trading), L2s could play a significant role. The former view suggests we’ve only seen the tip of the iceberg in crypto evolution and shouldn’t over-index on the present. The latter assumes crypto development will remain anchored to current conditions.
Both views have merit, but I lean toward optimism about the industry’s long-term outlook—and thus favor the former. There will be many novel, unforeseen states, with unpredictable relationships to existing ones. Compared to expected future states, today’s crypto state is just a fraction.
For example, Ethereum’s so-called “settlement guarantees” matter little for real-world assets like stablecoin USDC or tokenized Treasuries—they are only “settled” when recognized by issuers (e.g., Circle).
In such cases, the appeal of being an Ethereum L2 may wane for certain applications. A new USDC-based payment app doesn’t care whether it’s an Ethereum L2—it needs the most economical, fastest, and most reliable infrastructure to deliver the best possible user experience.
Solana previously struggled with creating new states, but this trend is clearly shifting. Many prominent DeFi and infrastructure projects are launching tokens on Solana, with more on the way—fueling Solana’s growth.
2) The second assumption is that, in specific scenarios, choosing an Ethereum-to-L2 bridge is superior to an Ethereum-to-L1 bridge (e.g., due to security or UX reasons).
Suppose the first assumption holds (i.e., your app heavily relies on Ethereum-native assets). The next question is: can an L2 present these assets more elegantly than a standalone L1? For example, a user holding ETH wants to swap into USDC. What should they do?
Although bridge security is often cited as a motivation, available evidence makes this argument seem weak. Many major rollup bridges lack proofs; some allow only specific proofs, multi-sig-controlled upgrades, or even lack true L2 status altogether.
Compared to traditional consensus-verified bridges (like IBC), there has never been a major validator coalition failure in such setups. Bridge failures are typically due to hacks or compromised multi-sigs (which L2s are equally vulnerable to).
While I find security improvements here unconvincing, the main advantage of current L2 bridges lies in convenient access to Ethereum users and assets. Rollups like Base, Optimism, and Arbitrum feel like extensions of Ethereum. Users keep the same wallets and addresses; native gas tokens are standard ETH; ETH dominates DeFi (e.g., trading pairs); social apps price NFTs in ETH and pay creators in ETH (e.g., friend.tech); deposits to L2s are instantaneous (since they get reordered together)—and so on.
Users don’t want to think about which bridge to use, analyze various security assumptions, manage multiple wrapped tokens, or obtain native chain tokens for gas. They just want to move their ETH across and arrive with ETH on the other side, then use the L2 seamlessly—just like Ethereum or any other L2. That’s why Eclipse uses ETH as its native gas token. Forcing a new gas token harms user experience.
So why can’t Solana offer the same benefits as an Ethereum L2? In practice, this is more of an engineering challenge than a fundamental limitation—and will become easier to solve over time. Issues like gas tokens and other non-EVM-related UX hurdles are not essential differences between L1s and L2s.
-
gasToken: Gas payment abstraction allows users to freely choose their payment method.
-
Bridge: Over time, bridging solutions will stabilize and standardize, reducing user confusion and liquidity fragmentation.
-
Wallet: MetaMask’s new Snaps feature extends support to non-EVM chains via third-party integrations like Drift or Solflare’s MetaMask Snap.
-
Developer Experience: Language barriers are gradually disappearing. Projects like Solang and Neon help Solidity developers build on Solana, while Stylus enables Rust developers on Arbitrum.
In the future, if users desire Ethereum-like features but require Solana’s speed and scale, Ethereum might play a role in Solana DeFi. Yet, users holding Ethereum-native assets may still prefer operating on Ethereum L2s—provided scalable L2 options exist.
3. App-Specific vs. General-Purpose
Regardless of whether a chain is an L1 or L2, it’s clear that vertical scaling through enhanced execution is needed to increase per-chain throughput. Rollups shouldn’t imply fragmentation. Consolidating many homogeneous chains under a shared stateful sequencer manager looks like a parallelized chain from a scalability standpoint—but poses greater UX challenges.
Whether L1 or L2, deploying app-specific rollups is often cited as providing “dedicated blockspace.” However, this misunderstanding largely stems from the unnecessary constraints of the EVM’s single-threaded global fee market. A parallelized SVM with local fee markets greatly reduces the need for app-specific chains. Hosting more apps on shared infrastructure lowers complexity for both developers and users. Cross-chain UX and developer complexity in a multi-chain world are underestimated existential risks.
This doesn’t mean there will ultimately be only one chain. I see four reasons to deploy your own chain:
1) Scalability and dedicated blockspace This argument is often unconvincing. An NFT mint shouldn’t shut down other functions of a chain, and the answer isn’t necessarily spinning up another chain. This can be mitigated by a parallelized VM with local fee markets. But if overall network bandwidth is constrained, even local fee markets fail—and then another chain may be needed.
2) Sovereignty Crypto governance remains fragile. Having your own chain for forking may serve as a coordination mechanism—though this is extremely rare.
3) Customizability Consensus-level customization may be valuable in some applications, but such cases are currently few. Almost all new rollups are still just generic EVM forks with new tokens.
4) Value Capture Internalizing value on shared infrastructure can be harder; app chains make it easier to allocate value directly to the responsible application.
Today, the main motivation for launching an app chain is often to boost project narrative or token utility. Bear-market downturns and insufficient app growth have driven funding and development of overly complex architectures, forcing new projects to manage their own complexity.
Launching your own chain today involves painful and unnecessary trade-offs (complexity, cost, poor UX, liquidity fragmentation, etc.). Most apps can’t justify incremental gains against these costs. The infrastructure required to make such UX competitive still seems distant. This isn’t to say app chains should never exist—they clearly do. Rather, we’ve overinvested in the narrative as an industry direction. Given the current state, the current trend toward rebundling is clearly beneficial.
4. Summary
Solana has indeed gained significant momentum in recent months. This sharp shift largely reflects recognition of the current state of multi-chain user experience—decentralized yet poorly usable. Using Solana-based apps offers an incredible experience: smooth and fast.
Rollups and L2s have a bad reputation for user experience, but the real issue is fragmentation. We associate rollups and L2s with horizontal sharding because, in practice, most simply replicate off-the-shelf EVMs and operate under constrained data availability bandwidth—resulting in expensive and clunky usage.
Yet, this isn’t a fundamental limitation. By vertically scaling via powerful VMs on scalable data availability layers, these UX and cost issues can be resolved. For both L1s and L2s, some degree of rebundling the entire tech stack is likely inevitable. When used correctly, L2s and rollups should improve user experience—that should be their true selling point.
Both approaches have merits. Before building the next L1, L2, or L3, we simply need to ask ourselves more clearly: “What market problem is this product trying to solve?” and “How does this architecture meet my needs?”
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@dba_crypto
