Vitalik Keynote | ETHTaipei 2025

Transcript

[Music] Okay. Yeah, thank you. Um, this is for the Oh, I see for the sliders. Okay. Yeah. Well, thank you so much for the kind introduction. Um, so the thing that I wanted to talk about is uh simple road map for layer 2 scaling and security, right? So, uh scaling you know a really big topic on all of our minds. So we I think uh in the last couple of years we've been going through this really important transition from Ethereum just being this kind of very theor mostly theoretical thing that relatively few people are using but lots of people are making a lot of really cool experiments on to Ethereum being something that

supports like very big mainstream applications that are being used by millions of people right and I think it's always important to remember that Like really Ethereum is being quietly used by a pretty huge number of people today. There's a huge number of people who use it for international remittances. There's a huge number of people that just use it for payments and savings. There's huge numbers of people participating in DeFi. A lot of people using things uh like prediction markets. Uh a lot of people using things like Farcaster. Um also uh Worldcoin got to 10 million users. So a lot of things are actually yeah getting pretty significant in terms of

scale and there's a lot of projects in the pipeline that wants to get to a much bigger level of scale right like there are projects that are willing to get to a much much higher level of users as long as there is space for that and so to make sure that there is space for everyone who wants to be on Ethereum to actually be able to be on Ethereum Ethereum needs to scale and While Ethereum scales, one thing that is really important is we do not want to compromise the fundamental properties that make Ethereum be Ethereum, right?

We do not want to compromise on permissionlessness. We do not want to compromise on Ethereum being a global neutral trustless open platform. We do not want to compromise on censorship resistance and we do not want to compromise on security. Right? We do not want to accidentally move back from being an ecosystem where people actually can have guarantees that the assets that they're using actually belong to them into an ecosystem where like everyone is trusting very small multisigs, right?

And so scaling and security are really important things that we really needs to keep in mind and solve for at the same time. Now scaling has a layer one side to it and it also has a layer two side to it and both the layer one side and the layer two side are important right and u about a month ago I wrote this article where basically I talked about how there's actually value in increasing the L1 gas limit by something like 5 to 10x even if you believe that basically all applications are going to be on layer 2 right so the value of of the Ethereum layer 1 at the very least as this kind of central coordinating point as a point

through which cross layer 2 interoperability happens as a point through which Ethereum users go when they're moving between layer 2s um all of these use cases it still requires L1 to scale right so L1 scaling is important but L2 scaling is also important and L2 scaling I think uh actually can happen quite quickly right So this is the the really nice thing that I think is uh really important to keep in mind, right? Which is that uh like it's taken us a very long time to get to where we are today, but we've actually built a huge amount of technology in the last 5 years. We have

tools today that we did not imagine that we would have at all 5 years ago. Right? And a lot of the existing layer 2, optimism arbitum zkync incarketnet, all all of these, a lot of them they're actually using these technologies under the hood. But if you really start to combine the technologies together, you realize that like actually we are in a position where we can scale quite quickly and we can do so in a way that actually does quite a good job of preserving security.

So step one scaling the blobs right. So last year is in Ethereum we uh had the uh EIP4844 upgrade which introduced this concept of blobs. So it introduced this concept of having this separate data space where layer 2s could have their own transactions and this greatly increased the scalability of layer 2. It decreased the cost of layer twos by a factor of about 50 and uh like it basically really kickstarted the layer 2 ecosystem as it exists today. Right? But blobs as they existed uh as last year like that and as they exist right now, they're only the first step in the the

lawyer 2 scaling journey. Right? So the hard fork that is currently tentatively scheduled for the end of April is going to increase the target number of blobs from 3 to 6 and increase the maximum from 6 to 9. So what does increasing the target from 3 to 6 mean? It means that the data space in Ethereum blocks that layer 2 can use to put their transaction data goes up from 375 kilobyt to about 750 kilobyt. Now, how much does 375 kilobyt give you? Right? 375 kilobyt if you divide by say about 150 bytes per transaction then you basically

