What People Need From Ethereum | ETHLabs | Common S3nse - 2026

CryptoCanal Talks · 12 Sept 2026 · 16:58

Julian Ma introduces ETH Labs, a donation-funded nonprofit started by former Ethereum Foundation researchers, and sets out what developers say Ethereum should ship next. Speed comes first: making slot times parametric so they can fall from 12 seconds in steps, a fast confirmation rule that cuts bridging from layer 1 (L1) to layer 2 (L2) to about 12 to 24 seconds, and fast finality. He also covers larger contract size limits, shortening the five-day withdrawal window on optimistic rollups toward proof-based exits, and work on ETH as a store of value.

Speakers

Topics

From CryptoCanal Talks, hosted by CryptoCanal.

Transcript

Hey guys. Um, I'll get started with my talk. So, thanks for coming here. Thanks for walking through the gene shop for this talk. Let me get started. So, I'm here to talk about ELABS and what we're seeing that um, people want Ethereum to ship. Um, let me start out with a bit of an introduction of what is ELABS. So, Ethabs is a new nonprofit entity helping Ethereum and ETH grow. Um, we started it about 10 weeks ago and we started with five people formerly from the Ethereum Foundation research team. That's where I spent four years as well. Uh, we developed the core market structure here for Ethereum and uh parts of the consensus mechanism. Um, and I think what many of us realized there was that even though the the core Ethereum

infrastructure is extremely important, it seems to be not the thing that's holding Ethereum back at the moment. it's not the thing that's keeping broad adoption from from um coming to Ethereum. And so that's why we started ELABS which has the goal of delivering on what the ecosystem urgently needs in order to ensure that there is going to be more adoption. That's a pretty broad mandate and we're only nine people now. So we started with five growing to nine. Uh and we're doing it mostly via technical means. So this means that we will ship improvements to Ethereum draw protocol. We will improve core infrastructure, but we're also delivering this to exactly those who core infrastructure is intended to serve. And more on that in a second. And so why did we found E Labs? Well,

Ethereum by now is is a massive ecosystem, right? It has over a million lifetime developers. The ETH token itself is like three to 500 billion valuation. And the TVLum is insanely large. And there's it's it's basically too large for it to be served by one single ecosystem steward which has previously been the Ethereum Foundation. Combine that with the Ethereum nation narrowing its scope after its released mandate which was a bit of a strategic pivot for them. Uh it became obvious to us that there was need for another ecosystem steward that helps Ethereum uh in this new age of adoption.

So at ELAs we hold roughly the same values as Ethereum Foundation. So don't expect us to make any huge shifts that you that you wouldn't have been seeing. We value censorship resistance, open source, privacy and security clearly, but we have a different culture and a different culture does actually lead to a very different technical output. So we built different tech even though we all worked on one same Ethereum. That might sound contradictory of how can we have a different output if we worked on the same tech. But actually it seems to be going quite well in a very collaborative fashion so far. Uh the Ethereum Foundation works on very long uh large moonshot projects like ZKVM, Postquantum, but also faster um earlier times uh projects. Um but uh so in general the timelines differ and the

output is quite different. Uh and what eventually will get shipped wasn't decided by Ethereum Foundation anyway. It's always been decided by the group of core developers that decide which items get implemented in the next Ethereum hard fork. And so we propose our items to this group and Ethereum Foundation does so similar. So what is it exactly that we've been hearing that Ethereum should be shipping? Well, for context that was last year as well and then was advocating that we should be scaling Ethereum more. Obviously scaling Ethereum is nothing new. People have been talking about it for ages but the approach has been very different. How people have been talking about it before was through Moonshell projects where we go from a very small small scale to a huge scale all at once via for example

ZKVM uh which has some technical properties which means that you can scale it extremely extremely large. Something that we did while still at the Ethereum Foundation was to start with iterative scaling improvements. So instead of trying to go from 0 to one we tried to go from zero to 0.1.2 etc etc. So Ethereum had been at 13 million 30 million gas throughputs for a very long time and recently it scaled to 60 million. At the end of the year it's going to scale to 200 million and after that it can scale iteratively more. How these iterative improvements work is basically how you'd expect it. There are small inefficiencies in the system that are continuously getting solved. Some of them are are somewhat larger and they're sold via hard forks and some of them are are really quite small and they can be

solved even throughout the year. And so that's how we're scaling iteratively. Another reason why we've been collecting so much user input on uh what exactly Ethereum needs to ship is because uh the next fork items are being chosen. And so the next fork is called headota uh and it's it will be delivered somewhere in 2027 and today the core developers are deciding which items should be put into that fork. So should we for example prioritize faster slots or should we prioritize more skill? Should we prioritize user experience? All of these things obviously being important uh but the finite resource being developer time and so what does Ethereum look like now?

