Vitalik's Talk: Exploring the Ethereum 2025 Vision, Fusion Innovation of POS, L2, Cryptography, and AI

Original Title: "[DappLearning] Exclusive Interview with Vitalik Buterin"

Original Source: DappLearning

On April 7, 2025, at the Pop-X HK Research House event co-hosted by DappLearning, ETHDimsum, Panta Rhei, and UETH, Vitalik and Xiao Wei made a joint appearance at the event.

During the event, Yan, the founder of DappLearning community, interviewed Vitalik. The interview covered various topics such as ETH POS, Layer2, cryptography, and AI. This interview was conducted in Chinese, and Vitalik's Chinese proficiency was excellent.

Below is the interview content (slightly reorganized for better readability):

01 Views on the POS Upgrade

Yan: Vitalik, hello, I'm Yan from the DappLearning community. It's a great honor to interview you here. I've been following Ethereum since 2017. I remember the intense discussions about POW and POS in 2018 and 2019. This topic may continue to be discussed.

Looking at it now, Ethereum's POS has been running steadily for over four years, with millions of Validators in the consensus network. However, the ETH to BTC exchange rate has been declining, presenting both positive and challenging aspects. So, at this point in time, how do you view Ethereum's POS upgrade?

Vitalik: I think the prices of BTC and ETH have nothing to do with POW or POS at all. There are many different voices in the BTC and ETH communities, and what these two communities are doing is completely different, with entirely different ways of thinking.

Regarding the price of ETH, I think there is one question. ETH has many possible futures, and in these futures, there will be many successful applications on Ethereum. However, the value these successful applications may bring to ETH might not be enough.

This is a concern that many people in the community worry about, but in reality, it is a very normal issue. For example, take Google as a company. They have created many products and done many interesting things. However, over 90% of their revenue is still related to their Search business.

The relationship between applications in the Ethereum ecosystem and ETH (price) is similar. Some applications pay high transaction fees, consuming a lot of ETH, while there are many successful applications that do not contribute proportionally to the success of ETH.

So this is an issue that we need to think about and continue to optimize. We need to support more applications that bring long-term value to Ethereum holders and ETH. Therefore, I believe that the future success of ETH may lie in these areas. I don't think it has much to do with improving the consensus algorithm.

02 PBS Architecture and Centralization Concerns

Yan: Right, the prosperity of the ETH ecosystem is also a key reason why developers are willing to build on it. OK, how do you view the PBS (Proposer & Builder Separation) architecture of ETH 2.0? This is a good direction, where in the future, everyone can use a mobile phone as a light node to verify (ZK) proofs, stake 1 ETH to become a Validator.

But the Builder may become more centralized. They have to combat MEV and generate ZK Proofs, and if using a Rollup-based solution, the Builder may have to do even more tasks, such as acting as a Sequencer. In this case, would the Builder become too centralized? Although Validators are decentralized enough, this is a chain. If one link in the middle has a problem, it will also affect the entire system's operation. How do you plan to address the censorship resistance issue in this area?

Vitalik: Yes, I think this is a very important philosophical question. In the early days of Bitcoin and Ethereum, there was a subconscious assumption: constructing a block and validating a block are the same operation.

Assume you are building a block. If your block contains 100 transactions, then your node needs to process that many transactions' gas. After you have built the block and broadcasted it to the world, every node in the world also needs to do the same amount of work (consume the same amount of gas). So if we set a gas limit that aims for every laptop, MacBook, or a certain-sized server in the world to be able to build blocks, then correspondingly sized nodes need to validate these blocks.

This was the previous technology; now we have ZK, we have DAS, we have many new technologies, and we also have Statelessness (stateless validation).

Before using these technologies, building blocks and validating blocks needed to be symmetric, but now it can become asymmetric. So, the difficulty of building a block may become very high, but the difficulty of validating a block may become very low.

Using a stateless client as an example: After adopting stateless technology, if we increase the gas limit tenfold, the computing power required to build a block will become enormous, and an ordinary computer may no longer be capable. At this point, a high-performance MAC studio or a more powerful server may be required.

However, the cost of validation will become lower because validation requires no storage at all, relying only on bandwidth and CPU computational resources. If we further add ZK technology, the cost of CPU for validation can also be eliminated. If we also include that DAS, the cost of validation will become very, very low. While the cost of building a block may increase, the cost of validation will decrease.

