The Next Five Years of Ethereum Core Technology

EDCON 2025 · September 2025 · 37:49

Vitalik Buterin surveys Ethereum’s next five years across the base protocol and application layer. He connects Layer 1 scaling, greater blob capacity, block-level access lists and zkVMs with the challenge of keeping nodes accessible, then considers how security, privacy and usability improvements can support a more stable foundation for applications and Layer 2s.

Speakers

Topics

From EDCON 2025, hosted by EDCON.

Transcript

ceremony on the main stage. Speaker, we will now move on to the conference presentations. We are honored to welcome the founder of Ethereum, Mr. Betric Butin. Mr. Butin, the floor is yours. [Applause] Okay, testing. Okay, so today uh I I thought I would uh start us off uh by just talking uh at a high

level about uh some of the things that are happening in the uh next five years of uh Ethereum's core technology. Right. So this uh includes both the Ethereum layer 1 which is the base on top of which everything else is built. It also includes some uh really interesting and some really important uh application layer pieces, some pieces that are closer to the user and also talk about uh like what each of these things mean uh to applications on Ethereum and uh you ads to users on Ethereum. So a big short-term focus uh that uh we've had this year is uh scaling right and

this includes scaling on the L1. This includes scaling L2s by increasing the number of blobs. And so this year uh we already saw the Ethereum gas limit go up from 30 million to 45 million. And uh there's uh already research happening to verify that it's safe to continue to increase it even further. Uh we've already seen uh EIP444 uh start to launch which means that a large portion of Ethereum history. Um Ethereum's nodes no longer have to store. And uh this basically means that Ethereum nodes can continue to be smaller and continue to fit on uh

smaller and more different types of hardware. At the same time as the Ethereum blockchain continues to scale. We also saw in the Petra hard fork the number of blobs go up from three the target go up from three to six. And we've already seen L2s increase their scale and uh mostly start to make use of that extra space and uh a lot of a lot more things that are coming on the horizon. Right? So for around the end of this year, we have planned the Faka hard fork and the Versaka hard fork is has this technology called Pieras which basically allows for a much larger number of blobs which basically means

that layer 2s on top of Ethereum. So including optimism, arbitrum, base, tao, scroll, all of those, we'll be able to include again a a significantly larger amount of data. And the plan is to continue to increase this amount of data so that if you launch an L2 on Ethereum, then you know that it will that it the space that available will continue to increase and you will be able to publish all of the data that you need even as you grow and as you get a larger number of users. So this is on L2. Um I think uh some of the other exciting things that are happening are the things that

are happening on L1, right? And here the challenging goal is basically that we want to increase the L1 gas limit. So increase the number of transactions that we want to store on L1 while at the same time preserving the protocol's decentralization, right? And this is difficult, right? Because uh if you just crank up the gas limit, then running an Ethereum node becomes harder, right? And the harder running an Ethereum node gets, the more centralized the network gets. And so some of the uh tools that we have some really fascinating technical work that's happening this year. One of them is uh this concept of block level access lists where basically what this is is as part of every block

the block will contain an object that says these are the things that happened in that block. And the goal of this is basically that uh one it enables parallel processing right basically if the block contains the information that says what are the things that happened as a result of every transaction then every node that verifies the block is able to process every single transaction in parallel. Right? And so Ethereum basically gets as much parallelizability as basically even a chain that is perfectly designed to be as parallel as possible but at the same time this this is true despite the serial properties of

the EVM. So much more paralyzability um and uh also a lot more parallelizability between execution and between accessing the disk and also it works really well with this other tool ZKVMs right so zkVMs uh this is a technology that I think we've been talking about thinking about working on for basically the past like 10 years right so how many people here have been in in Ethereum for more than five years more than 10 Okay, so if you've been here, you probably remember more than 5 years ago, right?

They give you openness. They give you censorship resistance. They give you decentralization. But everyone gets to see every transaction and everyone has to download and verify every transaction. Because of the first, you don't have privacy. Because of the second, you don't have scalability. ZKRS happen to solve both problems, right? They allow you to make a proof, a cryptographic proof that you made some computation and that that computation has some particular result. And that proof can be verified by anyone very quickly. And when they verify the proof, they know that the computation was was run correctly even without having to do any comput more computation themselves.

