Vatilik: Why accelerate L2 confirmation speed? How to accelerate it?

Sorting: Wuzhu, Jinse Caijing

On April 8, 2025, Ethereum founder Vitalik delivered a keynote speech at the Web3 Scholars Summit 2025. Jinse Finance has summarized the content of the speech as follows.

Currently, exiting Optimism or Arbitrum requires a 1-week exit period, which can cause a lot of issues.

Why should we care about this? Why should we care about faster connections between L2 and L1? I think there are two reasons for me. One is user experience, we want users to have a better experience; waiting a week is a terrible experience. The other reason is we need a more integrated ecosystem. We need to do some things to truly improve Optimism, Arbitrum, and Polygon.

These parts of the Ethereum world are not independent.

Currently, interoperability between L1 and L2 is very fast, but it requires a lot of Gas. We started to really care about this issue since last summer. The two things we are focusing on include: specific addresses on the blockchain and intended projects. I hope that transferring Optimism to Arbitrum does not take a week, and I even hope that it can be put into a smart contract.

In a smart contract, if anyone provides proof first that they have sent currency to my designated destination address through the contract, it will automatically jump to this step. Therefore, we hope to find a suitable way to reduce the one-week waiting time as much as possible.

Why do we now have a one-week withdrawal window? Because Optimism's Rollup needs to wait a week to see if anyone questions its hash; if no one questions it, you can accept the hash. The advantage of Optimism lies in the caution of the technology it relies on, but the cost is a one-week waiting period.

If we do not want to wait for 1 week, then we need to establish a system that can package blocks using a completely non-Optimism proof system, such as the combination of ZK+TEE+OP — this is the design proposal we put forward.

! DgiWcMrcMkwxgOfjSfT9BcXQXFNajasojnfkTkPt.jpeg

Under normal circumstances, once an L2 transaction occurs, the state will be finalized on L1 within one hour, reducing 1 hour to 12 seconds, which is basically just an efficiency issue. So that is the first goal. The second goal is that we want L2 to be trustless. We want to prove that the system can determine the correct state and record incorrect states, even if the trusted components are compromised. So today, Rollups are either in zero phase or in the first phase, which means they place a certain degree of trust or complete trust in some kind of security committee. You have to trust that the manufacturer can design them correctly. You have to trust that the manufacturer will not keep a copy of the site key itself.

Moreover, you must believe that the hardware mechanism is not something that any holder of the hardware can destroy, and you must believe that they cannot find a way, such as using lasers or infrared scanning hardware, to extract information without damaging the visual.

Now, we don't want to place all our trust in ZK.

You will allocate trust among three different mechanisms that operate based on very different types of logic. If we have this design, then you can shorten the finalization period from 1 week to 1 hour. By the way, another way is my previous view on group systems, I basically categorize them into two types. One is institutional trust, and the other is crypto trust.

Another dimension is fast versus slow. Fast things can be approved immediately, while slow things take some time to wait. Interestingly, just like the four items here, they are essentially the 4 types of proof system components that people use or think about in the context of L2, right? If we could really put them in a box, they would fit perfectly in 2×2.

First step, basically, we shortened the window period for the devil's walk from 1 week to 1 hour. What does this mean for you? It basically means that if you use the native bridging to directly transfer assets, your waiting time will be reduced from 1 week to 1 hour. If you use intent-based bridging, then intent-based bridging is instantaneous, but liquidity providers do not have to wait 1 hour, but rather must wait 1 hour. The cost of providing liquidity has decreased by 168 times. Therefore, the fees you will have to pay will decrease by up to 168 times.

L2s can use lowlookahead for asynchronous reading of L1. This is a feature that L2s already have, as they must be able to handle deposits. We adopt the same state as reading deposits and expose it to the L1SLOAD opcode. Supporting the reading of L1 oracle data, vault wallets, and many other applications is very valuable, as one of the challenges that L2s often face is that they need to pay large amounts of funds.

! 4ZTnBOtkTIBfxYOBykB3r2sM9Y8960iNQpjEVHVb.jpeg