So, is this situation better compared to the current one? This question is quite complex. I would think that if there are some super nodes in the Ethereum network, meaning some nodes with higher computing power, we need them to perform high-performance computing.

So, how do we prevent them from malicious behavior? For example, there are several types of attacks:

First: Performing a 51% attack.

Second: A censorship attack. If they do not accept certain users' transactions, how do we mitigate this risk?

Third: How can we counter MEV-related operations and reduce these risks?

Regarding the 51% attack, as the validation process is done by the Attester, these Attester nodes need to validate DAS, ZK Proof, and the stateless client. The cost of this validation will be very low, so the barrier to entry for becoming a consensus node will still be relatively low.

For example, if some Super Nodes are building blocks, in a scenario where 90% of these nodes are controlled by you, 5% by him, and 5% by others, if you completely reject certain transactions, it is not necessarily a very bad thing. Why? Because you cannot disrupt the entire consensus process.

So, you cannot perform a 51% attack. The only thing you can do is to censor some users' transactions. Users may only need to wait for ten or twenty blocks for someone else to include their transactions in a block. That is the first point.

The second point is about the concept of Fossil, so what does Fossil do?

Fossil separates the role of "transaction selection" from the role of executing transactions. By doing this, the role of selecting which transactions to include in the next block can be more decentralized. Therefore, through the Fossil method, smaller nodes will have the ability to independently choose which transactions to include in the next block. Additionally, if you are a larger node, your rights are actually quite limited.

This method is more complex than before. Previously, we thought of each node as a personal laptop. However, if you look at Bitcoin now, it is actually a more hybrid architecture. This is because Bitcoin miners are all part of mining data centers.

So in PoS, it is done roughly like this: some nodes require more computing power and more resources. However, these nodes' rights are restricted, while other nodes can be very decentralized, ensuring network security and decentralization. But this method is more complex, so it is also a challenge for us.

Yan: A very good idea. Centralization is not necessarily a bad thing, as long as we can limit malicious behavior.

Vitalik: Yes.

03 Issues Between Layer1 and Layer2, and Future Direction

Yan: Thank you for answering my long-standing questions. Let's move on to the second part of the discussion. As a witness to Ethereum's journey, Layer2 has been quite successful. The TPS issue has indeed been resolved. Unlike during the ICO craze, there is no longer unbearable congestion.

Personally, I think L2 is pretty user-friendly now. However, the current liquidity fragmentation issue for L2 has also prompted many proposals. How do you view the relationship between Layer1 and Layer2? Is the current Ethereum mainnet too laissez-faire, too decentralized, with no constraints on Layer2? Does Layer1 need to establish rules with Layer2 or create some profit-sharing models, or adopt solutions like Based Rollup? Justin Drake recently proposed this solution on Bankless, which I also agree with. What is your perspective, and I am also curious about when, if there are corresponding solutions, they will go live?

Vitalik: I think right now our Layer2 has a few issues.

The first one is that their progress in terms of security is not fast enough. So, I have been pushing for all Layer2s to upgrade to Stage 1 and hope that this year they can upgrade to Stage 2. I have been urging them to do so, while also supporting L2BEAT in doing more transparency work in this regard. The second one is the issue of L2 interoperability. That is, cross-chain transactions and communication between two L2s. If two L2s are within one ecosystem, interoperability needs to be simpler, faster, and lower cost than it is now.

We started this work last year, now called the Open Intents Framework, and there is that Chain-specific addresses, which is mostly UX work.

In fact, I think the cross-chain issue of L2 is probably 80% a UX issue. Although the process of solving UX issues may be painful, as long as the direction is right, complex problems can be made simple. This is also the direction we are working towards.

Some things need to go further, such as the Withdrawal time of Optimistic Rollup, which is one week. If you have a coin (Token) on Optimism or Arbitrum, you need to wait for one week to cross-chain that coin to L1 or to another L2.

You can make Market Makers wait a week (at a corresponding fee to them). For regular users, they can cross-chain from one L2 to another L2 through methods like Open Intents Framework Across Protocol for small transactions. But for larger transactions, Market Makers still have liquidity restrictions. So the transaction fee they require will be higher. I published an article [2] last week, which is in support of the 2 of 3 validation method, which is the OP + ZK + TEE method.

