Partnered With:

Exploring L1 and L2 mindset differences and evolution of trust assumptions

Read this article in 21 Minutes

This paper starts from the perspective of thinking mode and explains the architecture, trust assumptions and participants of L1 and L2 systems.

Original title: " Mental models for L1 and L2 "

Original author: Patrick McCorry

Original compilation: ETH Chinese

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

Any user operation will eventually be reflected in the form of 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 secure the database.

Cryptocurrency is ushering in a paradigm shift in database technology

If these third parties go offline, all access to the database will be interrupted. If they made a mistake updating the database, the mistake could have gone undetected.

In order to build public confidence in the database, auditors can be hired to check database updates retrospectively validity (not an easy task) to prove data integrity.

A group of participants with open membership may be able to replace a trusted third party, which It’s also why cryptocurrencies are ushering in a paradigm shift (“Web3”) in database technology.

It allows anyone willing to contribute resources to read, write, audit, and eventually Protect the integrity and content of the database. This group can check the database for updates in real time, which also allows them to immediately reject errors and find errors immediately after the update.

Open membership groups are the basis of this paradigm shift, which can be broken down into two Roles:

- Proposer: A principal that can propose updates to the database.

- Validator: A principal that can check the validity of proposals to update the database.

The mindset of participation is similar to a cryptographic protocol, where a group of parties (proposers) want to To prove a claim is correct, another set of parties (validators) must check it for correctness before accepting it. This interactive process is repeated every time the database is updated.

However, implementing open membership groups requires asking several important questions:

- Who is the proposer? 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 agree on accepting an update?

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

< p>

L1 thinking mode

The L1 database must be economically majority(" world")

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

The purpose is to allow all participants to agree to 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 database updates. 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 contents of the database.

The need for network consensus affects participation:

The number of proposers to limit the ratio. Membership needs to be open, but limited to those participants who are financially incentivized from the long-term success of the system. This is to prevent a flood of conflicting updates that end up making 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 computing and bandwidth resources to validate all updates in real time. Otherwise, they won't be able to keep up and won't be able to compute the latest copy of the database.

We can use this as an opportunity to discuss how to limit who can be a proposer and how to weigh the broadness of the database Replicas and who is the final decider on an authoritative chain (and database).

The number of proposers to limit the ratio. Our 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 be a proposer, based on the need for scarce resources Ownership (acquiring this resource is economically expensive).

For example, in a proof-of-work mechanism, the proposer must have efficient hardware and In order to compete in the mining market, we must have an efficient source of electricity.

In the equity proof mechanism, the proposer must own the Token of the chain and lock it into the chain in the program. In both cases, the frequency at which new updates are proposed is proportional to the number of all other participants.

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

During congestion, as users scramble to have their transactions accepted before others , there will be a trade-off between the throughput of the network and the affordability of transactions.

In fact, networks like Bitcoin and Ethereum maximize the participation, while networks like Solana aim for low fees for as long as it can sustain them. Interestingly, ICP validators must be licensed and purchase hardware from specific vendors.

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

These proposers and validators are just proxies for the economic majority under normal operating conditions, but If a modification to the network's consensus rules is contested, the decision will ultimately be made by a global majority of users who will judge from the external economic value of the resulting database.

For example, the market cap of Bitcoin vs Bitcoin Cash and Ethereum vs Ethereum Classic clearly shows that the community Who is the winner after major disagreements on the way forward.

In short, the thinking mode of L1 is to regard L1 as a database, which is ultimately responsible for determining assets Ownership and having an economic majority accept all requests for database updates. This is why decentralization is critical to the success of L1 from a technical, social and economic perspective.

Its purpose is to make as many copies of the database as possible to maximize participation in the database protection process The number of validators, in the end, relies on the economic majority to determine its real-world value.

< p>

L2 thinking mode

bridge contract holds all assets and L2 database records Liabilities

On the L2 system, trusted third parties are Smart contracts, where two components are considered:

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

