To truly extend the trust-minimized system to every corner of the earth, it is necessary to build a trust-minimized and horizontally scalable system.
Written by: weidai.eth
Translated by: Luffy, Foresight News
Ethereum is a permissionless world computer. At the time of writing, it has the highest economic security and serves as a settlement ledger for a large number of assets, applications, and services. However, Ethereum 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, many projects have entered this field, with most of them being Rollups. However, strictly speaking, Rollups (with data on Ethereum L1) cannot achieve infinite scalability for Ethereum, with a limit of processing only a few thousand transactions per second.
First, please understand two concepts:
Trust minimization: If the functionality of an L2 system does not require trust in parts outside of the underlying L1, then this system (or its functionality) is trust-minimized.
Horizontal scalability: If instances can be added without creating a global bottleneck, the system is horizontally scalable.
In this article, we believe that trust-minimized and horizontally scalable systems are the most promising way to expand blockchain applications, but this direction has not been fully explored. We reach this conclusion by discussing three issues:
Why should applications be trust-minimized?
Why build a horizontally scalable system?
How can we enhance trust minimization and horizontal scalability?
Disclaimer: Although this article focuses on Ethereum as the underlying L1, most of the content discussed here is also applicable to other decentralized settlement layers outside of Ethereum.
Why should applications be trust-minimized?
Applications can connect to Ethereum in a trusted manner, allowing them to write to and read from the Ethereum blockchain, but the area where trust is needed is in ensuring that business logic is executed correctly. Centralized exchanges such as Binance and Coinbase are excellent examples of trusted applications. Connecting to Ethereum means that applications can leverage a global settlement network with a variety of assets.
Trusted off-chain services pose significant risks. The collapse of major exchanges and service providers in 2022 (such as FTX and Celsius) is a good cautionary tale about what happens when trusted services behave improperly 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 Arbitrum or zkSync, and coprocessors like Lagrange and Axiom. In general, as applications are protected by the Ethereum network and more functionality is allocated to L1, trust is eliminated. Therefore, trust-minimized financial services can be provided without counterparty or custodian risk.
By outsourcing functionality to L1, applications and services can obtain three key attributes:
Liveness (and ordering): Transactions submitted by users should be included (executed and settled) in a timely manner.
Validity: Transactions should be processed according to pre-specified rules.
Data (and state) availability: Users should be able to access historical data and the current state of the application.
For each of the above attributes, we can consider what trust assumptions are needed; in particular, whether Ethereum L1 provides the attribute or if external trust is required. The table below categorizes different architectural paradigms.
Why build a horizontally scalable system?
Horizontal scalability involves expanding the system by adding independent or parallel instances, such as applications or Rollups. This requires that the system does not have a global bottleneck. Horizontal scalability can achieve exponential growth in system throughput.
Vertical scalability involves increasing the throughput of the overall system (such as Ethereum L1 or data availability layer). When horizontal scalability encounters bottlenecks in shared resources, vertical scalability is often needed.
Disclaimer 1: Rollups cannot horizontally scale because they may encounter data availability (DA) bottlenecks. Vertical scaling of DA solutions requires compromises in decentralization.
Data availability (DA) remains a bottleneck for Rollups. Currently, the maximum capacity target for each L1 block is 1 MB (85 KB/s). In the long term, EIP-4844 will provide an additional approximately 2 MB (171 KB/s) of available 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 for. Therefore, while using L1 as DA can provide optimal security, it becomes a potential bottleneck for system scalability. Systems using L1 as DA (usually) cannot horizontally scale and are not economically scalable. Alternative DA layers, such as Celestia or EigenDA, also have bandwidth limitations (although larger, at 6.67 MB/s and 15 MB/s, respectively). However, this comes at the cost of transferring trust assumptions from Ethereum to another (usually less decentralized) network, compromising security.
Disclaimer 2: The only way to horizontally scale trust-minimized services is to achieve (near) zero marginal L1 data for each transaction. Two known methods are State Delta Rollup (SDR) and validiums.
State Delta Rollup (SDR) involves publishing the state differences of a batch of aggregated transactions to the Rollup on Ethereum L1. For EVM, as the transaction batch size increases, the data published to L1 for each transaction approaches a constant, much smaller than the transaction data for Rollup.
For example, in the stress test event with a large influx of transactions, zkSync found that the calldata for each transaction decreased to 10 bytes. In comparison, for normal traffic, Rollups such as Arbitrum, Optimism, and Polygon zkEVM have transaction data of approximately 100 bytes per transaction.
Validium is a system that publishes validity proofs of state transitions to Ethereum without associated transaction data or state. Even under low traffic conditions, Validium is highly horizontally scalable. Different validiums can share settlement layers.
In addition to horizontal scalability, validium can also provide on-chain privacy (from public observers). Validium with privacy DA has centralized and gated data and state availability, meaning users must be authenticated before accessing data, and operators can enforce good privacy measures. This achieves a user experience similar to traditional networks or financial services: user activities are not subject to public supervision, but there is a trusted user data custodian, in this case the validium operator.
What about centralized vs. decentralized sequencers? To maintain the horizontal scalability of the system, independent sequencers (whether centralized or decentralized) are crucial. It is worth noting that systems using a shared sequencer have atomic composability but cannot horizontally scale, as the sequencer may become a bottleneck with the addition of more systems.
What about interoperability? If horizontally scalable systems settle on the same L1, they can achieve interoperability without additional trust, as messages can be sent from one system to another through the shared settlement layer. Trade-offs need to be made between operating costs and message delivery latency (which can be addressed at the application layer).
Trust minimization of horizontally scalable systems
Can we further minimize the trust requirements for liveness, sequencers, and data availability in horizontally scalable systems?
It is worth noting that, at the cost of horizontal scalability, we know how to salvage trustless liveness and data availability. For example, L2 transactions can be initiated from L1 to ensure inclusion. Volition can provide users with the choice to join L1 state availability.
Another solution is to simply decentralize (but not rely on L1). By using decentralized sequencers (such as Espresso Systems or Astria) instead of a single sequencer, the system can become more decentralized, minimizing the trust required for liveness, sequencing, and data availability. However, this approach has limitations compared to a single operator solution: (1) performance may be limited by the performance of distributed systems, and (2) for validiums with privacy DA, default privacy protection may be lost if the decentralized sequencer network is permissionless.
How much trust dependency can we reduce for single operator validiums or SDRs? There are several directions here.
Direction 1: Trust minimization of data availability in validiums. Plasma partially addresses the issue of state availability, either by presenting certain specific state models (including UTXO state models) or by requiring users to be online regularly (Plasma Free).
Direction 2: Responsible pre-confirmation in SDRs and validiums. The goal here is to provide users with fast pre-confirmation of sequencer-included transactions and to allow users to initiate challenges and impose stake penalties on sequencers if inclusion commitments are not fulfilled. The challenge here is to prove that transactions were not included, which may require users to provide additional data, while sequencers can simply retain this data. Therefore, we can reasonably assume that we require SDR or validium to employ a data availability committee for its complete calldata or transaction history, which can provide proof of non-inclusion (pre-confirmed transactions) upon user request.
Direction 3: Rapid recovery from liveness failures. A single operator system may encounter liveness failures (such as Arbitrum crashing during the influx event). Can we design a system that does not experience service interruptions in similar situations? In a sense, L2 systems that allow self-sequencing and state proposals do provide a guarantee against prolonged liveness failures. More resilient single operator systems for short-term liveness failures have not been fully explored. One potential solution here is to hold relevant parties accountable by reducing liveness failures. Another possible solution is simply to shorten the latency period before takeover (currently set at around one week).
Conclusion
Expanding the global settlement ledger while maintaining trust minimization is a challenge. There is currently no clear distinction between vertical and horizontal scaling in today's Rollup and data availability space. To truly extend the trust-minimized system to every corner of the earth, we need to build a trust-minimized and horizontally scalable system.
Special thanks to Vitalik Buterin and Terry Chung for their feedback and discussions, as well as Diana Biggs for her editorial comments.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