Because if you do that 2 of 3, it can satisfy three requirements simultaneously.

The first requirement is completely trustless, without needing a Security Council, TEE technology is in a secondary role, so you don't need to trust it completely either.

Second, we can start using ZK technology, but ZK technology is relatively early-stage, so we cannot fully rely on this technology yet.

Third, we can reduce the withdrawal time from one week to 1 hour.

You can imagine that if users use the Open Intents Framework, the liquidity cost for Market Makers will be reduced by 168 times. This is because Market Makers' wait time (for rebalancing) will be reduced from 1 week to 1 hour. In the long term, we plan to reduce the withdrawal time from 1 hour to 12 seconds (the current block time), and if we adopt SSF, it can be reduced to 4 seconds.

Currently, we will also adopt technologies like zk-SNARK Aggregation to parallelize the ZK proof process and reduce latency slightly. Of course, if users do this with ZK, they do not need to do it through Intents. But if they do it through Intents, the cost will be very low, all part of Interactability.

Regarding the role of L1, perhaps in the early stages of the L2 Roadmap, many people will think that we can completely replicate Bitcoin's Roadmap, where the usage of L1 will be very minimal, only for verification (doing a small amount of work), and L2 can do everything else.

However, we have found that if L1 does not play any role at all, this is dangerous for ETH. As we discussed before, one of our biggest concerns is that the success of Ethereum applications cannot become the success of ETH.

If ETH is not successful, it will cause our community to be without money, without a way to support the next round of applications. So if L1 doesn't play any role, the user experience and the entire architecture will be controlled by L2 and some applications. There will be no one representing ETH. So it would be better for ETH if we could allocate more roles to L1 in some applications.

Next, one question we need to answer is what will L1 do? What will L2 do?

In February, I wrote an article [3], in a world that is L2-centric, where many important things need L1 to do. For example, L2 needs to submit proofs to L1, if an L2 has a problem, users will need to cross-chain to another L2 through L1, in addition to Key Store Wallet, and Oracle Data can be placed on L1, and so on. Many mechanisms like this need to rely on L1.

There are some high-value applications that are better suited for L1, such as Defi. One key reason why some Defi applications are better suited for L1 is their Time Horizon, where users need to wait for a long time, such as one year, two years, or three years.

This is particularly evident in the prediction markets, where sometimes questions are asked about what will happen in 2028.

Here lies a problem: if there is an issue with L2 governance, theoretically, all users there can Exit, they can move to L1, or they can move to another L2. But if there is an application in this L2, and its assets are all locked in a long-term smart contract, then users have no way to exit. Therefore, many of those theoretically secure Defi applications are not actually very secure.

For these reasons, some applications should still be built on L1, so we are once again focusing more on L1 scalability. We now have a roadmap, and by 2026, there are about four to five methods to enhance L1 scalability.

The first is Delayed Execution, where block validation and execution are separated, meaning we only validate blocks in each slot and execute them in the next slot. This has the advantage that the maximum acceptable execution time could increase from 200 milliseconds to 3 seconds or 6 seconds. This provides more processing time.

The second is Block Level Access List, where each block needs to specify in its information which accounts' states need to be read and their related storage states. This is somewhat like stateless witnesses and allows for parallel processing of EVM execution and I/O, providing a simple way to implement parallel processing.

The third is Multidimensional Gas Pricing, which sets a maximum block capacity, crucial for security. Another aspect is (EIP4444) historical data processing, where not every node needs to permanently store all information. For example, each node could store only 1%, and we can employ a peer-to-peer method to distribute that information more evenly.

So if we can combine these four schemes together, we now think we can possibly increase L1's Gaslimit by 10 times, and all our applications will have the opportunity to start relying more on L1, doing more things on L1, which is beneficial for L1 and also for ETH.

Yan: Okay, next question, are we likely to see the Pectra upgrade this month?

Vitalik: Actually, we hope to do two things, to have the Pectra upgrade at the end of this month, and then to have the Fusaka upgrade in Q3 or Q4.

Yan: Wow, so soon?

Vitalik: Hopefully.

Yan:

My next question is also related to this. As someone who has been watching Ethereum grow all the way, we know that Ethereum, in order to ensure security, usually has about five or six clients (consensus and execution clients) under development simultaneously, with a lot of coordination work in between, resulting in a relatively long development cycle.