- The off-chain database is a database that records liabilities for the off-chain system.

Bridging 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 bridge assets by checking the integrity of the off-chain database.

To maintain its integrity, the contract checks every proposed Updates are checked for validity before acceptance (eg, every state change applied to the database on the L2 system).

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

Maintaining the independence of the bridging contract affects participation:

< br>

- Anyone can propose. The bridging contract should allow anyone to forcibly package transactions that will eventually be executed in the L2 system's off-chain database.

- A single validator. Assets are only allowed to be released if the bridge contract is confident that the proposed update to the off-chain database is valid.

Below we consider the architecture of L2 systems, how trust assumptions evolve, and making databases publicly available the purpose of the visit.

Architecture and centralized services. L2 systems are architected similarly to centralized services such as Coinbase. user will Token Deposits into bridge contracts on L1, deposits are reflected on off-chain databases, and most transactions are processed by off-chain databases.

This approach has helped the cryptocurrency market expand over the past 12 years as most Users interact with centralized services and use the underlying L1 system as an interoperable solution for moving funds from one service to another.

Historically, off-chain databases have been secured by operators such as Coinbase, and Determines whether a withdrawal is processed by the bridge contract.

Evolution of trust assumptions. Over the past few years, we have witnessed a change in the trust assumptions of the bridging contract, i.e. how it is sure of the integrity of the off-chain database. Trust assumptions have evolved from a single agency bridge, multiple agency bridges, to a consensus protocol for external blockchains.

In any event, the bridge contract must blindly trust a The judgment of the group participants.

This has also led to billions of dollars being stolen because billions of dollars provide security The manual processing flow of the network is difficult to replicate on hundreds of bridges. The goal of the L2 system is to completely remove trust in intermediaries, allowing bridges to independently verify proposed updates to the data database.

Database accessibility. Only the bridge contract can decide what is the real database and release the assets to users. The purpose of making the database publicly accessible is to guarantee the liveness of the L2 system.

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

Therefore, there is no need to create a very large validator network to secure the database, or rely on economic Most to decide which database should have external real world value.

So the L2 mindset is about bridging contracts and supporting contracts trying to protect what they hold assets. Regardless of what the majority of participants believe, the contract has the sole power to determine which updates to the database are accepted.

At the same time, the participant network still hopes to ensure the liveness of the L2 system and guarantee that it will Updates are constantly being proposed to the smart contract. However, this is not to rely on a global mesh network to protect the integrity of the database (security property).

* optimistic rollup is a bit to be reminded because it It is assumed that there will be an honest party assisting the bridge contract to verify updates to the off-chain database, but in the end, it is the final decision made by the bridge contract that really matters.

< p>

Comparison and summary

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

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

- L2 system. The goal is to build a system that makes smart contracts trust the integrity (and state) of the off-chain database.

The two systems differ fundamentally in their 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 consent or external asset valuation . It already assumes that the L1 system achieves public consensus and its sole concern is securing assets held by smart contracts. Therefore, it can rely on the presence of an honest party to keep the system going.

In my opinion, this is why the contrast between L1 and L2 is two completely A comparison between different things. The two systems have different trust assumptions, participants, and final system architectures.

The only reason our community tries to compare the two is that the L2 system came about because L1 scalability has hit a bottleneck. One of my soft goals is to change that narrative, because second-tier systems should be seen as an evolution of bridge contracts.

So, they should work with a custodial service like Coinbase, which protects 10% of all crypto assets % above) for comparison, because the systems on both sides are responsible for protecting the database and a basket of assets under the chain.

Finally, I hope this article can help readers in the system architecture and Build a good mindset in terms of trust assumptions. It is also hoped that L2 protocols will continue to prosper and demonstrate their superiority over managed solutions.

Not because users care about the security of the system, but because I believe that operators can provide complete The same service without taking the risk of protecting billions of dollars. As such, trusteeship (and trust) becomes an unnecessary, intrusive liability.