get uh like about 2500 transactions in a block. Divide by 12 and like you have a little bit more than 200 transactions per second. Right now in Peterra going up from 3 to six and so we go up from about 200 transactions per second on layer 2 to about 400 transactions per second on layer twos. And then at the same time there's a lot of things that layer twos can do to improve their efficiency but really the biggest gains happen after right and so in foraka the plan is to introduce this upgrade called pieras right and pardas basically yeah means instead of requiring every node in the ethereum network to fully store all

of the blob contents like we actually start sharting the data right we actually start splitting it up and we start only requiring each node to store a small portion of all of the blob data. And by doing that, we can greatly increase total scalability. So the hope is to get to 48 blobs. There's actually a couple of different proposals. One of them is to get to 48 at the end of this year. Another is to get to 12 or 24 in Q3 and then increase very quickly after that. So there's a couple of different proposals, but in all of the cases, the goal is to pretty quickly increase the blob count. And then if you do that then the number of DPS that you can do on layer 2 securely goes up over a thousand. Now if we take

the podas model as it exists and we crank up the parameters as far as it seems reasonable, we could actually get to 128 blobs. So we could actually get to the original final target for the number of blobs just by using pas. And then if we get to 128 blobs, then we can get to like something like 10,000 transactions a second. And then if layer two is do more data quick compression, we can get to 50,000. But then now the goal actually is to go even higher, right? So the current goal is to get to 512 blobs and then potentially go even higher. So layer 2 scaling actually pretty simple, right? More blobs, more blobs, and even more blobs. So this is the scale part, right?

I think one other thing that's really important to talk about is the security part of layer 2, right? So, this is probably one of the things that's been the most challenging with uh the whole layer 2 concept as uh we've actually seen it play out over the last couple of years, which is basically that in theory, it's possible to make layer 2 that are completely trustless, right? It's possible to make layer 2 that are fully backed by the security of the underlying Ethereum chain. Now the problem is that a layer 2 and especially a layer 2 that's verifying the EVM is a pretty huge amount of code and with a huge

amount of code there's a risk that you have bugs in that code right and um something as big as an EVM prover inside of a layer 2 verification contract that's something where verifying that it's secure like it actually takes a lot of effort right and so for this reason like layer 2 so far have been pretty scared of giving up their multisigs and their security councils and so right now we have three EVM layer 2s that have gotten to what we call stage one um which is like basically a limited reliance on a security council and uh you know those are optimism arbitum and INC and I think we can actually be more ambitious and we can actually aim to get to stage two right and the definition of

stage two is basically a layer two that is actually trustless in the sense that the security of the layer 2 would only depend on the code being correct be the code being correct right it would it would depend only on mathematically provable components now you're allowed to have some components that are not mathematically provable but those components uh have to have a li only only a limited amount of power so that as if the provable component components are all working correctly, they can override the other components. Right? So basically, if you imagine a layer 2 with multiple proof systems, then fully

trustless proof systems have to take take up more than 50% share. Right? So this is where we want to go, right? We want to get to layer twos that are actually trustless, that are actually provable, that are actually running based on all of these principles that we want layer 2 to run on. Now the challenge today is from a usability perspective optimistic roll-ups are still quite a bit ahead of the ZK roll-ups right and with ZK roll-ups there's two major challenges one of them is cost but the cost is very quickly decreasing the other challenge is that ZK is still a relatively immature technology it's still especially at this level of complexity has quite a high

risk that there are some amount of bugs and so we don't want to fully rely on ZK. But then there's also another problem. The other problem is that with an optimistic rollup, you have to wait one week to withdraw, right? If you have an asset inside of an optimistic rollup and you want to withdraw it to layer 1, you have to wait one whole week. Now, the way that this works in practice for regular users, right, is that regular users are not going to be actually withdrawing directly, right? regular users are going to be withdrawing through intents through market makers through across protocol ERC 7683 like all of these second layer things right and then it's market makers that will be actually doing this like round tripping between layer 1 and layer 2 but the

problem is that if these market makers have to wait one week every time they withdraw then this is very capital inefficient for them right and if it's capital inefficient for them then the fees that they're going to charge to regular users trying to move coins between different layer 2s are going to be high, right? And so what we really want is we want layer 2 to go down to having let's say maximum 1 hour withdrawal time. And I think in the long run we can actually get to layer 2 having a 12second uh deposit and withdrawal time and we'll talk a bit about that. Um but let's get down to 1 hour first, right? So 1 hour basically means no need to like none of these sort of challenge response systems, right?

