Note: This article is from @levi0214 Twitter, and MarsBit organizes it as follows:
The founder of Gnosis @koeppelmann shared at EthDenver yesterday, talking about the limitations of L2 and another way to expand.
I found it very interesting and I made some excerpts and notes:
https://twitter.com/koeppelmann/status/1631875843751542791
The original purpose of L2 is to complete a bunch of transactions in batches, and then synchronize the results back to L1. It is a very temporary space, rather than a new space to put some permanent assets.
In the long run, even if it is perfectly implemented, L2 will still have some fundamental problems.
For example, question 1: This kind of process has a problem, that is, it is only suitable for applications where the state will not expand, such as exchanges (only transaction results are required, no transaction history is required), but for applications with state expansion, it has no way of expansion.
Taking ENS as an example,
If 10% of the world's 8 billion people (800 million people) want to register with ENS, the entire transaction processing capacity of Ethereum will be used to process these requests, and it will take 2 years to complete. During these 2 years, Ethereum will not be able to process any other transactions.
Taking stocks as an example,
If all the stocks (45,000) in the world use Ethereum as the settlement layer, then each stock can only conduct less than 30 transactions per day (even if you use L2).
Problem 2: Transaction Costs
L2 peak gas sometimes exceeds $1. Even if EIP4844 is implemented, the gas can be reduced by 90%, but there are still two problems:
1. It is still not applicable to scenarios that require gas below 1 cent (sbu-cent),
2. After the demand increases, the gas will still increase.
Problem 3: L2 asset exit problem
1. The small amount of assets may not be enough to pay the exit Gas fee,
2. The exit bandwidth is limited, if everyone wants to go out, it will be blocked...
Question 4: Some apps cannot be rolled up.
For example, CirclesUBI, POAP, they create a lot of state, these states cannot be compressed, so L2 is useless for them.
So if you stay in L2 forever, don't leave, and use it as a permanent space, is that okay?
There are several problems with this.
Question 1, the sequencer of L2 is very centralized
Although they can't take your money, they have great power and can decide whether to accept your transaction, how much gas to charge for your transaction, who is ahead and who is behind...
I also hacked Coinbase by the way, saying that if you want to do an exchange on BASE, it can easily rank transactions from it ahead of yours...
Then, the centralized sequencer is very likely to be censored and even enforce KYC (only accept transactions from KYC addresses).
The author emphasizes that this is very possible from the perspective of current regulations.
Question 2, here the author raises a very interesting question:
If we want to issue an asset that is native to L2 and does not exist in L1, what is the point of having L2 in this case?
Because the reason why L2 is safe is because of L1, but you don't want L1 anymore, so why do you have to use L2.
Question 3: (The following question is very interesting!)
rigid problem
Ethereum L1 itself is still evolving, and there will be many modifications in the next 5-10 years, which will bring many challenges to L2!
Example: The Snapshot we use for voting is to vote in L2, and then synchronize the state back to L1, and they do Merkle Proof in L2.
However, Ethereum L1 plans to switch from Merkle Trees to Verkle Trees in the next year or two, which will cause the current version of Snapshot to no longer be used.
Therefore, L2 may need some kind of "upgrade" mechanism, but this would also contradict its trustless goal.
solution
The author proposes an interesting scheme, similar to Cosmos' IBC model.
That is to say: let's make another chain, run the same thing as Ethereum, and then connect through a trustless ZK-bridge to form an Ethereum universe (Ethereumverse)
In fact, when I first heard about the implementation of zk bridge, I thought it was very sci-fi. As a result, such a thing is really made now.
It is to use zk to run the light node client of another chain on one chain, and then verify in it...
There is no need for trust here, and it is far safer than traditional bridges.
That's about it for sharing.
In my personal opinion, this is a very interesting and underrated solution, and if you think about it, it can really solve a large part of the previous problems.