Therefore, I have obtained various custom applications and specific integrations. This can indeed reduce costs, as in many cases, alternatives will be able to directly read copies of applications that already exist on one application, which is applicable to data processing. It applies to certain things but not to things that require writing to anyone.

A key storage wallet is another interesting idea, isn't it? The idea of a key storage wallet is basically that in normal cybersecurity, when you want to change a key, you don't want the key to have an infinite lifespan. Neo is part of the account abstraction goal, which I will discuss today.

But I have mentioned many times that it is essentially about creating accounts with arbitrary logic, so that you can do things like change the encryption algorithm, change the keys, make them very resistant, and make them use snarks added like recovery methods. Now, one of the challenges is that if you can change the keys, then you have a hundred results after changes. Therefore, you must change the record of the current key in 100 places.

How do you solve this problem? We solve this problem by placing a record of the current key on a central contract. Then you have a copy of the wallet appearing on each L2, which can simply read from L1. This makes many very reasonable and very similar securitization safety practices more feasible and practical in the world of L2.

Another benefit is that it makes workflows that include both L2 and L1 easier and more natural for developers. We are not just talking about theory and a bunch of completely independent chains; we are actually talking about L1 theory continuing to be at the core of applications and people's user experience.

The third step is proof aggregation. As I mentioned earlier, if we adopt this method based on two or three approaches, or in the future, if we achieve very good formal verification, and we rely solely on ZK, we can shorten the submission time from 1 week to 1 hour. Why 1 hour? Why not 12 seconds? There are two reasons, and we can address both of them. The first reason is the submission cost. Therefore, submitting proof to L1 incurs additional overhead, approximately 500,000 gas, and the cost of AA is very high.

Now, if you imagine submitting a proof for every time period, that would mean 2.5 million time periods in a year. We would spend 27.5 million dollars each year just to maintain a relative value, which is insane. Who here is willing to pay 27 million dollars every year? But if you submit once every minute instead of every 12 seconds, then the annual cost of 27 million dollars becomes 5.5 million dollars. Then, if you submit once an hour, it drops to under 100,000 dollars a year. This is actually manageable. The natural solution here is proof aggregation.

If we have a large number of different tools, then those tools don't have to be submitted to different groups individually, chain proofs can be grouped, groups can submit their proofs to the aggregate, and then the aggregate can submit a separate SNARK to prove the existence of other SNARKs. The cost of verifying the SNARK is only a one-time 500,000 gas cost. What's happening here is basically what's on this diagram? Right? Basically, you have a bunch of proofs, and those proofs also specify which contract. We are in a block. Then you have an aggregate proof. Aggregate proofs are verified. The aggregate attestation contains all the information of a single aggregate as a common input, and then the attestation occurs only once. This contract will then only make one call per rollup, and the only thing the call does is for each rollup. It's just loaded separately. The cost per visit dropped from 500,000 gas to less than 10,000 gas.

The fourth step is to reduce proof delay. Proof computation takes longer and requires more computational power than performing the computation itself. By default, this computation does not paralyze. You have to scale it, and you have to perform this very intensive computation.

Therefore, the result is that in a balanced state, generating a block that takes 5 seconds still requires 500 seconds to prove, right? This is a problem. So the question is, how do we solve this problem? There are two ideas. One is that we can use dedicated hardware to improve it. Some companies are already doing this. If you achieve a 100 times hardware acceleration factor, then you can prove in real-time. The other idea is super provably difficult proofs. So from a mathematical perspective, this is actually quite simple. Basically, you will break down the computation into multiple steps. Then you prove each step in parallel on different devices.

If this is not enough, then the improvement speed of specialized hardware will be faster. At the same time, the improvement costs will be lower. So we have many options.

If you use Intensive Optimism and Arbitrum, both of which have much faster time slots, you can complete transactions in just 2 seconds. So it will be very cheap. Therefore, if you use Intensive, you will be able to transfer virtually unlimited amounts of Ethereum quickly and at low cost. This also means that we can establish closer links between L1 and L2. We have a more integrated world, making everything easier and faster for everyone. Thank you.