Like optimistic does not work. Um basically you need something where instead of waiting to make sure that nobody says that a particular state route is incorrect, you have proof systems that just tell you that the state route is actually correct. Right? So we have to balance these two different concerns. Right? Basically, on the one hand, we don't want to rely too much on immature technology yet. On the other hand, we also want to be able to withdraw from layer 2 as quickly. And so, the design that I think actually does quite a good job of balancing all of these constraints at the same time is this thing that I proposed a couple of days ago, which is a two of three

between optimistic ZK and trusted hardware. Right? So optimistic we all know um it's the technology that optimism and arbitrum are using and optimistic rollups they well an optimistic proof system you have to wait 7 days for it to give you an answer zk we know and then trusted execution environments basically you know there's uh things like SGX there's TDX there's a whole bunch of these right basically they require having trust in a hardware manufacturer and also they rely on this security assumption that like a particular piece of hardware has not been broken and breaking into hardware is generally much much easier than breaking a cryptographic algorithm,

right? And so it's a very different kind of security assumption than cryptographic assumptions, but it's one that we can of add into the mix, right? And so the goal of this kind of design is basically that we're not leaning on any side too much, right? Basically uh trusted execution environments they can give attestations of correctness immediately right and so because two out of three proof systems they can give you a correct an answer immediately in the normal case you have instant finality right in the normal case a layer 2 submits a block and then immediately you get a zk proof of it and you also get a TE proof of it now in order for layer 2 is to be stage two in order for layer 2

is to be trustless you don't want like things like tees and security councils to actually control the thing, right? If you have a layer two that's like actually controlled by things like TEES, then like it's not a layer two of Ethereum, it's a layer 2 of Intel, right? And so we want Bas but what this architecture does is it limits TAE to 1/3. And so if the code is working correctly, it doesn't matter if the TE breaks completely, your funds are still safe, right? And then also at the same time it still keeps two out of three in the hands of relatively mature technology. And it's basically making a bet that ZK and TE as they're like the risk profiles that they have are

sufficiently separate that we're not going to get a ZK breaking and a TE breaking at the same time. Right? And so or at least being broken by the same attacker, right? The argument is that the the things that cause them to be vulnerable are very different from each other. The people that are good at finding those vulnerabilities are very different. And so it's like basically as uncorrelated as you can get, right? And so like my argument is that if you have this kind of architecture, then it basically actually achieves all of the security properties that we want to the best level that we can today. And at the same time, it will let us be be able to natively withdraw from layer 2s within an hour. And I actually think it should

be possible to get EVM layer um layer 2 up to something like this within 2025. So that's part two. Now part three, right? Let's talk about fast finalization. So ultimately, I think you should be able to deposit and withdraw from a layer 2 within 12 seconds, right? Layer 2s should be moving closer and closer to just being like Ethereum shards. What is a property that you would expect from an Ethereum shard? You would expect to be able to move things between different Ethereum shards very quickly, right? And so you should be able to expect to move assets between one layer 2 and another layer two very quickly. And you should

be able to expect to do that natively, right? Why natively? Because well, if you can do native movement from one layer 2 to another layer 2 within 12 seconds, then you can do things that you cannot do with intentbased protocols. Right? With intentbased protocols, you can move ETH from optimism to arbitum. You can move USC from optimism to arbitum, but you can't move an NFT from optimism to arbitrum. Why? because well you can't have like a market maker have a second copy of an NFT on every layer 2 so that they can front the liquidity. It's impossible because there's only one copy of that layer 2, right? Or or of that NFT. And so can we have cross layer 2 native movements happen within 12

seconds? Can we have everything within the Ethereum world be doable natively within 12 seconds? I think the answer is yes. And I think there is basically two things that need to happen for that. One is that proof systems need to become faster. But I actually do not worry too much about this because I think there's a lot of incentive for that to happen already. And actually layer 1 already needs the same thing. Um but the other piece is basically layer 2 submitting to layer 1 needs to be much cheaper. Right? Today layer 2 submitting to layer 1 it has a gas cost of like over 500,000. And so and the reason is that basically every time you submit a proof verifying the proof is very expensive. And so the thing that I

