In-depth analysis of the differences in thinking patterns between L1 and L2

Original Author: Patrick McCorry

Original Title: 《Mental models for L1 and L2》

Translation: ethereum.cn

Cryptocurrency is leading a paradigm shift in database technology.

The cornerstone of cryptocurrency is the database. It records the balances of all user accounts, the code and state of smart contracts.

Any user operation will ultimately be reflected through executing transactions and updating the database.

The problem with "Web2" database technology lies in the trust that enables it to operate. It relies on a trusted third party to maintain and protect the database.

If these third parties go offline, all access to the database will be interrupted. If they make a mistake while updating the database, that error may go unnoticed for a long time.

To build public confidence in the database, auditors can be hired to retrospectively check the validity of database updates (not a simple task) to prove data integrity.

A group of open membership participants may replace a trusted third party, which is why cryptocurrency is leading the paradigm shift in database technology ("Web3").

It allows anyone willing to contribute resources to read, write, audit, and ultimately protect the integrity and content of the database. This group can check database updates in real-time, allowing them to immediately reject errors and discover mistakes right after updates.

The open membership group is the foundation of this paradigm shift, which can be divided into two roles:

• Proposers: Entities that can propose updates to the database.

• Validators: Entities that can check the validity of proposed updates to the database.

The mindset of participation is similar to cryptographic protocols, where one group of participants (proposers) wants to prove a statement is correct, while another group of participants (validators) must check its correctness before accepting it. This interactive process is repeated with every update to the database.

However, several important questions need to be raised about how to implement an open membership group:

• Who are the proposers? How do I become a proposer? How large does this group need to be?

• Who are the validators? Do I need to register? How large does this group need to be?

• How do we reach consensus on accepting an update?

The architecture of this system and its fundamental implications for database security will answer the above questions. We explore the architectures of L1 and L2, with the ultimate goal of helping readers establish a good mindset.

L1 Mindset

The L1 database must be accepted by the economic majority ("the world").

In the L1 system, the trusted third party is replaced by public consensus.

The purpose is to have all participants agree on updates to the database. This requires a set of common rules ("consensus rules") that can be objectively followed by all parties.

These rules are used to prove the validity of database updates. One or more proposers can propose a competing update, but ultimately all participants converge on a single update to the database and a single fact about the database's content.

The demand for network consensus affects participation:

Limited ratio of proposers. Membership needs to be open but limited to those participants who have economic incentives tied to the long-term success of the system. This is to prevent a flood of conflicting updates, which would ultimately make it difficult for all parties to reach consensus on a single update.

Maximizing the number of validators. The frequency and size of updates will determine the number of validators, as they must have the computational and bandwidth resources to validate all updates in real-time. Otherwise, they will fall behind and will not be able to compute the latest copy of the database.

We can take this opportunity to discuss how to limit who can become a proposer, how to balance the widespread copies of the database, and who is the ultimate decision-maker of an authoritative chain (and database).

Limited ratio of proposers. Our goal is to find proposers who "share the risk," whose economic interests align with the long-term prosperity of the network.

This can be achieved by allocating the right to become a proposer based on ownership of scarce resources (acquiring such resources is economically expensive).

For example, in a proof-of-work mechanism, proposers must have efficient hardware and cost-effective power sources to compete in the mining market.

In a proof-of-stake mechanism, proposers must own tokens of the chain and lock them in on-chain programs. In both cases, the frequency of proposing new updates is proportional to the number of all other participants.

Affordability vs. Verifiability. The throughput of the network depends on the time required for an update to be accepted by all participants.

During congestion, there is a trade-off between the network's throughput and the affordability of transactions, as users rush to have their transactions accepted before others.

In practice, networks like Bitcoin and Ethereum maximize the number of participants who can act as validators, while networks like Solana aim for low fees as long as they can maintain it. Interestingly, ICP validators must be permitted and purchase hardware from specific vendors.

Economic Majority. Most of the time, we can view proposers and validators as a collective protecting the database. However, their ultimate goal is to persuade the economic majority, namely those who have vested economic interests from a usage perspective.

These proposers and validators are merely agents of the economic majority under normal operating conditions, but if there is a dispute over changes to the network consensus rules, it is ultimately the global majority of users who will decide, judging from the external economic value of the resulting database.

For example, the market capitalization of Bitcoin compared to Bitcoin Cash and Ethereum compared to Ethereum Classic clearly indicates who the winners are after significant community divergences on the path forward.

In summary, the mindset of L1 is to view L1 as a database that ultimately determines asset ownership and allows an economic majority to accept all demands for updates to the database. This is why decentralization is crucial for the success of L1 from technical, social, and economic perspectives.

Its purpose is to replicate copies of the database as widely as possible, maximize the number of validators participating in the database protection process, and ultimately rely on the economic majority to determine its value in the real world.

L2 Mindset

