1kx: The end result of blockchain expansion is trust minimization and horizontal expansion
Original author: weidai.eth
Original compilation: Luffy, Foresight News
Ethereum is a permissionless world computer that, at the time of writing, has the highest economic security and acts as a 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 expansion is considered to be the best solution to this problem. In recent years, a large number of projects have entered this field, most of which are Rollup. However, Rollup, in the strict sense of the term (data is located on Ethereum L1), does not achieve unlimited expansion of Ethereum, and its upper limit is to process thousands of transactions per second.
First, please understand two concepts:
Trust minimization: If the functionality of an L2 system does not require trusting parts outside the underlying L1, then (a feature of) the system is trust minimization.
Horizontal scalability: A system is horizontally scalable if instances can be added without creating a global bottleneck.
In this article, we argue that trust-minimized and horizontally scalable systems are the most promising way to scale blockchain applications, but this direction is currently underexplored. We develop our argument by exploring three questions:
Why should applications be trust-minimized?
Why build a system that scales horizontally?
How can we enhance trust minimization and horizontal scalability?
Disclaimer: While this article focuses on Ethereum as the underlying L1, much of what we discuss here also applies to other decentralized settlement layers outside of Ethereum.
Why should applications be trust-minimized?
Applications can connect to Ethereum in a trustworthy way, and they can write and read data on the Ethereum blockchain, but trust is required that the business logic will be executed correctly. Centralized exchanges like Binance and Coinbase are great examples of trusted applications. Connecting to Ethereum means applications can take advantage of the global settlement network with multiple assets.
There are significant risks associated with trusted off-chain services. The collapse of major exchanges and services in 2022 (such as FTX and Celsius) is a good cautionary tale of what happens when trusted services misbehave and fail.
On the other hand, trust-minimized applications can write to and read from Ethereum in a verifiable manner, such as smart contract applications like Uniswap, Rollups like A.bitrum or zkSync, and co-processors like Lagrange and Axiom. Broadly speaking, as applications are secured by the Ethereum network and more functionality is assigned to L1, trust is removed. As a result, trust-minimized financial services can be provided without counterparty or custodian risk.
By outsourcing functionality to an L1, applications and services gain three key attributes:
Liveness (and ordering): User-submitted transactions should be included (executed and settled) in a timely manner.
Validity: Transactions are processed according to pre-specified rules.
Data (and state) availability: Users can access historical data as well as current application state.
For each of the above properties, we can think of what trust assumptions are required; in particular, whether Ethereum L1 provides that property or whether external trust is required. The table below categorizes different architectural examples.
Why build a system that scales horizontally?
Horizontal scaling refers to scaling by adding independent or parallel instances to the system, such as applications or rollups. This requires that there are no global bottlenecks in the system. Horizontal scaling can achieve exponential growth in system throughput.
Vertical scaling refers to scaling by increasing the throughput of the overall system (such as Ethereum L1 or data availability layer). Vertical scaling is often required when horizontal scaling encounters bottlenecks such as on shared resources.
Statement 1: Rollups cannot scale horizontally because they may encounter data availability (DA) bottlenecks. Vertically scaling DA solutions requires compromises in decentralization.
Data availability (DA) remains a bottleneck for Rollup. Currently, the maximum capacity target for each L1 block is 1 MB (85 KB/s). In the long run, EIP-4844 will provide approximately 2 MB (171 KB/s) of additional free space. Through Danksharding, Ethereum L1 may eventually support DA bandwidth of up to 1.3 MB/s. Ethereum L1 DA is a resource that many applications and services compete against. Therefore, although using L1 as DA provides the best security, it becomes a bottleneck in the potential scalability of the system. Systems using L1 as DA do not (generally) scale horizontally and suffer from diseconomies of scale. Alternative DA layers, such as Celestia or EigenDA, also have bandwidth limits (albeit larger ones, 6.67 MB/s and 15 MB/s respectively). But this comes at the cost of moving trust assumptions from Ethereum to another (usually less decentralized) network, compromising security.
Statement 2: The only way to scale a trust-minimized service horizontally is to achieve (near) zero marginal L1 data per transaction. Two known methods are state difference rollup (SDR) and validitys.
State Difference Rollup (SDR) is a rollup that publishes the state differences in a batch of aggregated transactions to Ethereum L1. For EVM, as the transaction batch becomes larger, each transaction data published to L1 will approach a constant, which is much smaller than the transaction data of Rollup.
For example, during a stress test event with a large influx of inscriptions, zkSync saw calldata reduced to 10 bytes per transaction. By comparison, rollups like Arbitrum, Optimism, and Polygon zkEVM are around 100 bytes per transaction for normal traffic.
validium is a system for publishing validity proofs of state transitions to Ethereum without associated transaction data or state. Validium is highly horizontally scalable even under low traffic conditions. And different validiums can share the settlement layer.
In addition to horizontal scalability, validium can provide on-chain privacy (from public observers). Validium with Privacy DA has centralized and gated data and state availability, meaning users must authenticate before accessing data and operators can implement good privacy practices. This enables a user experience similar to traditional web or financial services: user activity is not subject to public scrutiny, but there is a trusted custodian of user data, in this case the Validium operator.
What about centralized sorters versus decentralized sorters? To maintain horizontal scalability of the system, independent sorters (either centralized or decentralized) are crucial. It is worth noting that although systems using a shared sorter are atomically composable, they do not scale horizontally because the sorter can become a bottleneck as more systems are added.
What about interoperability? If horizontally scalable systems are all on the same L1 settlement, they can interoperate without additional trust because messages can be sent from one system to another through the shared settlement layer. There is a trade-off between operational costs and message delivery latency (this can be addressed at the application layer).
Trust minimization for horizontally scalable systems
Can we further minimize the trust requirements for liveness, orderers, and data availability in horizontally scalable systems?
Remarkably, we know how to salvage trustless liveness and data availability at the expense of horizontal scalability. For example, L2 transactions can be initiated from L1 to ensure inclusion. Volition can provide users with opt-in L1 status availability.
Another solution is to simply decentralize (but not rely on L1). By using a decentralized sequencer (such as Espresso Systems or Astria), rather than using a single sequencer, the system can become more decentralized, minimizing the trust required for liveness, ordering, and data availability. There are limitations to doing so compared to single operator solutions: (1) performance may be limited by distributed system performance, (2) for validiums with privacy DA if the decentralized sequencer network is permissionless , the default privacy protection will be lost.
How much more trust dependence can we reduce on single carrier validitys or SDRs? There are several directions here.
Direction 1: Trust-minimized data availability in validiums. Plasma solves the state availability problem to a certain extent, either the withdrawal problem of certain specific state models (including the UTXO state model), or requiring users to be online regularly (Plasma Free).
Direction 2: Responsible pre-validation in SDRs and validiums. The goal here is to provide users with fast pre-confirmation of sequencer inclusion transactions, and should allow users to challenge and impose staking penalties on the sequencer if inclusion promises are not fulfilled. The challenge here is to prove that the transaction was not included, which may require the user to provide additional data, which the sequencer can simply retain. Therefore, it is reasonable to assume that we at least require SDR or validium to hire a data availability committee for its complete calldata or transaction history, and the committee can provide proof of non-containment (pre-confirmed transactions) upon user request.
Direction 3: Fast recovery from active faults. Individual operator systems may experience active failures (such as Arbitrum being down during the Inscription event). Can we design a system that will not experience service interruption in similar situations? In a sense, L2 allowing self-ordering and state proposal does provide guarantees against long-term liveness failures. Single-operator systems that are more resilient to short-term active failures are currently underexplored. One potential solution here is to impose liability through curtailment of active faults. Another possible solution is to simply shorten the delay period before taking over (currently set at around a week).
in conclusion
Scaling a global settlement ledger while keeping trust minimal is a difficult problem. In todays world of rollup and data availability, there is no clear distinction between vertical scaling and horizontal scaling. In order to truly extend trust-minimized systems to every corner of the planet, we need to build trust-minimized and horizontally scalable systems.
Many thanks to Vitalik Buterin and Terry Chung for feedback and discussion, and to Diana Biggs for editorial comments.