think we need to do is we need to create aggregation protocols right we need to create protocols where you have many different layer 2s each layer 2 submits a proof and actually you don't just you need to keep this limited to layer 2. You can combine everything, right? Layer 2s, privacy protocols, um, account recovery wallet wallet zk email anything that uses a proof, you can basically have users submit. And then you have one aggregation protocol that takes say 100 different proofs and it replaces them with one single proof of all the proofs. And so we have a hundred different protocols where instead of all of them needing to submit 100 separate proofs for 500,000 gas each, they can

make much smaller transactions and you only need one aggregate proof to verify that all of them are correct. This is infrastructure that can be built. And if it can be built, then the submission cost for layer 2, submitting a state route to a layer 1 can go down to probably below 10,000 gas. And then if you do that then it actually becomes economically viable for every layer 2 to commit to layer 1 and to have finality in every slot. Right? And so this I think is how we can solve that part of the interoperability piece. So I think there's also other interoperability pieces that matter right so L1 S load is really important. L1S load basically means that layer 2 will be able to read

layer 1. And uh this basically means that you could use layer 1 as this central store of information. So we can have like key store wallet data on layer 1. You can have oracle data on layer 1. You can have a lot of different things on layer 1. And then layer 2 has become able to just read that data for free without having to pay gas for it. Um you then we talked about um ERC 7683. So users being able to transact with intents and a lot of this is also just work on the wallet and user experience side right. So I think like a lot of the time when people talk about problems with uh Ethereum layer 2 like a lot of the time the problem isn't even like the

base level technology right the problem is basically that there's a lot of these inefficiencies in how wallets are designed and so if you have if you currently are on arbitum and you want to move to optimism you have to click a bunch of buttons you have to figure out how to use a bridging protocol it's very annoying right And so what we need is we need for all of that stuff to appear much more native. We need bridging and sending to just look like the same operation to the user. And these are all things that chain specific addresses intent 7683 all of this kind of work actually does. Right?

So these are kind of the uh technological directions that I think we need to go in the next probably roughly one to two years uh to try to make layer uh push layer 2 really to the limit of their potential. Right? And I actually feel pretty confident that if we work hard we can get all of these things done within 2 years. Right? I think if we want to be realistic then if we look at scaling the blobs we can probably get the first half of this done in one year and then the second half of this done in one year. If we look at this two of three like I actually feel quite confident that we could get this done in one year. The thing that will take longer I think is doing formal verification pushing ZK proofs to a much

higher level of security and then eventually in like maybe 3 or 4 years we can actually get rid of the optimistic get rid of the TE and we can actually have extremely secure zero knowledge proofs of protecting all of our layer twos and protecting our layer one as well. Right? But this is something that will just take some more time. And then fast finalization like this I think realistically probably will take two years, right? I think realistically this just has much more dependency on zero knowledge proofs being relatively safe. And I think if we focus on this then this will already be able to get the layer 1 to layer 2 native bridging time down to 1 hour. And then I

think this is like a natural stage two of the road map right basically bring the bring that bridging time down from 1 hour all the way down to 12 seconds. So if we have all these things right then basically we get to this future where any kind of layer 2 like basically functionally actually does you know feel like an Ethereum shard you actually get the the kind of hyperscalable Ethereum experience that we're actually talking about and at the same time we're also in a very good position to use a lot of these exact same technologies to start scaling the layer one as well, right?

And so if we have these things, then I think we can really start to get layer 2 up to a much higher level of security and at the same time a much higher level of scalability and we can actually say we have an Ethereum ecosystem that actually is ready to serve applications and build things that actually go and benefit like 10 million, 100 million, potentially one bill 1 billion users. and we can feel confident that we're not making any compromises on security, censorship resistance, or permissionlessness while we do that. So, thank you.

[Applause] All right. Uh, thank you, sir. There are some slid questions that you may want to check check out. So, this one. Okay. Um, we have cheap block space now. How do we get the devs uh to come back and build actual apps? Yeah, I mean I think okay, so here's the thing, right? I think uh this idea that we have cheap block space for devs to feel confident building serious applications and like especially if you think about like enterprises building institutional applications, you can't just tell them we have cheap block space now. They need to feel confident that there will be

