Differences in thinking patterns between L1 and L2: Who will prevail forever?

Cryptocurrency is leading a paradigm shift in database technology

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

Any user operation will eventually be reflected by executing transactions and updating the database.

The problem with “ Web2 ” database technology is all about the trust that makes it work. It relies on a trusted third party to maintain and protect the database.

If these third parties go offline, all access to the database is interrupted. If they make a mistake updating the database, the mistake may go undetected.

To build public confidence in the database, auditors could be hired to prove data integrity by retroactively checking the validity of database updates (not a simple task).

An open membership group of participants may be able to replace a trusted third party, which is why cryptocurrencies are leading a 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 review updates to the database in real time, allowing them to reject errors immediately and discover errors immediately after an update.

Open membership groups are fundamental to this paradigm shift and can be divided into two roles:

• Proposer : A subject that can propose updates to the database.

• Validator : A subject that can check the validity of a proposal to update the database.

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

However, how to implement open membership groups requires asking several important questions:

• Who are proposers ? How do I become one? How big does the group need to be?

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

• How do we reach consensus on accepting an update?

The architecture of this system and its fundamental significance to database security will answer the above questions. We explore the architecture of L1 and L2, and the ultimate goal is to help readers establish a good mindset.

L1 thinking patterns

L1 database must be acceptable to the economic majority (“the world”)

In L1 systems, trusted third parties are replaced by public consensus .

The purpose is to get all participants to agree on the update of 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 updates to the database. One or more proposers can propose a competing update, but eventually all participants converge on one update to the database and one fact about the database's contents.

The need for network consensus affects participation:

A limited ratio of proposers . Membership needs to be open, but limited to participants who have an economic incentive to succeed in the long term. This is to prevent a flood of conflicting updates, which ultimately makes it difficult for all parties to agree on an update.

Maximize 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 verify all updates in real time. Otherwise, they will not be able to keep up and will not be able to calculate the latest copy of the database.

We can use this opportunity to discuss how to restrict who can be a proposer, how to weigh broad replication of the database, and who is the final say on an authoritative chain (and database).

The goal is to find "risk-sharing" proposers whose economic interests are aligned with the long-term prosperity of the network.

This can be achieved by assigning the right to become a proposer based on ownership of a scarce resource (which is economically expensive to obtain).

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

In proof-of-stake , the proposer must own the chain’s tokens and lock them into the on-chain program. 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 is determined by the time it takes for an update to be accepted by all participants.

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

In practice, networks like Bitcoin and Ethereum maximize the cases where you can participate as a validator, while networks like Solana aim for low fees as long as it can be maintained. Interestingly, validators on ICP must be licensed and purchase hardware from specific vendors.

Economic majority . Most of the time, we can think of proposers and validators as a collective protecting the database. However, the ultimate goal is to convince the economic majority, that is, those who have a vested economic interest in usage.

These proposers and validators are only proxies for the economic majority in normal operation, but if changes to the network consensus rules become controversial, they are ultimately decided by the majority of users around the world, who will judge based on the external economic value of the resulting database.

For example, the market caps of Bitcoin vs. Bitcoin Cash and Ethereum vs. Ethereum Classic clearly show who the winners are after a major disagreement in the community over the path forward.

In summary, the L1 mindset is to think of L1 as a database that is ultimately responsible for determining asset ownership and for having an economic majority accept all demands for database updates. This is why decentralization is critical to the success of L1 from a technical, social, and economic perspective.

It aims to replicate the database as widely as possible, maximize the number of validators participating in the process of securing the database, and ultimately, rely on an economic majority to determine its real-world value.

L2 thinking patterns

The bridge contract holds all assets while the L2 database records liabilities

On L2 systems, trusted third parties are replaced by smart contracts, which have two components to consider:

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

• The off-chain database is a database that records the debt status of the off-chain system.

The bridge is responsible for bridging assets from one database (L1 system) to another database (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 (e.g., every state change of the database applied on the L2 system).

This is critical to ensure that the assets held on the bridge contract can cover the liabilities recorded in the off-chain database, otherwise it will lead to a large-scale withdrawal of funds.

Maintaining the independence of the bridge contract affects participation:

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

• A single validator . Only when the bridge contract is convinced that the proposed update to the off-chain database is valid will it allow the release of assets.

  
  

Below we consider the architecture of L2 systems, 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 such as Coinbase. Users deposit tokens into the bridge contract on L1, the deposit is reflected on the off-chain database, and most transactions are processed by the off-chain database.

This approach has helped the cryptocurrency market scale over the past 12 years as most users interact with centralized services and use the underlying L1 systems as an interoperability solution to move funds from one service to another.

Historically, off-chain databases have been maintained by operators (such as Coinbase) and have determined whether a withdrawal should be processed by a bridge contract.

Evolution of trust assumptions . Over the past few years, we have seen changes in the trust assumptions of bridge contracts, i.e. how it can be assured of the integrity of the off-chain database. Trust assumptions have evolved from a single institution bridging, to multiple institutions bridging, to a consensus protocol on an external blockchain.

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

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

Database accessibility . Only the bridge contract can determine what the real database is and release assets to users. Making the database publicly accessible is to ensure the liveness of the L2 system.

The contract assumes that an honest party will emerge, who will become the 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 secure a database, or rely on an economic majority to decide which database should have external real-world value.

Therefore, the L2 mindset is about bridging contracts and supporting contracts in doing their best to protect the assets they hold. Contracts have the sole authority to decide which updates to the database are accepted, regardless of what the majority of participants believe.

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

* There is one caveat to optimistic rollup, as it assumes that there will be an honest party to assist the bridge contract in verifying updates to the off-chain database, but ultimately, it is the final decision made by the bridge contract that is truly important.

Comparison and summary

The architecture and purpose of L1 and L2 systems are different:

• L1 system . Its goal is to reach public consensus and eventually converge on a single global truth about the state of the database.

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

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

However, on L2 systems, there is no need for majority agreement or external asset valuation. It already assumes that the L1 system has achieved public consensus, and its only concern is to protect the assets held by the smart contract. Therefore, it can rely on the presence of an honest party to ensure that the system continues to move forward.

This is why, in my opinion, 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 tries to contrast the two is because L2 systems emerge because L1 scalability hits a wall. One of my soft goals is to change that narrative, because layer 2 systems should be seen as an evolution of bridge contracts.

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

Finally, I hope this article can help readers develop a good mindset in terms of system architecture and trust assumptions for L1 and L2 systems. I also hope that L2 protocols can continue to flourish and demonstrate their superiority over hosted solutions.

Not because users care about the security of the system, but because I believe the operators can provide the exact same service without the risk of protecting billions of dollars, making custody (and trust) an unnecessary, obstructive responsibility.