A lot has happened uh and we started with basically one Ethereum foundation and since then it has grown a lot. Most of the growth has been uh happening throughout like the past 10 years or 11 years or so. Uh but there's been some shifts recently and so in this diagram that's tense on EP shared from protocol. You can see um a rough diagram of it. So you can see the Ethereum foundation here. It's still quite large. It's it does a lot of the core development work but then there are lots of other organizations contributing to it. And what I find like extremely cool about this is that Ethereum core developments really is very decentralized. There's it's extremely hard to capture um and there there yeah an infinite many uh number of organizations that are contributing to it in a pure public goods manner uh that are advocating for

what they might think is important uh to happen in the next force. You can see E labs is a is a tiny dot here and we do focus on research engineering and ACD stands for all developers on the execution layer. And my personal fun facts about starting ELABS is that um since we left the Ethereum Foundation, three new organizations have been set up by former Ethereum Foundation members. Ours focuses on the tech that's immediately necessary to help Ethereum grow in the edge of adoption. There's a new organization called Ethereum institutional which helps um institutions and enterprises on board to Ethereum mostly via business development and then there's uh E systems which

helps uh as forward deployed engineers with privacy solutions. Basically, the fun part is that two two of these organizations, so ETH Labs and Ethereum institutional are funded purely with donations. And I think this sometimes gets overlooked, but it's actually extremely interesting. Very few other organ ecosystems are able to fund to large um core development arms with pure no strange attached donations. And most of the other labs that you see in the other ecosystems are venturebacked companies which eventually have to turn a profit um for for their shareholders and so won't be able to do purely what's best for their ecosystem.

So how does the tool actually differ? What is it that we're trying to bring to Ethereum? Well, one part of it is that we want to be more iter iteration first. And so this is something that I mentioned with the scaling as well where we're not trying to go from zero to 100 immediately. We're trying to make small steps to get there. And one thing that we're pushing here is faster slots for example. So slot times in Ethereum have been at 12 seconds for a while. And it actually turns out to be pretty hard to change that even from 12 to like 11. And that's because slot times are like very implicitly baked into the assumptions of the code bases across Ethereum and also on the applications building on Ethereum. Um and so what we're doing is we're first pushing for making that slow time parametric and then we can

iteratively decrease it uh so that we make Ethereum faster. We also reason very outcome first. Uh this might seem obvious, but sometimes um development is very um mechanism first driven and that's because you're developing for like a very long time period, right? And so it's hard uh to start with an outcome because uh you're you're building new primitives that other people can build on. Uh but we're what we're trying to do here is outcome first and it's possible because of the iteration. So we're we're decreasing the time frames that we're building for. And so we're looking at, for example, how do we make sure that application developers building on an L2 have a good way of attracting capital instead of how do we make sure that capital flows as efficiently between the L2s. These are slight differences in culture, but they lead to different tech

outcomes. And then the final thing that I'm spending most of my time on is what we call demand to delivery. And so what we're doing is we're speaking with a lot of developers across um various different industries uh in Ethereum and asking them what are the things that are most blocking you and we were seeing like very uh recurring requests actually. So one thing that's has been a large pain point is the match contract size limits. So this is basically how many uh lines of code or how many how large of a contract you write. I'm seeing some nodding back in the room. So that must probably be an issue. Um that's actually being uh addressed in the next work at the end of the year.

It's going to two and a halfx. Uh so you can write larger contracts that have way more functionality without having the overhead of having to split your code base across multiple contracts. Um what we're trying to do here is have very good user validation of what has to be shipped and also make sure that that what we ship actually reaches the end consumer and I'll tell a bit more about that in a second. So the things that we're hearing is this match contract size limit and it's a lot about speed as well. So people are saying Ethereum is too slow one on like a user experience layer that if you're sending a transaction you'll just have to wait um on average like six seconds until it gets included. Uh but also on for markets for example if you're building a a decentralized exchange speed really

helps and so uh making Ethereum faster would be good there. A nuance that we're hearing in what makes Ethereum slow is the L2 to L1 route. So, optimistic L2s, they have a fiveday uh fault proof window and this is a a technical property that helps keep them secure. Uh, but the effect of that is that if you're sending a transaction from the L2 to the L1 to bridge your funds back to the L1, it can take up to 5 days until you receive your assets. And that's a that's a very human thing, right? It would be very annoying to have your funds stacked for 5 days. And so, that's something that we're looking at a lot. And other things actually are are very non-technical. So people are asking us like what's Ethereum's plan with L2s and uh what's the way that ETH truce value and like should it attr value and one