There are pros and cons to this. It may indeed be slower compared to other L1 solutions, but it is also more secure. However, are there any solutions that would allow us to not have to wait a year and a half for an upgrade? I've seen you mention some solutions, could you elaborate on them?

Vitalik:

Yes, there is one solution where we can improve coordination efficiency. We now also have more people who can move between different teams, ensuring more efficient communication between teams. If a client team encounters an issue, they can raise it so that the research team is aware. One advantage of Thomas becoming one of our new EIP editors is this—he is with the client (team), and now he is also with the EF (team). He can handle this coordination, which is the first point.

The second point is that we can be a bit stricter with the client teams. Our current approach is, for example, if there are five teams, then we need all five teams to be fully ready before we announce the next hard fork. We are now considering starting the upgrade as soon as four teams are ready, so we don't have to wait for the slowest one, and we can also boost everyone's motivation.

04 How to View Cryptography and AI

Yan: So appropriate competition is necessary. It's great, really looking forward to each upgrade, but don't make everyone wait too long. Next, I want to ask another question related to cryptography, a more broad question.

Back in 2021 when our community was just established, developers from major domestic exchanges and researchers from Ventures gathered to discuss Defi. In 2021, everyone indeed participated in understanding Defi, learning, and designing Defi. It was a stage of nationwide participation and enthusiasm.

Looking ahead, for ZK, whether for the general public or developers, learning ZK, such as Groth16, Plonk, Halo2, etc., the further developers go, they find it challenging to catch up, especially considering how rapidly the technology is advancing.

Furthermore, now we see a trend where ZKVM is developing rapidly, leading to ZKEVM's direction not being as popular as before. Once ZKVM matures, developers may not need to focus too much on the underlying ZK. What are your suggestions and views on this?

Vitalik:

I think the best direction for some of the ZK ecosystems is that most ZK developers know some high-level language (HLL). They can write their application code in HLL, and the Proof System researchers can continue to enhance and optimize the underlying algorithms. Developers need a layered approach; they don't need to know what's happening in the next layer.

One potential issue now is that Circom and Groth16's ecosystem is highly developed, but this poses a significant limitation to the ZK ecosystem application. Groth16 has many disadvantages, such as each application needing to handle its Trusted Setup, and its efficiency is not very high. Therefore, we are also considering allocating more resources here and helping more modern HLLs succeed.

Another aspect is the ZK RISC-V route, which is also promising. Because RISC-V can be considered an HLL, many applications, including EVM and some others, can be written on top of RISC-V.

Yan: Okay, so this way, developers only need to learn Rust, which is great. I attended Devcon in Bangkok last year and also heard about the development of applied cryptography, which was very enlightening to me. Regarding applied cryptography, what is your view on the direction of combining ZKP with MPC and FHE, and what advice would you give to developers in this regard?

Vitalik:

Yes, this is very interesting. I think the future of FHE looks very promising, but there is a concern that both MPC and FHE always require a Committee, meaning you need to select, for example, seven or more nodes. If those nodes could potentially be attacked by 51% or 33%, your system will encounter issues. It's like the system has a Security Council, which is actually more severe than a Security Council. Because if an L2 is Stage 1, the Security Council needs 75% of the nodes to be attacked for issues to arise [7], which is the first point.

The second point is that if the Security Council is reliable, the majority of them will keep their funds in cold storage, meaning they will be mostly offline. However, in most MPC and FHE scenarios, their Committee needs to be online to keep the system running. Therefore, they might be deployed on a VPS or other servers, making it easier to attack them. This worries me a bit. I think many applications can still be developed, which have advantages but are not perfect.

Yan: Lastly, I want to ask a relatively light-hearted question. I see you have also been focusing on AI recently. I want to list a few viewpoints, such as Elon Musk's statement that humans may only be a boot loader for silicon-based civilization.

Then there is a viewpoint in "The Network Nation" that authoritarian states may prefer AI, while democratic states may prefer blockchain. From our experience in the crypto world, decentralized systems rely on everyone following the rules, mutual checks and balances, and understanding the risks, which ultimately leads to oligarchical politics. So, what is your take on these viewpoints? Just discussing the viewpoints is sufficient.

Vitalik: Yes, I'm considering where to start in answering.