And also they know that the the result of the computation without even needing to see the information that went that went in. And so you can use it for privacy and I'll talk about how we're doing that. And you can use it for scalability. Now for scalability basically the idea is you have one proof that basically verifies that this block level access list this object that says in this block these are the storage slots that's change that that changed these are the new accounts that got created the this is the amount of ETH that moved from this accounts to this other account. The proof says that this whole list is correct that this whole list actually is the result of processing all of the transactions.

Right now, this is cool, right? Because what it means is that you can run a full node. You can run a node locally on your machine that uh keeps up to date with the Ethereum chain that processes every Ethereum block. And it can do this without actually needing to do all of the EVM computation by itself. Now this is also powerful because uh it gives you a lot of options for really cutting down the resource requirement for running this type of node. Right? So today an Ethereum node including the history 1.5 right now I see people here with laptops whose laptop here has more than 1.5

zero hands one hands raised anyone else even if your laptop's not here if you have more than 1.5 terabytes right see basically no one has more than 1.5 terabytes now with EIP444 you can for you can basically throw away the history, right? If you throw and then especially once we take it a couple of steps further, right? And so if you throw away most of the history, it goes down to maybe 500 gigabytes. Whose laptop here has at least 500 gigabytes? Those exist, right? Now if you uh if we do these uh block uh block level access list and zkms then you actually go even

further right because your node it will not it will not even have to store the tree. It only has to store the state just like the table that says this account has this number of ETH this account has this number of ETH this account has this much code this account has this storage slot has this number the state today is uh about 80 gigabytes. Now let's say naively we increase the gas limit from 30 million to let's say 100 million right increase it by a factor of 3.3. Now obviously it'll take time for the state to grow but like approximate 80 gigabytes multip about uh three uh 3.3 right and you get to about laptop here at least 260

whose phone has at least that amount like the nice like you you will literally with these technologies especially I think with the next generation of phones in many cases literally be able to run a full knot on a phone right because uh all of this stuff it will uh reduce the disk requirements and then the fact that you have a zero knowledge proof means that you don't have to run EVM yourself and so it doesn't matter if your phone has like much less processing power that's like okay all you're doing is you're just like updating numbers in a table right and so you like literally a full bee on a phone that slides.

So ZKVMs basically you and then you have other tools. So we have gas repricing, you have slot optimization, a lot of different things. And uh basically we'll be able to have much higher gas limits at the same time as the Ethereum blockchain becoming much more decentralized, right? At the same time as the Ethereum blockchain becoming much easier for you to run a node and much easier for you to verify the chain and see everything that's happening. So this is really powerful. Um one other short medium-term focus, interoperability. Um, so who here has coins on more than one L2?

Okay, lots of people. That's good. So, who here remembers like the process of moving coins from one L2 to another L2? Who here thinks it's easy? Okay, not many hands raised, right? So, I argue it can be easy and it can be trustless, right? And there's a number of protocols that are working on this. So, there is ERC7683. Um, also as there's starting like EIL is like another one that that a team at the EF is working on. There's starting to be more and more work on enabling both trustless cross layer 2 asset transfers with very a very high standard of user experience. The goal is that ascend from optimism to arbitum should feel

equivalent to ascend from optimism to optimism or from Ethereum L1 to Ethereum ML1. And uh basically with at least liquidity providers with reasonably small amounts of money like you'll be able to make a transfer very cheaply within 2 seconds. So this is step one. Step two is fast settlement for L2s. Right? So today if you're on an L2 and you have ETH on optimism and you want to take it out and like use the native withdrawing process, you have to wait a week, right? Waiting a week is annoying.

