# Ethereum Protocol Update Scale Blobs - Devconnect - Channel: [Devcon](https://streameth.org/devcon) - Date: 2025-12-09 - Duration: 32:23 - Topics: blockchain, smart contracts, distributed ledger, ethereum, Science & Technology - Watch: https://streameth.org/watch/yt-9tLs0U-mp-c - YouTube: https://www.youtube.com/watch?v=9tLs0U-mp-c ## Description Speakers: Ansgar Dietrichs and Barnabé Monnot Event: Ethereum Day (Devconnect Argentina 2025) Keywords: Ethereum, Protocol, L1, Scaling About Devconnect Devconnect is a week-long gathering of the Ethereum community with events for developers, researchers, artists and creators. It’s organized by the Ethereum Foundation and took place in Buenos Aires, Argentina in Nov 2025, with ~20,000 attendees. What’s next The next major Ethereum community event is Devcon 8, happening in 2026. For updates visit: https://devcon.org More Follow us: @efdevcon · @ethereum Learn more about Ethereum: https://ethereum.org And the Ethereum Foundation: https://ethereum.foundation/ ## Transcript Hello everyone. Uh great that you all could make it here. I'm very excited for this talk. Um so this talk will be shared between Barab and me. I'll start and then Bannabe will take over. And I wanted to start with a a quick recap, right? Like what does protocol even mean? I mean we all know the word but like what does it mean in this context? And so specifically um throughout this year there were a few changes um at the EF and uh you might or might not have seen this this blog post that was late April of this year by our new executive directors Shaw and and Tom that basically outlined as part of the the kind of the focus for the for the um coming year these three priorities at specific focus areas for the EF scaling Ethereum mainet scaling blobs improving UX um with kind of addition including interop application layer and that really kind of kickstarted internally as well. We have a lot of technical teams um in different places in the app and some sort of like thinking about how can we best um structure ourselves to deliver on these priorities in particular and so a month month and a half later there was a an official kind of um adjustment to the organization of these technical teams and and there was the beginning of what we call the protocol cluster. The protocol cluster is is the group of of the of the um most of the technical teams um at the Ethereum foundation. And in that blog post as well, you see again this kind of like by now it was a bit more concise. Scale L1 scale blobs improve UX. And I wanted to just basically give give a bit of an status update. What have we been doing? We are now six months into that 12 month month focus uh time window. What have we been doing doing in those six months? What are we going to do in the next six months? Uh where are we at? And so I'll talk about the first two here. scale at one scale blobs and then Bannab will talk about um improve the UX. Um first though I wanted to briefly have have one more like way of of or two two more quick just like mental models for you to maybe like consider in terms of like how are these three priorities somewhat different. The first one I would say is to what extent were they existing focus areas at the at the Ethereum Foundation. And so Scaled L1 was in some ways existing because we had this existing focus on ZKEVM as the long-term big upgrade that will help um move Ethereum throughput to like really exciting levels. But what was new here was the attention on the near-term. Basically saying, hey, before we get there, what can we do? Scale blobs was really much more saying of, hey, we've been doing this already over the last few months. um let's really communicate clearly to the world that this is a big priority and we'll continue to to focus on this and deliver here. Um and then improve UX was new not in the sense of course Ethereum UX has been a big topic for a long time but basically rethinking a little bit what can the role of the EF as a coordinator in the ecosystem be here. So that's mental model number one. And then mental model number two is maybe you are um aware of this kind of this idea of like zero to one, right? Creating something new. And ideally you read the slide from bottom to top here. So basically UX again it was about what should the role of the F here be. So it was much more of like a zero to one ex like coming up with the strategy like tying all these individual pieces. UX is a very broad topic tying it all together. And then scale the blobs was a 1 to 10. We already had the existence proofs. We had already um um deployed an early version of this. Now it was about scaling this and then of course mainet itself Ethereum L1 has been around for a while and so the idea was primarily here it's much more about a continued kind of bringing this to even to even even more mature production. So those are the general kind of considerations and then I want to start by going into scale the L1. So what was the situation? The situation early this year was that the gas limit, that's how we measure the the total throughput of Ethereum, had not been changing for close to four years. So ever since early 2021, it was before EB559 for those of you that are familiar with these technicalities, it was 15 million and then with 1559, we added this like 2x um factor between the target and the maximum. So now it was 30 million but ever since basically we we had been at 30 million and why was that? Well because the engineering focus was on other really important things for Ethereum. That was first the merge then it was really interesting new features. Um just the fork before we shipped uh EIP702 for those of you that have maybe started using these smart accounts. Really amazing features but a different focus. And then of course the robustness of the chain is always a top priority for Ethereum. So that also took a lot of attention and we already had a long-term plan, right? So Ethereum already had this plan ZKVM. Eventually there will be a big upgrade. What was new now was basically to say hey we also really want to focus on the short term. What what can we what can we bring to the chain now? Um and in particular there was actually it was really interesting. There was an organic push by the community earlier this year to say hey 30 million is a bit too conservative over the last few years of like just continued performance improvements in the clients. We've built up a bit of a safety margin. Let's just push this a little bit. So there was this initial 20% bump and there was really a strong signal that hey this really is something that the community is really passionate about that that that we should really make a make a priority for the for the next while. So that's where we were right not really changed for a long time and then we had this first initial bump this like sign of life that actually we we have like room to grow with with with the throughput. Um and then there was a bunch of people just like exploring the idea. So like on the left you see a blog post by Vitalik from early this year, I think it was February, where he was basically saying in the in the lower left column, hey, we we even even if we want to have the the one be mostly used for settlement, a 10x or something is actually not a bad idea, right? Like that that seems like something that baseline we should probably do. And then we had a month later we had Dunkrad um a bit more aggressively saying, hey, what if what if we actually go like 100x, right? Like I think there's room to to go to go this far. And then Justin like he usually does just came into the room and was like you all are not excited enough like a thousandx he said it in like giggas gas but if you if you calculate that's that's roughly a thousandx from from where we are um were at the beginning of the year is possible once once we get to this magical technology of of zero knowledge based scaling. Um but all of this of course that you know like you hear this 10x 100x a thousand x and so like what did we actually do like where are we at today right like bringing it back down to earth so first of all why is scaling even um a challenge like why can't we just run faster right um so in principle you can think of this graph like the cost to run a full node and the throughput in the system and Ethereum is somewhere there like in the kind of the middle of course it it's relatively cheap to run an Ethereum node you can do it on on home a hardware um and we have decent throughput but not not basically like where people would want us to be and so an easy way to scale of course would be to just like go up the the diagonal right like what you can just do is you can be like okay now if you want to participate in Ethereum you just have to be in a data center and some chains do that and there's nothing wrong with that in principle if that's kind of the the use case you have in mind for your chain but that's just not the Ethereum way right Ethereum wants to be this very um open to everyone robust uh decentralized trustless network and for that we just cannot simply increase the hardware requirements. What we did do is early this year as part of this effort we did we formalized the requirements and you can look it up EIP7870. Um we formalized what exactly are the uh hardware requirements to to run an Ethereum node. Um and that that was part of what what what got this initial bump. But like how do you scale this without going up the diagonal? Well, there was basically three phases to this. phase one. Oh. Oh, yeah. To just briefly um summarize. So, basically like what what are even the reasons why they why why basically you have to be careful with scaling. There's I would say three buckets of things that hold the network back that you have to you have to you have to deal with live processing being able to follow the chain as it progresses. You need bandwidth, compute, disk access there. Um then cumulative things that don't in the moment create problems um but over time if you don't have a strategy there um become an issue. And then you have other really important parts of the network, the syncing, the transaction pool, the RPC, all of these really need to work in a very robust way. Um, but at least for the initial kind of like getting the process started, the really the main bottlenecks are these like being able to follow the chain no matter what it throws at you, right? And so that's where we initially started the journey. Um, in the short term, what did we do? Well, you can think of this image. It's it's more like a symbolic representation in green. basically all the operations that are available in the Ethereum virtual machine like each spike basically something you can do when you send a transaction different different operations and they all are differently efficient. So if you use these like small spikes, Ethereum runs very smoothly. But if you use for example like I I marked with orange like basically the worst case operation you could use in Ethereum. If you were to like exclusively run use the ver worst case operation, you basically push the Ethereum virtual machine at to its very limit. And so that's what what governs how large we can make the cycle the circle overall. So again just a mental model but what did we do in the in the early days early this year? Well there was this loop. You identify the current bottleneck, you optimize that current bottleneck. So now the spike is gone and now you can scale the entire machine a little bit. Right? So that's something that you can do without having to change the circle. The circles are your hardware requirements. But just running this optimization loop getting rid of the spikes allows you to over time start to slowly scale the chain in a responsible way. So that got us in July already. We got started in June again July. So like very early on we had this like first easy win the the first batch of performance improvements 45 millions right so now we're 50% above where we started the year that's already kind kind of nice and then second result just now if you've seen we have the upcoming Fusaka hard fork we all very excited and that comes with um the default rollout of 60 million gas so we'll soon move to 60 million gas um so now we are at at double so that's step one right just performance improvements step two is actually changing the protocol to be more efficient. So um so for that we have Pusaka. Pusaka helped a little helps a little bit. It gets rid of some of the worst cases. So hopefully we think that we can get to roughly 80 120 million uh once once that's live and we can we can test that that's stable early next year. Um and then much more excitingly next year we'll have a big hard fork lump sadam where scaling the L1 is really the main focus of the fork. So we have EPBS, B level access lists, and repricings. If you're more on the technical side, maybe these these uh terms tell you something. If not, really doesn't matter so much. These are three really exciting features that all make Ethereum a bit more efficient. Specifically, repricing. I just wanted to give you this um yeah, specifically um and and and basically the goal here would be to say, hey, you know, this this DA proposal 100x over four years, it's not sure that we can do that for four years in a row. That will be a challenge as we go further along. But for now, can we basically embark on this journey three times the throughput per year and see how far we can climb there. Um, and just for repris, I wanted to give you this quick mental model. The idea here is right, you keep the box intact. Like that's always the through line you should keep in mind from this presentation. The box stays intact. Um, we are not basically like pushing into higher hardware requirements, but we make it we basically make the most out of our our available resources. And then one last slide on scaling the L1. It's just you should keep in mind ZKVM is coming. ZKVM also very very exciting magical big techn technology upgrade and the big challenge that we were that that basically is at the core there is real time proving. So ZKVMs have been around for a while, but for Ethereum's L1 use case, you really need to get the proving time down to um um basically within this 12 second window that that we have available in slot and kind of big progress this year. We actually in the average case performance are there now. So we have average case proving times that uh that are below 12 below 10 seconds even. Now caveat this is really just early days. Average time does not mean worst case performance. it also does not mean it's secure yet. So there's there's a long way to go but as like a first step this is really absolutely amazing progress and the entire industry entire ecosystem has come together to to achieve this. So um really really exciting to see maybe I don't know quick round of applause for everyone working on ZKBM this really has been has been amazing [applause] and then uh just to say like the plan here is also like how we do things in Ethereum now not just shoot for this like long-term goal but also shortterm have these individual rollout stages that already allow us to use the technology once it starts to get ready if you are interested in ZKVM in particular it's a really exciting topic on Saturday there is the e-roof days where you hear much more about it. Um, and so the hope is that with CKVM we can basically like we can really escape the diagonal and we we will be able to have like a very high throughput network that with a low cost of running a full node. Okay, scale blobs. Um, and I'm running a bit short so I I'll have to really speed up a bit. Um, scale blobs. So what are blobs again, right? Data availability on Ethereum. Basically the idea is that roll-ups on Ethereum need two things from the Ethereum L1 that is settlement the ability to actually like update their state commit back down to the L1 and and also like have uh validity proofs false proofs executed on the L1 and then the other big one is data available availability at a station. So you basically as an L2 you need to be able to prove that the data that you used to advance your chain was available because if not there can be these edge cases where the chain where the L2 basically breaks. So it's a really important feature that that was part of this rollup centered road map. Um and initially in the early days what people used for this was just call data. So call data is just data you can pass into the EVM that was an existing feature. people just um roll up operators just reuse that existing feature and that was very inefficient because call data is meant to actually be used during EVM execution. So when you run a transaction, you execute a trade or something, the actual price for the trade for example comes from the data section. So it's very inefficient to pass the entire data that you don't actually need. You just want to make sure that it was available into the EVM. So for small scale use that was fine. But then to get beyond that, the first thing we introduced was EIP 4844. that was um last year which was protodunk sharding um called and the idea is is simple right so basically you see here the blocks of Ethereum the kind of um advancing and now these individual transactions right you can see roll up red and roll up blue basically what they do now they just post these normal transactions in the blocks and they only have this little red and blue dots these dots are called commitments so they just point us to data and then Ethereum just takes the data and says we're going to make sure it's available, don't you worry. So, it's a new service where you can just ask Ethereum to make sure your data is available without having to pass it into the system. And that was a big uh performance improvement. And how do we now check that data is available is an implementation detail. Um, with EIP44 though, we still checked that the data was available by fully downloading it all. Now, what are we doing in this upcoming hard fork? uh Fusaka coming in in in a few weeks has this amazing feature at the very core that's called pieras. What makes pieras? What is the DAS in there? DAS stands for data availability sampling. And that gives you the the the important clue. The idea here is that we make this data availability check more efficient with sampling. And we do that by taking the data we double it. And now that we double it with erasia coding, it means that instead of having to ensure that 100% is available, we just have to make sure that 50% is available. Why? Why? It seems silly at first. we double it. Then we have to make sure it's 50% is available. Why is that a big uh efficiency improvement? It it means that now we can use probabilistic methods. If you need to make sure 100% is available, you need to download it all. There's no way around it because the one thing you didn't check might be the one thing that was unavailable. With a 50% check, you can just sample because if you sample often enough, you get 99.999999 uh% um guarantees. So that's a that's secure enough to to to to run the chain with. And so that's exactly what what what you do. Basically everyone in the in the network now is is sampling small parts of the data. Um and and and you know now we have like multiple rows of data and and that means that uh in aggregate all the nodes uh know that the data was available even though they only downloaded a small part. So that's a huge efficiency improvement. And here this slide was just to show you in reality things are always more complicated like you should not try to understand all of this unless you're already an expert in this. But the point is the actually making this work under work under the hood was a huge effort like it took many many months to to make pas work. But the result is that as of Fusaka in a few weeks and then we roll out the gradual improve increase of the throughput we'll have much higher rate of data availability on Ethereum. Um where will we go after that? uh the team that worked on pedas is already since months uh has been now actively work on the improvements for the next generation uh for now just basically like a teaser there the idea is to say hey now that we have pas like the first version of sampling just make it more efficient in all the stages and there's two specific stages there's the you send a transaction and it propagates through the network that's the stage that's the slow efficient path and then once it gets included into block propagated through all the nodes for sampling and so basically both of these have individual um work streams that that make those much more efficient over the next year. So there will be a lot of extra scalability. Um and then beyond pas the question is will we just keep iterating or will we have a big kind of transition to one of a different architecture full sharding relay does um but we'll have to see about that. So that's basically that that's what the focus was in scale the L1 right scale L1 we we really went from 30 million to now 60 million we'll go to 120 and then 300 wherever we will go over the next years 3x per year is the goal and then Pas where we we had amazing uh efficiency improvements that are rolling out in the coming weeks um and we have a clear path forward there and uh we'll continue to give rollups all the data they need and now on to the last one and BA we will take a little bit extra time so not sure we have time for Q&A I'm sorry about that that's all my fault >> thank you Anza all good [applause] hi everyone so let me jump in quickly so going from zero to one on improving UX meant for us at the Ethereum Foundation that we explore many directions so these are currently active efforts at the EF we have inup which is about how to improve the free flow of assets and value throughout the Ethereum ecosystem we have trillion dollar security which is a security focus focused effort and we have Kohaku which is a privacy wallet that int intends to put privacy as a first class uh UX citizen. We're also working on something that we hope to reveal soon. In this talk I'll focus on interrupt and when I think of interrupt there's really two issues that come to my mind. The first one is about crosschain UX and the second one is about the network value that comes from having free interoperability throughout the network. Let me start with crosschain UX. I would say that this is our goal. We want seamless, secure and permissionless experience across the Ethereum ecosystem both for individuals and for institutions. Today the experience on the Ethereum network is not so seamless. You may have experienced for instance having many different versions of the same assets on different networks. You might have bridged some tokens to a new network and then you didn't have the right token to pay for the gas at destination. And finally, apps don't necessarily know which assets you have on which networks and so they can't offer you seamless flows. For instance, depositing on room using assets that are on base. So the apps, they want to support these seamless flows so that you don't have to go to a bridge and quit the app. So we have a couple of things in the works that we plan to release. One of them is the open intense framework or OAF. It's a modular stack that is built by many contributors in the ecosystem including the Ethereum foundation across Leifi, Open Zeppelin, Wonderland, Hyperlane, Arbitum, Uniswap, Coinbase and others. I just came back from Patagonia where we hacked on the stack and we made some improvements with some of his contribution and individuals. And we want to ensure that the stack addresses the needs of users, wallets, apps, and intera protocols that will engage with it. So why intents? Uh what do they offer for crosschain UX? Intent bridges make it easy to uh find liquidity where you want to transact which means that you don't need to wait for your assets to move on the slow interrupt pipes. The counterparty can just front the funds for you at destination and then you can proceed with the crosschain transaction that you wanted to do. The OIF is modular and extensible so that different protocols can adapt it to their needs. It also offers secure modules for user and counterparty exchanges and it allows many protocols to be routed through OAF. So it's also a bit of an interface. And finally the OAF composes with emerging standards and the interup SDK. Uh it makes use for instance of interoperable addresses which have this human readable form like barnab. at arbitrum and it runs on 7683 which is a standard for deeper liquidity and deeper markets which means cheaper fees for for users. You should reach out if you're interested to work with us on integration. A second project that we have is a new mechanism by the account attraction team named the Ethereum interoperability layer or EIL. EIL will be presented at the trustless conference tomorrow and on Wednesday, but you can already scan the QR code which is on the left here uh to find a post on E research if you're looking for some alpha before the conference starts. So this was crosschain UX uh we are looking to fill the most glaring gaps for user experience by offering easy to integrate and and modular solutions. And next I want to talk about the network value in the context of interup and how to improve it. So what I would say is a confirmation engine is mainet or L1's core service to Ethereum users and businesses including L2s and we must improve this service. L1 is really the beating heart of the broader Ethereum ecosystem. We want this heart to pump blood, oxygen, assets, value throughout the network and we want the heart to beat stronger and and faster. This is to the benefits of the many chains and projects that choose to to build on Ethereum. So what can we do? The first thing that we're looking into is increasing the speed of the L1. So time to inclusion means how how long it takes for your transaction to enter onchain. Today the slot time is 12 seconds. So a block is produced every 12 seconds which means on average when you send a transaction you wait let's say 6 seconds for inclusion. This is a really long time. We we can try it out together to get a sense for how long it is. I want you to count with me. One, two, three, four, five, six. Yeah, this is really too slow. You see? Yeah, we have to improve this. So, beyond UX improvements with shorter slot times, there are also many more benefits to to network value. The first one is that everything refreshes faster on chain with shorter slot times, including prices. This leads to healthier market and in particular it makes it a much stronger value proposition for D5. The second thing that improves with shorter slot time is interoperability with L1 which moves at the speed of the L1. So this also gets better. So here's the plan. We have 12 second slots today. We propose to move to sixcond slots. It's a very challenging engineering task and we're actively working on this and then further into the future we think we should go even lower. How far can we go? This is not something we know let's say today, but we know that we also shouldn't risk a heart attack. So there is a limit somewhere. It's a marathon. It's not a sprint. All right. Besides time to inclusion, time to fin to finality is a metric that also matters a lot to us. What is finality? This is when Ethereum gives you the strongest confirmation that your actions on chain will never be reverted. with faster finality. We have lower capital cost across the network as assets settle faster and so they can move around. This improves UX by reducing latency and cost. Uh we have less incentive to opt for weaker forms of settlement and you also have more valuable network for off-chain systems that depend on Ethereum finality to know what state of Ethereum is settled. So today the strongest finality which is economic finality is quite slow. it takes 13 minutes to to achieve it. So, we're working on a project to make available a confirmation rule that provides some degree of finality while being 95% faster than full economic finality, which confirms in a block or two. There are stronger conditions on the security. So, it's not a replacement for everything, but we think there are some good use cases for this confirmation rule that can be attractive to some of the businesses on Ethereum. In particular, we'd like to talk to L2s, interro protocols, and centralized exchanges about integration of this rule. There are benefits for all of them. L2s can use a confirmed route of L1 faster. Inter protocol can do faster message passing, and centralized exchanges can reduce the delay for withdrawals and deposits. We're working to make it available in Q1 2026. So, we think it's a good time to talk about it. So, please reach out. So, this is today's picture. Then we have our 12cond slots at the bottom. The fast confirmation rule adding this layer of settlement and then the full economic finality up here. Going to 6C slots already gives us a much more responsive network. We have fast confirmation and we have finality time as well. So we have a lot more going on per unit of time. But from there the job's not done. Our aim is to accelerate research and development for faster finality and inclusion. In particular, we want to take the finality time as it is today between 13 and 19 minutes all the way down to perhaps 10 seconds in the future. And you should [snorts] reach out if this is an interesting challenge for you. So, let's make L1's heart a bit faster. Thank you. [applause] Nice. Thank you both so much. That was awesome. Okay, so we have a ton of questions. I'm going to go from some of the more popular ones and then we're going to go one by one. Um, so first question for someone new to this topic, what's the simplest way to explain what why blobs matter for everyday users? >> So why blobs matter? Um, that's that's a very simple question. So I'm sure basically everyone here has used Ethereum and many of you have probably used Ethereum L1, but also most of you will have used a rollup in the past. And basically for rollups the fundamental bottleneck for how fast they can go they have several bottlenecks but one really important one is how quickly can they get their data availability checks from the Ethereum L1. So blobs are necessary that that an L2 can basically take the latest batch of user transactions go to the L1 and say please can you double check that this was actually available data and then the L1 says yes looks good to me and that can only move as fast as the rate of blobs can move. So the more we increase blobs the the the basically the more throughput you will get on the L2s. >> Uh second question what do you think of the trustless manifesto that came out this week by Vitalik and how does that relate to some of the work that you're doing? >> Yeah we're always looking for solutions that respect properties of censorship resistance uh of privacy of open source like these are criterias that are very important to us. As a personal taste, I like the word trust minimization better because there's always a model of the adversary that we have in mind. But yeah, that's all I think about it. >> Awesome. Um, final question. How do you think about the tension between scaling L1 and scaling L2? >> Yeah, that's a great question. So, I think ultimately while there is a little bit of a technical tension in in in a very narrow sense, so specifically on bandwidth use, there's always you can use the bandwidth for more data for the L1 or for more data for the L2. I think that's really a complete destruction like focusing so much on that because most of the challenges of scaling the L1 are not on the data camp to begin with. So really these are um in mostly synergistic and I think the more general point is getting to a mindset of like continuous performance improvements and then those will naturally basically like spread across the L1 and the L2 and many of the challenges for scaling the L2s also will then be for those L2 teams within their own chains. So I really think that as an ecosystem basically just in general make the systems more performant, make them more efficient while making sure we never compromise on robustness that is some that is a general engineering effort that will be synergistic across those two efforts. >> Awesome. And as part of this uh you know you're collaborating with teams across the board from all walks of Ethereum. Uh how has that collaboration been and how how do you feel about it today and how could it be better in the future? Yeah, I mean I think you've already seen like in in in a lot of banner talk with there's this with with these in intense frameworks there's there's very wide ecosystemwide collaboration same on on scaling especially in the ZKVM I'm not sure if you've paid attention to this yet if not either go to the event on Saturday or or watch the stream or something because it's really incredible to see the energy there's like 20 teams with that are all working on different elements of the of the stack it's it's it's a very very large kind of cross the ecosystem collaboration Same with these other efforts, blobs, scale one, I would say it's it's it's um we're starting to also see more collaboration. Everyone in in the ecosystem that has an EVM chain wants to come together on this. For now, it's a bit more of an internally focused effort. >> Awesome. Uh final question. Is there one thing that you wish more people knew about what you do? >> Um I wish people knew that it wasn't so hard to work on this stuff. I think people get intimidated by yeah the complexity of a protocol perhaps but more and more like we're seeing that um yeah people are just coming up to us and asking how do we learn to do this how do we become like core devs or builders on etheum and also as our focus is shifting and we think more about let's say apps users and all of this like we're also really trying to ourselves immerse into into this this other ecosystem so yeah I think people should understand of it's much more of a revolving door between protocol and the ecosystem uh than it has been in the past. Yeah. >> And maybe one one last mention quick shout out in in in our own interest. We have an amazing team at the Ethereum Foundation working on all of these different topics. If any of that sounded really interesting to you and you feel like you're like an exceptional person that could really help push that even harder. H if you go to the jobs page of the Ethereum Foundation, there's an open role. Like we don't always have roles specific to these individual efforts, but there's also an open role posting. If you feel very passionate about any of these topics, do shoot us a message and give it a try because we we always happy to have even more people help with this effort. >> And we have many internships open actually. I think at the moment >> you can just do things. Thank you so much Barnav and Scar. He's going to get a round of applause.