Because the field of AI is very complex, for example, five years ago, no one might have predicted that the U.S. would have the world's best Closed-Source AI while China would have the best Open-Source AI. AI has the potential to enhance everyone's abilities, and sometimes it may empower certain centralized entities.

However, AI can sometimes have a somewhat democratizing effect. When I use AI myself, I find that in those areas where I am already in the global top one thousand, such as some ZK development areas, AI actually helps me less in the ZK part, and I still need to write most of the code myself. But in those areas where I am more of a newbie, AI can help me a lot, for example, in Android app development, which I have never done before. I did an app ten years ago, using a framework, written in JavaScript, and then converted to an app. Besides that, I have never written a native Android app before.

At the beginning of this year, I did an experiment, which was to try to write an app using GPT, and I completed it within an hour. The gap between an expert and a newbie has been greatly reduced with the help of AI, and AI can also bring many new opportunities.

Yan: Just to add, I really appreciate the new perspective you've given me. I used to think that with AI, experienced programmers might learn faster, while it might not be friendly to newbies. But in some ways, it does improve the abilities of beginners as well. It might be a kind of equalization instead of differentiation, right?

Vitalik: Yes, but now a very important issue that needs to be considered is the effect of some of the technologies we are working on, including blockchain, AI, cryptography, and some other technologies, when they are combined (on society).

Yan: So, you still hope that humanity won't just be ruled by elites, right? You also hope to achieve the Pareto optimality of the whole society. Ordinary people empowered by AI and blockchain become super individuals.

Vitalik: Yes, super individuals, super communities, superhumans.

05 Expectations for the Ethereum Ecosystem and Advice for Developers

Yan: Okay, moving on to our final question, what are your expectations and messages for the developer community? Is there anything you would like to say to the Ethereum developer community?

Vitalik: To those developers of Ethereum applications, you should think about it. There are many opportunities to develop applications on Ethereum now, many things that could not be done before can now be done.

Here are many reasons, such as:

First: previously, the TPS of L1 was completely insufficient, but now this issue has been resolved;

Second: previously, there was no way to address the privacy issue, but now there is;

Third: it's because of that AI, the difficulty of developing anything has been reduced, so even though the complexity of the Ethereum ecosystem may have increased, through AI, everyone can better understand Ethereum.

So I think there are many things that failed in the past, including ten years ago or five years ago, that may now succeed.

In the current application ecology of blockchain, I think the biggest issue is that we have two types of applications. The first type can be said to be very open, decentralized, secure, and particularly idealistic (applications). But they only have 42 users. The second type can be said to be a casino. The problem is that these two extremes, both of them are unhealthy.

So what we hope to do is to create some applications that users will like to use, that will have real value. Applications that will make the world a better place. Second, there are really some business models, such as economically viable ones, that can sustainably operate without relying on limited foundation or other organizational funding, which is also a challenge.

But now I think everyone has more resources than before, so now if you can find a good idea, if you can execute it well, then your chances of success are very high.

Yan: Looking back on the journey, I think Ethereum has actually been quite successful, always leading the industry and striving to solve industry problems under the premise of decentralization.

One other point with deep feelings, our community has always been nonprofit. Through grants from Gitcoin in the Ethereum ecosystem, as well as retroactive rewards from OP, and other project teams' airdrop rewards, we find that in the Ethereum community, Building can receive a lot of support, and we are also thinking about how to make the community continue to operate stably.

The construction of Ethereum is really exciting, and we also hope to see the realization of the world computer soon. Thank you for your valuable time.

Interview conducted at Victoria Peak, Hong Kong

April 7, 2025

Finally, attached is a photo with Vitalik

In-article References Mentioned by Vitalik are summarized by the editor as follows:

[1]：https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870

[2]：https://ethereum-magicians.org/t/a-simple-l2-security-and-finalization-roadmap/23309

[3]：https://vitalik.eth.limo/general/2025/02/14/l1scaling.html

[4]：https://ethresear.ch/t/delayed-execution-and-skipped-transactions/21677

[5]：https://vitalik.eth.limo/general/2024/05/09/multidim.html

[6]:https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617

[7]:https://specs.optimism.io/protocol/stage-1.html?highlight=75#stage-1-rollup

This article is contributed content and does not represent the views of BlockBeats.