So what you can do today is you can basically like you can withdraw through something like a cross and what that means is you're paying a liquidity provider to wait a week for you. Paying someone else to wait a week for you is expensive. And so what we wants to do is we want to reduce these withdrawal windows from 7 days to 1 hour and then to 12 seconds. Now how do we do this? Basically we have to move away from optimistic roll-ups and we have to move toward ZK roll-ups. we have to move toward ZK ZK proofs for everything, right? And so like ZK really is the magic bullet that makes everything work, which like almost, you know, in the same like like I like I think roughly to the same extent that like LLMs have been

this decade, right? Like you remember, you know, like 10 years ago, like you had to go to Google Translate to like translate them some stuff and then, you know, you had to go somewhere else if you want if you wanted to draw an image and then if you you wanted to go somewhere like to Google if you wanted to search and now like you can use an LLM to do everything, right? Like ZK I think is like basically that but for the crypto world. So you know powerful technology we need to use it. We are using it longer term. Um also stage two. So improving trustlessness also proof aggregation uh so allowing like basically zero knowledge proofs that go on chain to all be combined together into one proof and so that saves gas and L1S load allowing L2s to read L1

directly right so what we can do is we can get to a world where if you have a coin in optimism you can natively move that coin down to Ethereum within like basically 12 or 24 seconds. So I this is uh I mean obviously an ambitious road map but there's a lot of work that's been happening and I'm pretty confident uh that we can get there. So now let's talk about privacy right. So privacy is has been uh probably the big new topic for uh Ethereum this year. I mean privacy is something that I've been talking about basically from the beginning, right? But uh and then like I've been supportive like of tornado cache and then rail gun

and uh also ZK identity protocols and and ZK voting protocols and all of these things from the beginning. But uh we have really increased the amount of emphasis that we put on privacy as a base level feature that any that any Ethereum user should be able to have and expect this year, right? And to me the reason why is one privacy just is important, right? Private if you remember all the way back to projects that were doing cryptocurrency type things before Bitcoin. If you look at chamomash from 1982 for example, it actually did not have any decentralization. It relied on a server

but it did have privacy. And so privacy was like the whole time considered this very important first class goal, right? And I think this is true not just for crypto people. This is true even for a lot of people in the main uh in mainstream like business even governments, right? Like when we talk about not trusting centralized services, a lot of the time the type of abuse that you're worried about is not like those services going in and editing your spreadsheet. The the the abuse you're worried about is how much data that they're slurping up and potentially selling to someone else and you have no idea what's happening to it without anyone knowing, right? And so privacy is a very important type of security and

it's a type of security that before we did not have the technology to provide. The early versions of decentralization like Bitcoin they provided decentralization at the expense of privacy but today with Ziki snarks we do have the technology to provide it. And over the last five years, what we saw is we saw privacy go from something where we have some really cool demos and some interesting theory and some fun blog posts and like you have fun little math equations and there's some diagrams that I would try to draw and you can go and like try to learn them to something that you can go and actually use, right? So um who here has sent a Yaza transfer on

Ethereum already? Okay, good. Quite a So I hope that within one year's time there will be three times more hands raised. Um who here has done a Yazik vote uh before fewer hands. I hope that within one year there will be nine times more people raising their hands on this. Um who here has done any kind of zk operation before? So not a payment, not voting, but other DeFi. Okay. Well, my hand is not raised, but I hope that within one year there will be 27 times more hands including mine raised. So we can uh basically go through the list of things that people want to do on

Ethereum and we can give privacy preserving options for each one of them. Right? So on the left here we have uh this is rail gun um and uh it this is a privacy protocol and uh I mean it's a really cool privacy protocol. It actually works a lot of people use it. They also have this uh association set mechanism that ensures that they can provide strong privacy without back doors to their users but at the same time um like ensure that very few bad actors are using the protocol. And uh on the right we have Aragon and Aragon is a DAO project like it's a a project that's writing software and tooling for Dows

that has existed for a long time and uh they have been recently getting into um into ZK voting. Uh so a lot of progress on these two things but I don't think we should have privacy wallets. I think we should have wallets and wallets should have support for privacy features. You should not have to open a separate application to do a private send. The default type of send should be a private send. And these are the kinds of things that we're already starting to work on and uh do. So some key technologies. So zk snarks obviously. Um another one is uh client side zkvm. So you should be able to prove things about um transactions that

