Cryptocurrencies are leading a paradigm shift in database technology
The cornerstone of cryptocurrencies is the database. It records the balances of all user accounts, the code and state of smart contracts.
Any user action will eventually be reflected in the form of executing transactions and updating the database.
The problem with “Web2” database technology is the trust that makes it work. It relies on a trusted third party to maintain and secure the database.
If these third parties go offline, all access to the database is interrupted. If they made a mistake updating the database, the bug may have gone undetected.
To build public confidence in the database, auditors can be hired to prove data integrity by retrospectively checking the validity of database updates (not a simple task).
A group of participants with open membership could potentially replace a trusted third party, which is why cryptocurrencies are 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 contents of the database. This group can check for updates to the database in real time, which also allows them to reject errors immediately and catch them as soon as they are updated.
Open-membership groups are the basis for this paradigm shift, which can be divided into two roles:
- Proposer: A subject who can propose an update to the database.
- Validator: A subject who can check the validity of a proposal to update the database.
The mindset of participation is similar to a cryptographic protocol, where one set of parties (proposers) want to prove a claim is correct, while another set of parties (verifiers) must check its correctness before accepting it. This interactive process is repeated with every update to the database.
However, how to achieve open membership groups requires asking several important questions:
- Who is the proposer? How do I become a proposer? How big does this group need to be?
- Who is the validator? Do I need to register? How big does this group need to be?
- How do we agree on accepting an update ?
The architecture of this system and its fundamental implications for database security will answer the above questions. We explore L1 and L2 architectures with the ultimate goal of helping readers develop a good mindset.
L1’s database must be acceptable to the economic majority (the “world”)
In the L1 system, trusted third parties are replaced by public consensus .
Its purpose is to get all participants to agree to database updates. This requires a set of common rules ( “consensus rules” ) that can be objectively followed by all parties.
These rules are used to demonstrate the validity of database updates. One or more proposers may propose a competing update, but eventually all participants converge on an update to the database and a fact about the database contents.
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 gain financial incentives from the long-term success of the system. This is to prevent the proliferation of conflicting updates, ultimately 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 figure out the latest database copy.
We can take this opportunity to discuss how to limit who can be a proposer, how to weigh the broad copy of a database, and who is the final decider of a chain of authority (and database).
The number of proposers to limit the ratio. Our goal is to find “shared risk” 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 ownership of scarce resources (which are economically expensive to acquire).
For example, in a proof-of-work mechanism , proposers must have efficient hardware and cost-effective sources of electricity in order to compete in the mining market.
In the proof-of-stake mechanism , the proposer must own the tokens of the chain and lock them into the on-chain program. In both cases, the frequency with 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 periods of congestion, there is a trade-off between the throughput of the network and the affordability of transactions as users scramble to have their own transactions accepted before others.
In fact, networks like Bitcoin and Ethereum maximize the situations in which one can participate as a validator, while networks like Solana aim for low fees as long as it can be maintained. Interestingly, validators of ICPs 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. The ultimate goal, however, is to convince the economic majority, those who have a vested economic interest in using it.
These proposers and validators are just proxies for the economic majority under normal operating conditions, but in the event of a dispute over a modification to the network consensus rules, it is ultimately up to the majority of users around the world to decide from the external economic value of the resulting database to judge.
For example, the market caps of Bitcoin vs. Bitcoin Cash and Ethereum vs. Ethereum Classic clearly show who will be the winner if the community divides significantly along the way.
In summary, the L1 mindset is to think of L1 as the database, which is ultimately responsible for determining asset ownership and for an economic majority to accept all needs for database updates. This is why decentralization is critical to L1’s success from a technical, social and economic standpoint.
It aims to replicate the database as widely as possible, maximize the number of validators involved in the database protection process, and finally, rely on the economic majority to determine its real-world value.
The bridge contract holds all the assets and the L2 database records the liabilities
On L2 systems, trusted third parties are replaced by smart contracts, in which 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 bridging contract is to protect the bridging asset by checking the integrity of the off-chain database.
To maintain its integrity, the contract checks every proposed update to the off-chain database, checking its validity before accepting it (eg, every state change applied to the database on the L2 system).
This is critical to ensure that the assets held on the bridging contract can cover the liabilities recorded in the off-chain database, otherwise it will lead to a situation of large-scale withdrawal of funds.
Maintaining the independence of the bridging contract affects participation:
- Anyone can propose. 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. The release of assets will only be allowed 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 have evolved, and the purpose of making databases publicly accessible.
Architecture and centralized services. The architecture of L2 systems is similar to centralized services such as Coinbase. Users deposit tokens into bridge contracts on L1, deposits are reflected on the off-chain database, and most transactions are handled 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 system as an interoperability solution to move funds from one service to another. A sort of.
Historically, off-chain databases have been secured by operators (such as Coinbase) that determine whether a withdrawal is processed by a bridging contract.
The evolution of the trust assumption. Over the past few years, we have witnessed a change in the assumption of trust in the bridge contract, how it is assured of the integrity of the off-chain database. The trust assumption has evolved from a single agency bridge, multiple agency bridges, to a consensus protocol on an external blockchain.
In any case, the bridge contract must blindly trust the judgment of a set of parties before returning the asset to the user.
This has also resulted in billions of dollars being stolen because billions of dollars in manual processes that provide security are difficult to replicate across hundreds of bridges. The goal of an L2 system is to completely remove trust in intermediaries, allowing bridges to independently verify proposed updates to the database on data.
Database accessibility. Only bridge contracts can decide what is the real database and release assets to users. Making the database publicly accessible is to keep the L2 system alive.
The contract assumes that an honest party will appear, 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 databases, or rely on the economic majority to decide which database should have external real-world value.
So L2’s mindset is about bridging contracts and supporting contracts trying to protect their holdings. Regardless of what the majority of participants believe, the contract has the sole authority to decide which updates to the database are accepted.
At the same time, the participant network still wants to ensure the liveness of the L2 system and guarantee that updates will be proposed to the smart contract on an ongoing basis. However, this is not about relying on a global mesh network to protect the integrity (security property) of the database.
*optimistic rollup is a caveat, as it assumes that there will be an honest party assisting the bridging contract to verify updates to the off-chain database, but in the end, it is the final decision made by the bridging contract that really matters.
Comparison and Summary
The architecture and purpose of L1 and L2 systems are different:
- L1 system. The goal is to achieve a 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 where smart contracts trust the integrity (and state) of off-chain databases.
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 by the database.
However, on L2 systems, no majority consent or external asset valuation is required. It already assumes that the L1 system achieves public consensus and its sole focus is to protect the assets held by the smart contracts. Therefore, it can rely on the presence of an honest party to keep the system moving forward.
In my opinion, 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 final system architectures.
The only reason our community is trying to compare the two is that L2 systems came about because L1 scalability hit a bottleneck. One of my soft goals is to change this statement, as second-tier systems should be seen as an evolution of bridging contracts.
So, they should be contrasted with custodial services like Coinbase, which protects over 10% of all crypto assets, since both systems are responsible for securing off-chain databases and a basket of assets.
Finally, I hope this article helps readers develop a good mindset in terms of system architecture and trust assumptions for L1 and L2 systems. It is also hoped that L2 protocols will endure and demonstrate their superiority over managed solutions.
Not because users care about the security of the system, but because I believe carriers can provide the exact same service without risking billions of dollars in protection. In this way, escrow (and trust) becomes an unnecessary and obstructive responsibility.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/in-depth-analysis-of-the-differences-in-thinking-modes-between-l1-and-l2/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.