1kx: The endgame of blockchain scaling is minimal trust and horizontal scalability
TechFlow Selected TechFlow Selected
1kx: The endgame of blockchain scaling is minimal trust and horizontal scalability
To truly scale trust-minimized systems to every corner of the planet, trust-minimized and horizontally scalable systems must be built.
Navigating Web3 tides with focused insightsAuthor: weidai.eth
Translation: Luffy, Foresight News
Ethereum is a permissionless world computer that, at the time of writing, possesses the highest economic security and serves as the settlement ledger for a vast array of assets, applications, and services. Ethereum also has its limitations: block space is a scarce and expensive resource on the Ethereum mainnet. L2 scaling is considered the best solution to this problem, and in recent years numerous projects have entered this space—most of them rollups. However, strictly defined rollups (with data posted on Ethereum L1) cannot achieve infinite scalability for Ethereum; their upper limit is processing several thousand transactions per second.
First, let’s understand two concepts:
-
Trust minimization: A system (or one of its functions) is trust-minimized if it does not require trusting any component beyond the underlying L1.
-
Horizontal scalability: A system is horizontally scalable if instances can be added without creating global bottlenecks.
In this article, we argue that trust-minimized and horizontally scalable systems represent the most promising path for scaling blockchain applications—a direction that remains underexplored. We build our argument by exploring three questions:
-
Why should applications be trust-minimized?
-
Why build horizontally scalable systems?
-
How can we enhance trust minimization and horizontal scalability?
Disclaimer: While this article focuses on Ethereum as the base L1, much of what we discuss also applies to other decentralized settlement layers beyond Ethereum.
Why Should Applications Be Trust-Minimized?
Applications can connect to Ethereum in a trusted manner—they can write to and read from the Ethereum blockchain—but the trust assumption lies in whether business logic is correctly executed. Centralized exchanges like Binance and Coinbase are prime examples of trusted applications. Connecting to Ethereum allows applications to leverage a global settlement network with multiple assets.
Trusted off-chain services carry significant risks. The 2022 collapses of major exchanges and service providers (e.g., FTX and Celsius) serve as cautionary tales about what happens when trusted services misbehave or fail.
On the other hand, trust-minimized applications interact with Ethereum in a verifiable way—for example, smart contract applications like Uniswap, rollups like Arbitrum or zkSync, and coprocessors like Lagrange and Axiom. Broadly speaking, as applications become protected by the Ethereum network and more functionality is delegated to L1, trust is eliminated. As a result, financial services can be offered without counterparty or custodial risk.
By outsourcing functionality to L1, applications and services gain three key properties:
-
Liveness (and ordering): Transactions submitted by users should be timely included (executed and settled).
-
Validity: Transactions are processed according to pre-specified rules.
-
Data (and state) availability: Users can access historical data and the current application state.
For each of these properties, we can consider what trust assumptions are required—specifically, whether Ethereum L1 provides the property or if external trust is needed. The table below categorizes different architectural paradigms accordingly.
Why Build Horizontally Scalable Systems?
Horizontal scaling refers to scaling by adding independent or parallel instances to a system, such as applications or rollups. This requires the absence of global bottlenecks. Horizontal scaling enables exponential growth in system throughput.
Vertical scaling refers to increasing the throughput of the overall system (e.g., Ethereum L1 or a data availability layer). Vertical scaling is typically needed when horizontal scaling hits bottlenecks on shared resources.
Claim 1: Rollups cannot scale horizontally because they may hit bottlenecks around data availability (DA). Vertically scaling DA solutions require trade-offs in decentralization.
Data availability (DA) remains a bottleneck for rollups. Currently, the maximum capacity target per L1 block is 1 MB (85 KB/s). In the long term, EIP-4844 will provide an additional ~2 MB (171 KB/s) of available space. With Danksharding, Ethereum L1 could eventually support up to 1.3 MB/s of DA bandwidth. Ethereum L1 DA is a shared resource competed for by many applications and services. Therefore, while using L1 as DA offers optimal security, it becomes a bottleneck for potential system scalability. Systems that use L1 as DA generally cannot scale horizontally and suffer from diseconomies of scale. Alternative DA layers, such as Celestia or EigenDA, also have bandwidth limits (though larger, at 6.67 MB/s and 15 MB/s respectively)—but this comes at the cost of shifting trust assumptions away from Ethereum to another (typically less decentralized) network, thereby compromising security.
Claim 2: The only known ways to horizontally scale trust-minimized services are achieving (near) zero marginal L1 data per transaction. Two known approaches are State Difference Rollups (SDRs) and validiums.
A State Difference Rollup (SDR) is a rollup that posts the state differences from a batch of aggregated transactions to Ethereum L1. For EVM, as transaction batches grow larger, the calldata posted per transaction approaches a constant—much smaller than the full transaction data in traditional rollups.
For example, during stress-testing events caused by massive inscription activity, zkSync found that calldata per transaction reduced to just 10 bytes. In contrast, under normal traffic, rollups like Arbitrum, Optimism, and Polygon zkEVM require approximately 100 bytes per transaction.
A validium is a system that posts validity proofs of state transitions to Ethereum without requiring associated transaction data or state. Even under low traffic conditions, validiums are highly horizontally scalable. Moreover, different validiums can share the same settlement layer.
Beyond horizontal scalability, validiums can offer on-chain privacy (from public observers). Validiums with private DA have centralized and gated data and state availability, meaning users must authenticate before accessing data, and operators can implement strong privacy practices. This creates a user experience similar to traditional web or financial services: user activity is not publicly monitored, but there exists a trusted custodian of user data—in this case, the validium operator.
What about centralized vs. decentralized sequencers? To maintain horizontal scalability, independent sequencers (whether centralized or decentralized) are crucial. Notably, systems using shared sequencers achieve atomic composability but cannot scale horizontally, as the sequencer itself may become a bottleneck as more systems are added.
What about interoperability? If horizontally scalable systems all settle on the same L1, they can interoperate without additional trust, since messages can be passed between systems via the shared settlement layer. A trade-off exists between operational costs and message delivery latency (which can be addressed at the application layer).
Trust Minimization in Horizontally Scalable Systems
Can we further minimize trust assumptions around liveness, sequencers, and data availability in horizontally scalable systems?
Notably, at the expense of horizontal scalability, we know how to recover trustless liveness and data availability. For instance, L2 transactions can be initiated from L1 to guarantee inclusion. Volition can allow users to opt into L1 state availability.
Another solution is simply to decentralize (without relying on L1). By using decentralized sequencers (e.g., Espresso Systems or Astria), systems can become more decentralized, minimizing trust required for liveness, ordering, and data availability. Compared to single-operator solutions, this approach has limitations: (1) performance may be constrained by distributed system overhead, and (2) for validiums with private DA, default privacy protections are lost if the decentralized sequencer network is permissionless.
For single-operator validiums or SDRs, how much trust dependency can we reduce? Here are several directions.
Direction 1: Trust-minimized data availability in validiums. Plasma partially solves state availability issues—either through withdrawal mechanisms for certain state models (including UTXO), or by requiring users to stay online periodically (“Plasma Freedom”).
Direction 2: Responsible pre-confirmations in SDRs and validiums. The goal here is to give users fast pre-confirmations from sequencers that their transactions will be included, and allow users to challenge the sequencer and trigger slashing if inclusion commitments are not honored. The challenge lies in proving non-inclusion, which may require users to provide extra data that the sequencer could simply withhold. Thus, it is reasonable to assume that we would at minimum require SDRs or validiums to employ a data availability committee for full calldata or transaction history, capable of providing proofs of non-inclusion (of pre-confirmed transactions) upon user request.
Direction 3: Fast recovery from liveness failures. Single-operator systems may encounter liveness failures (e.g., Arbitrum going down during the inscription event). Can we design systems that avoid service outages under similar circumstances? In a sense, L2s that allow self-ordering and state proposals do provide guarantees against prolonged liveness failure. Resilience against short-term liveness failures in single-operator systems remains underexplored. One potential solution is to impose slashing penalties on operators responsible for liveness failures. Another possibility is simply reducing the delay period before takeover (currently set to about a week).
Conclusion
Scaling a global settlement ledger while maintaining trust minimization is a hard problem. In today’s rollup and data availability landscape, the distinction between vertical and horizontal scaling is not yet clearly drawn. To truly extend trust-minimized systems to every corner of the globe, we need to build systems that are both trust-minimized and horizontally scalable.
Special thanks to Vitalik Buterin and Terry Chung for feedback and discussions, and to Diana Biggs for editorial comments.
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
1kx