you can make. uh prove things about thing about um things that are happening on the Ethereum blockchain, prove things about EVM computation locally on your machine, right? And the reason is that we want the privacy uh Ethereum world and the rest of the Ethereum world to speak the same language. Now, doing this is uh obviously harder, right? Proving EVM is harder than proving a Merkel branch, but uh a lot there's a lot of things that can be done to actually make it happen. privacy pools and association sets. Uh so uh I mentioned this basically technology that lets you uh essentially preserve your privacy but at the same time prove that you're not uh that you're not from some set of known

bad actors. Um Macy technology for ZK voting and uh the trust assumptions in Macy can be improved quite a lot with things like FHE offiscation and sending transactions through mixed nets. So when you send a transaction like it should not be immediately visible like the link between you and what transaction you sent to whatever like internet endpoint you uh like you use to connect to the internet. So basically know we want to look at the full stack right and we want to really shift the focus from building cool tech to let's make the average Ethereum user experience private.

Um, now that was privacy of rights. Now we can also talk about privacy of reads, right? So here's the challenge, right? Imagine that you're using a bunch of Ethereum applications. A lot of them are using ZKRS. It's private. It's super amazing. But you also need to read the chain. You you a every application requires you to check things like what is your balance? What are recent transactions that I've received? It requires you to check a lot of things and uh when you generally uh like because full nodes are so difficult to run people do these uh do these reads by trusting an RPC server and when you trust an RPC

server then the RPC server knows everything about which addresses uh you're accessing what your IP address is what what sets of addresses you accessed from the same IP and so it can learn the links between different accounts like it can warn everything. So we actually have quite a lot of weak a lot of weaknesses here, right? And I think this is a problem that we've been historically neglecting and uh like we have things like Helios for example, right? And Helios is a light client. It's a wrapper that can wrap around an RPC and it can prove that the RPC is not lying about like what's about what thing the things

that it's telling you about Ethereum. Now this type of security is important right because uh if you're making a trade on unis swap like say you're buying ETH for USDC and uh you know you make a trade and right now the price of ETH is 4500 but imagine if you're buying one ETH but then your RPC provider lies to you and it tells you that the price of ETH is 5500 and then you don't think and you go and you click buy and then you make and then you make a transaction and then that transaction has a minimum a price of 5,500 and then you could imagine that RPC server then grabs that transaction. It sandwiches it so it it attaches its own transaction right behind and so you buy ETH for $5,500

instead of $4,500 and then the extra,000 gets immediately snapped up by the attacker that hacks your RPC. So this is bad, right? So what Helios is doing is important, but Helios so far has not even been trying to tackle this other problem, which is how do we protect your um RPC from learning every single thing about your usage of the blockchain. So there's actually some interesting technologies there that we can talk about. So um also we can talk about not leaking to anyone other than the RPC provider, right? Like it's one thing to have an application where the application talks to an RPC and you can choose who the RPC is. It's much much

worse when we have mainstream applications that are hard- coding a bunch of their own servers to talk to and then you as a user basically don't have a choice. So also we can talk about hiding the contents of the read. We can also talk about hiding the timing of the read. So some technologies here that can help. Uh so TE plus OAM this is like a very short uh a short term but very practical thing basically use trusted hardware together with this cryptographic primitive for encrypting the locations of memory and what this lets you do is this lets you do send a request to a server that basically says I want information about this address and the server responds to

the request and it does this without learning like what address it just gave you a response. respons. So this is powerful and uh if you trust the hardware then this basically solves the privacy of contents of the read problem but trusted hardware of course a lot of challenges and if we don't want to trust the hardware then we can go to the next level and then there is a cryptographic technology called private information retrieval that does the same thing with a much more unconditional level of security. Then you can also do like padding and you can do dummy requests.

Uh so you could have uh your wallet can just automatically make a requ batch all the requests and make a request every like say 200 milliseconds. This is like the same sort of stuff that tour does and then like basically your RPC provider then knows nothing except are you online right now? Are you offline right now and that is basically all that they learn. So this is pretty powerful right and uh like this really plugs a a lot of the holes that we have in terms of user privacy. Um one different approach that we can take is what we call partial state nodes. So a bit earlier I was talking about how it's going to become easier and easier over