cheap block space now and two years from now and if their application goes 100x in number of users, right? Like and if you think about the like Ethereum L1 right now, today it's cheap. 3 years ago it was expensive. Like as an app developer, how do you know that Ethereum L1 is not going to become expensive again in one year from now, right? Or even if you build an app today based on the assumption that a transaction on layer 1 costs 10 cents and then your own application succeeds and then just because of your own application succeeding it clogs up Ethereum and fees go up to $2, then like that's also a risk for you, right? And so I think we

really need to avoid the trap of saying like oh everything is cheap therefore we need to stop worrying about scalability because it's not true, right? And so, you know, I think uh basically we need to get both layer 1 scale and layer 2 scale up to the point where for as a large scale application developer, you can actually come in and you can feel confident that transactions will be cheap enough for you even if um a a huge number of other applications become extremely successful on top of Ethereum and the price goes up to 20,000 and everything goes crazy at the same time, Right. And uh I think if we just kind of sit back and say things are cheap today,

then like that's not good enough, right? Like we have to actually provide that level of guarantee that developers can trust. And I think if we do then like there are plenty of people that are actually willing to come and build those apps. So that's a big part of the answer. Another part of the answer is that I think uh as a community we do need to be more imaginative and we do need to like actually try harder to think about some of these application layer questions, right? And like I think you know the layer 1 infra um stuff and layer 2 infra it continues to be important, right? But I do think that in terms of like percentage of mind share in our community, the layer 1 and layer 2 stuff probably should decrease

somewhat and the application layer stuff should increase um somewhat. And the reason why it's uh important I think is because like if we as an ecosystem don't lead the way and figure out applications that people want to use and that are actually good for users, then like we'll just still be sitting here in 2028 and we'll still basically have like presidential meme coins and ponzies, right? And like that's not a future that I that that I or I think most of us actually wants to see for Ethereum, right? And so I think like active leadership and active thinking of uh applications both that people wants to use and that have business models and that actually make the world better.

Like I think we can do more in thinking about this. And I mean I think the higher quality of infrastructure that we have now means that things that we try today can actually be tried at scale, right? Like you can go directly to a much larger group of much more normal users. So like you're not just stuck within this like group of 500 enthusiasts, right? And so I think we do need to think about both sides. Yeah. Uh probably just two more. So this one Yeah. Could you please elaborate more about about stage two? Why would we need an optimistic way if we're doing ZK?

Yes. Okay. So the definition of stage two is basically a stage two rollup is a fully trustless rollup. What does that mean? It means basically that it's a rollup where if the code does not have any bugs, then everything is guaranteed to be correct. Like there isn't some set of humans that can go in and like flip a few switches and steal all of the money, right? So if you're stage zero, then you're basically just a multisig, right? The proof system doesn't matter. There's like a group of eight people and if they all decide to like click a button, they can take out all the money, right? In stage two, it's fully protected by the code.

Now, the uh the reason why I suggested we need to have both ZP ZK and OP is because right now I don't think we're quite at the level where we can afford to fully trust a code because there's still the risk that code has bugs. Right now, how do we deal with the risk of bugs? We have two different proof systems and these two different proof systems, they have very different risk profiles that are very disconnected from each other, right? like the situations in which a ZK proof would have bugs and the situations in which an OP proof would have bugs are very different, right? And so that's the argument for having ZK and OP. Now the argument for bringing in a TA as well is basically that we want something that in the

normal case lets you finalize in 1 hour, right? ZK proofs they can finalize in 1 hour. OP proofs have to wait for 7 days. And so what basically the what this would end up doing in practice is in normal operation what happens is someone proposes a state route ZK signs off TE signs off it's finalized right and like the OP thing never actually gets called the place where the OP thing gets called is if either the ZK has a bug or the TE gets broken. If either one of those exceptional situations happens, then the ZK and the TE will give answers that disagree with each other. If they give answers that disagree with each other,

then you have to wait for 7 days for the O and then the OP proof system acts as a tiebreaker and uh it it chooses uh what what will hopefully be the correct one of the two. All right. Uh I think just for the time uh let's wrap it up and uh yeah let's give a round of applause for servital. Okay and [Music]