Bridge contracts hold all assets while the L2 database records liabilities.

In the L2 system, the trusted third party is replaced by smart contracts, which involve two components:

• Bridge Contract, a smart contract that holds assets on the L1 system.

• Off-chain Database, a database that records liabilities for the off-chain system.

The bridge is responsible for transferring assets from one database (L1 system) to another (L2 system).

The sole responsibility of the bridge contract is to protect the bridged assets by checking the integrity of the off-chain database.

To maintain its integrity, the contract checks every proposed update to the off-chain database for validity before accepting it (for example, every state change of the database applied in the L2 system).

This is crucial to ensure that the assets held on the bridge contract can cover the liabilities recorded in the off-chain database; otherwise, it could lead to a massive withdrawal of funds.

Maintaining the independence of the bridge contract will affect participation:

• Anyone can propose. The bridge contract should allow anyone to force the packaging of transactions that will ultimately be executed in the off-chain database of the L2 system.

• Single Validator. Assets will only be released if the bridge contract is confident that the proposed update to the off-chain database is valid.

Next, we consider the architecture of the L2 system, how trust assumptions evolve, and the purpose of making the database publicly accessible.

Architecture and Centralized Services. The architecture of the L2 system is similar to centralized services (like Coinbase). Users deposit tokens into the bridge contract on L1, and deposits are reflected in the off-chain database, with most transactions processed by the off-chain database.

Over the past 12 years, this approach has helped scale the cryptocurrency market, as most users interact with centralized services and treat the underlying L1 system as a solution for interoperability, transferring funds from one service to another.

Historically, off-chain databases have been protected by operators (like Coinbase), who decide whether a withdrawal is processed by the bridge contract.

Evolution of Trust Assumptions. In recent years, we have witnessed changes in the trust assumptions of bridge contracts, specifically how they ensure the integrity of the off-chain database. Trust assumptions have evolved from single-entity bridging, to multi-entity bridging, to consensus protocols of an external blockchain.

In any case, the bridge contract must blindly trust the judgment of a group of participants before returning assets to users.

This has also led to billions of dollars being stolen, as the manual processes providing security for billions of dollars are difficult to replicate across hundreds of bridges. The goal of the L2 system is to completely eliminate trust in intermediaries, allowing bridges to independently verify proposed updates to the database.

Database Accessibility. Only the bridge contract can decide what constitutes the real database and release assets to users. Making the database publicly accessible is to ensure the vitality of the L2 system.

The contract assumes that an honest party will emerge, who will become a proposer, take over the list of pending transactions, and propose updates to the database.

Therefore, there is no need to create a very large network of validators to protect the database, nor to rely on the economic majority to determine which database should have external real-world value.

Thus, the L2 mindset is about the bridge contract and supporting contracts doing their best to protect the assets they hold. Regardless of what most participants believe, the contract has the sole authority to decide which updates to the database can be accepted.

At the same time, the participant network still hopes to ensure the vitality of the L2 system and guarantee that updates will continuously be proposed to the smart contract. However, this does not rely on a global mesh network to protect the integrity of the database (security properties).

It is worth noting about optimistic rollups that it assumes there will be an honest party to assist the bridge contract in verifying updates to the off-chain database, but ultimately, the final decision made by the bridge contract is what truly matters.

Comparison and Summary

The architectures and purposes of L1 and L2 systems are different:

• L1 System. Its goal is to achieve public consensus and ultimately converge on a single global fact about the state of the database.

• L2 System. Its purpose is to construct a system that allows smart contracts to trust the integrity (and state) of the off-chain database.

The two systems have fundamental differences in trust assumptions. The L1 system must rely on an honest majority to protect the integrity of the database and depend on the economic majority to assign real-world value to the assets recorded in the database.

However, in the L2 system, there is no need for majority consent or external asset valuation. It assumes that the L1 system has achieved public consensus, and its sole focus is on protecting the assets held by smart contracts. Therefore, it can rely on the emergence of an honest party to ensure the system continues to function.

In my view, this is why the comparison between L1 and L2 is a comparison between two completely different things. The two systems have different trust assumptions, participants, and ultimately system architectures.

The only reason our community attempts to compare the two is that the emergence of L2 systems is due to the scalability bottlenecks of L1. One of my soft goals is to change this narrative, as second-layer systems should be viewed as the evolution of bridge contracts.

Thus, they should be compared with custodial services (like Coinbase, which protects over 10% of all crypto assets) because both systems are responsible for protecting off-chain databases and a basket of assets.

Finally, I hope this article helps readers establish a good mindset regarding the system architectures and trust assumptions of L1 and L2 systems. I also hope that L2 protocols can thrive and demonstrate their superiority over custodial solutions.

Not because users care about the security of the system, but because I believe operators can provide exactly the same service without bearing the risk of protecting billions of dollars. In this way, custody (and trust) will become an unnecessary and cumbersome liability.