time to run an Ethereum node. Now, why do you necessarily care about running an Ethereum node if you can just run a light client? Like, why do you actually care about holding all of the state yourself? And the answer is, well, you want to be able to read it, and you want to be able to read it very quickly and efficiently without actually having to um do uh uh like without having to leak to an outside server what you're reading, right? And so this whole TE over MPIR and uh like padding type of approach is one way of doing this, but it has weaknesses. It has more trust assumptions. It's more expensive. And so

it would be nice to also pursue this other approach where you're basically just downloading all of the data locally. So if we do this then basically yeah it be like it actually becomes viable for you as a node for you as a user to just download and store first the entire Ethereum state or potentially you can go to partial state nodes which store not the full Ethereum state but maybe a large fraction of it and then you will be able to read all of the data that you need to read without even having to make any kind of request to the outside. So a lot of ideas here for improving privacy in of reads as well, right? So this is the type of like comprehensive approach that we have to

improving privacy on Ethereum and there's a lot of other privacy projects that matter. Um so there's also L2s, Aztec and IntMax I think are both very impressive. There is uh a lot of uh like projects trying to make more privacy friendly applications. A lot of important things. Now another big focus is uh faster slots and finality right basically can we uh decrease the um the slot time in Ethereum make the user experience even faster and can we make transactions finalize even faster so the main challenge here is how do we do this safely how do we do this without breaking Ethereum's decentralization

right if we just suddenly reduce Ethereum's slot time to two seconds or even 1 second. Maybe the Ethereum network will break, maybe it won't break, right? But even if it does not break, the problem is that once you push the slot time down that far, you create a huge advantage to whichever validators are located in the same place as all the other validators, right? And when you create that large an advantage, then that just creates this like very powerful black hole pressure and it causes the network to all concentrate in one place at the same time. We do not want this. We want to make sure that it's economically viable for you to participate and be part of the Ethereum

network from anywhere. So this takes a lot of research. It takes uh network optimizations, erase your coding. It takes three um three swat finality, new consensus protocol ideas, new fast finality ideas. So a lot of uh a a lot of hard technical work but people are generally confident that we can decrease the slot time quite a bit and we can basically make it so that uh you know if you send a transaction you will on average maybe only have to wait two seconds before that transaction gets included into a block. Um, one other big medium-term focus is uh also stronger guarantees for transactions, right? So

basically if you send a transaction and especially if you send a more complicated type of transaction like using a privacy protocol like using a smart wallet these are things that you should be able to do and you should be able to reliably expect them to get included on Ethereum without um needing to depend on trusted intermediaries. Right? Today, a lot of people are really taking shortcuts on supporting smart wallets. And the shortcut basically is to make the whole thing depend on a trusted intermediary that packages your transactions. This is not acceptable, right? We want it to be possible to send transactions directly and get transactions included onto Ethereum

directly. And this requires uh in protocol account abstraction. So things like EIP7701 and also Fossil which is a proposal that basically means that you have about 16 different actors in parallel that are able to schedule transactions for inclusion in the next slot. And what this means is that even if block building gets very centralized there will still be a strong guarantee that there your transaction will get included on chain. centralized block builders will not have the ability to just say I don't like this set of transactions and so I'm going to delay them for a very long time. So this is important right and these are things that are also

actively being worked on probably will happen later than some of the short-term scaling stuff but uh still important longer term focus lean Ethereum right so this is uh the subset of Ethereum research that's recently been run by Justin Drake and uh lean Ethereum is Ethereum's a long-term future right basically the idea is you We had Ethereum 1.0 the merge you you can call it Ethereum 2.0 I think lean Ethereum will be Ethereum 3.0 Now, and what this means is uh we needs to really make sure that every single piece of the Ethereum protocol is something that is uh simple, secure, optimal, efficient that is good