other nontechnical item that's quite dear to my heart is that there there's a a relatively low number of uh new builders coming into Ethereum. So even though that we have a huge number of lifetime builders we're seeing the new builder ecosystem splinter across chains and obviously being attracted to other industries. So that's something that we're trying to tackle as well. So our first act, our main focus at the moment uh is making Ethereum faster. We're doing so in three ways. One is pushing for faster slots. So again, as I mentioned, we first try to make it parametric so that you can decrease slot times and then iteratively increase them down. So we're at 12 now. We want to go to 10 and then go to 8, 6, 4, and other thing that we're working on is a fast

confirmation rule, which helps bridging from Ethereum L1 to L2s drop down to like 12 or 24 seconds. So this is a 97% reduction from the finality time that Ethereum has today. So it's it's a huge improvement and we're bringing that to market. An interesting thing here is that this technology actually exists. It's being rolled out today. Uh but it's an opt-in rule and it's it's it's like very deep um consensus layer tech. And so we're helping bridges and L2s understand it and see whether it suits their use case well. And then finally what we're working on is fast finality.

This is something that's been a long-term road map item at the Ethereum Foundation. Uh but we're prioritizing it. Uh so we we brought on uh one of the best persons on fast finality uh to help us ship it faster. Uh because we're seeing that this actually is one of the large blockers uh for people building on Ethereum. So just to say a bit more about this fast confirmation rule. So it decreases bridging time from Ethereum L1 to all tools by 97% making it actually quite fast compared to other chains and and uh obviously compared to Trafi. Um, it's an alternative to finality. It's it's not the same thing as Fidelity. The assumptions are slightly different and it's slightly less secure, but it's going to be extremely secure for basically most use cases that you could imagine uh that require like bridging

from Ethereum L1 to O2. Um, as mentioned, it's it's an opt-in rule that's being rolled out today. And so, as soon as the end of the month, uh, bridges will be adopting it. And so, your crosschain transactions should be flowing much much faster uh, by then. Secondly, on L2s, um I think this is an surprising one to sometime some to people when we speak with them. Uh people seem to think that Ethereum has abandoned the L2 road map and to us that's that's not the case at all. We believe that L2s are how Ethereum wins and that's because they are the distribution engines for Ethereum. So this is how we gain new users and this is also where assets that are issued and managed on Ethereum layer one can distribute to new users and new use

cases on the L2. So you see for example assets issued on L1 being used as collateral on lighter which is an Ethereum L2 that's a per deck. So uh again the first thing that we're doing to help L2s is making this L1 to L2 bridging time faster. Uh the second thing that we're doing is studying how we can decrease the L2 to L1 bridging time which is what I mentioned before right it's the the the fall proof window and that's five days which is pretty long. Um after that we're we'll be implementing some sort of proofbased system here so it can be faster uh to bridge from the L2 to the one. Some of this text exists already today, but the problem is that it's it's not really delivered in the in the way that we think it should be. And so it misses, for example, some economic validation of

why would your users care enough about this for you to spend um a lot of money, frankly, on on a proofbased system there. Finally, on the nontechnical side, what we're doing here is refining what the primary markets are that Ethereum, the L1 really wants to to go after. What we're seeing is that this is uh around asset issuance and asset management. There's been competition between the L1 and L2s and in our opinion that's that's a good thing. Competition is good. Uh but we should also go for that competition then. And then finally, something that's been spoken out relatively little in um Ethereum development is ETH as a token.

And we actually believe that E is very important there. There is no good Ethereum without a good ETH token. And so we're looking what we can do to improve e's uh properties as a store of value asset. A part of this is on the technical side. So how can we make sure that it's easier for you to self custody e for example? How do we make sure that e will be quantum safe which is a huge focus for the ethereum foundation actually. And also how do we help it generate more yield in defy outside of staking for example. And secondly there's lots of nontechnical work here to be done. So, how can we help spread the story more?

Obviously, Eve is a very widely held asset today already, which is part of its part of its value proposition, but how do we make sure that those making investment decisions actually um read the relevant information on ETH as a token as its performance uh in their in their same views as that they make their investment decisions. So, yeah, that was basically it. Thank you for for coming here and happy to take any questions if there are any. Yeah, in the back.

Yeah. So, uh it was 7 days decreased to 5 days actually. So, that's again one of the iterative improvements that we want to do. It's 5 days now. Let's see if we can decrease it to three days. uh this is like a lot of coordination that these L2 secure billions and billions of dollars right so it's it's pretty hard uh but it's something that we can do and then the end goal will be to go to proofbased systems so that you don't need to have this foolproof window an interesting thing is base for example has a multi-rover setup where in principle you have the 5 days foolproof window but you can speed it up by submitting a proof and then it goes to a one day and so what we're thinking about for example is can we measure uh the amount of um opportunity cost space of

the capital that's stuck in this uh five minus one day period and if that exceeds some threshold for example like the proving to then submit a proof uh there so yeah we're looking at how we can iteratively improve this until we get to like the the ZK end game there basically yeah cool no other questions yeah thank you so much um and see you