enough that we are comfortable with it with that piece sticking there for Ethereum's Ethereum's very long term, right? So we basically wants to look at every single major primitive that we use in Ethereum including hashes, including signatures, including zero knowledge proofs, including consensus protocols, including the virtual machine, including everything and really like figure out what is the ideal secure, simple, optimal version of that thing and incorporate uh and then create a road map to actually bring that into the Ethereum protocol. Also a key goal of lean Ethereum is quantum resistance. Uh so a lot of forecasters

believe that there is a 50% chance that we will have uh quantum computers that break cryptography before 2040 and even a 20% chance that they'll uh that it will happen around 2030. And so what this road map will do is within a few years it will give us quantum resistance at every single layer of Ethereum. Then um also formal verification right so using machineverifiable proofs to verify that everything is implement is uh implemented correctly that everything satisfies the properties that we that we expected to satisfy uh to make sure that everything actually is secure right so really pushing Ethereum toward like

actually being this like really ideal clean um like beautiful um base layer that actually make sense to run the base of global finance for the next century. So what does all of this mean for users? Right? I think uh the first important thing is uh scalability and usability will steadily increase over the next few years. So who here um has uh um sent a transaction in the last six months?

Okay, good. Um, who here has not sent a transaction in the last six months? Okay, no hands raised. That's good. Uh, so who here feels like gas prices have been too high for the last 6 months? Okay. Okay. No, it's good. I mean, we need to be more ambitious, right? Uh, but relative to his relative to what they've been historically, the the gas prices have been very low, right? Like today, even a privacy preserving transfer which takes 500,000 gas only takes about$1 to2 dollars in transaction fees. This is like insane. Like I remember back in 2019 2020 like one of these a privacy preserving transfer took $45 in fees.

Actually the highest I ever paid at one point I paid an $800 transaction fee for uh for for making a private transfer. So compared to that compared to those days fees have gone way down. Now part of the reason why fees have gone gone way down is of course we have layer twos we have more places to do execution and another part of the reason is that the L1 block space has also increased somewhat. Now what we want is uh we want to make sure that L1 scales enough that fees stay low and ideally get even lower even as the uh we potentially get another crypto

bubble and we get another big burst of user interest and activity. So this is the goal of scalability right to keep fees low to push fees even lower. Also improving usability. Uh so reducing the amount of time you have to wait, reducing the number of clicks you have to make to do important things. Improving user level security, giving people more options for being confident that they will not lose their funds. Also, it will become possible to build L2s that have very strong and UI scaling and UX properties and that integrate deeply into and that benefit from Ethereum ML1. Right? I think the technology to launch an your own L2 will

continue to get easier and easier and the technology for existing L2s will continue to get better and better. And what I think we'll see is we'll see L2s that really optimize around being very interoperable with this bigger Ethereum ecosystem and with each other. Also, trust assumptions will steadily decrease. it will be possible to do more and more things for more and more people in a way that is trust minimized in a way that does not depend on like five different servers for the safety of your assets and like 15 different servers for the for the safety of your data. So this uh there's a lot of challenges here right so things like the bybit hack they show that it's not just safety of smart

contracts that matters it's also safety of the uh the front end of the user layer and this is something that we can improve we can uh switch to front ends being on IPFS and we can switch to a world where something like that is a default for applications also I think uh we will continue to prioritize trustworthiness and security of the Ethereum L1. People and institutions value the Ethereum L1 because it is the chain that does not go down. And this is something that I think is continued to be important and that we'll continue to uh build on. And also Ethereum will I think stabilize more and more over time, right? And I think it will become more

and more clear over time what Ethereum's final form actually looks like. And there will be features that continue to change. And uh I think there will also be parts of the Ethereum protocol that uh u become more and more stable pretty quickly, right? And so we will actually get to a chain that has a lot of scalability that is very usable that is an excellent base layer for building L2s and applications on top of that is accessible for each and every one of one of you to run a node and to part and to participate in uh directly and that will be something that is secure enough uh to run a trillion dollar financial ecosystems and very uh powerful

non-financial in all kinds of the research and development teams are excited to making these things happen. Thank you. [Applause] >> Thank you very much.