Beam Day Opening Keynote

Transcript

Okay, welcome. Good morning to uh good morning and welcome to to Beam Day. Um it's great to see so many people on a Sunday coming to think about the uh the future of of Ethereum and um yeah, today we have a really really packed day. So yeah, but let's let's get started. What I want to do today is um zoom out a little bit. We're going to have many talks that going to zoom in into specific topics and I want to kind of share some thoughts on the broader strategy because what we have on our hands is an extremely ambitious project to say the least and so we need to have some sort of a plan uh and this is um I guess uh some some of my thinking which

is is still evolving. So in the first part of this talk I'm going to share ideas for strategies that apply for the whole uh beam project and then in the second part I'm going to talk about specific tactics that we can employ for modules of of the beam chain and one of the themes in the tactics is to try and use time as as leverage where things kind of age with like fine wine. Okay. So the the very first strategy is just to keep projecting out. So the mental model that I have here is that we we have the status quo on one end of the

spectrum where we are with Ethereum today and we have the idealized platonic state of Ethereum where you know it it could be if everything was was perfect and in some sense the goal of Ethereum research is to push the state-of-the-art and to try and minimize the delta between what we know is possible and what is actually possible. And one of the realizations in the last few months and years is that maybe this this delta here is very very small. Like more and more we're finding results that are lower bounds basically that prove that there isn't much space to to to improve things.

Um and so you know I have this kind of big dream in some sense to try and and get Ethereum to to the state of the art. And I believe there's an enormous gap here between where we are and where where we could be. And really what the the Beam project is is all about is kind of this this mentality, this attitude that we would start with the state-of-the-art and walk backwards as opposed to starting with where we are and and going forward. So we're trying to minimize path dependence and we're trying to take a fundamentals first principles approach to to things.

And hopefully, you know, at some point we kiss in the middle and Ethereum uh is in a great position. Now, this is a bit of a of a personal slide, but I've been working on many different projects in the last few couple years, and um what I'm trying to do is spend more and more time on on on the beam project. But in order to do that, I need to find ways to delegate these these projects here. And you know, I'm sharing this slide kind of tentatively. But there's there's various people who I'm hoping will be able to champion some of these these efforts here. So we have Drew for the base rollup. Luca, this is shared

confidentially from late to be might be championing native rollups. And we also have Farah in this room who might be championing the the proof project. And so I'm hoping that all of these other projects can be segmented away and I can spend most of my time on on the main shape of it. Now there's a lot of stuff that we can improve in the consensus layer and what I think we should do is try and pick the right battles. We need to basically focus on on the things where we have the most leverage. Now this this is kind of this mental model that I introduced in in um my Devcon talk where there's three buckets of improvements

and each bucket has three meaty improvements. So in the block production uh bucket we have censorship resistance attested firewalling and and shorter slots and one of the amazing outcomes of the last few months is that we actually have EIPs that move in that direction. So the incrementalists are you know very very much excited about improving the block production. We have a fossil EIP you know there was a proposal to include it in Amsterdam. It might go into the H4. We'll see. There's also um EPBS which is an incremental step towards APS that's gaining a lot of momentum

recently especially since Berlin and we also have a proposal to shorten the start times to six seconds. So all of that is things that we want and because others are working on it maybe we don't have to spend that much time on. Another strategic thing that I would not spend much time on is the issuance. The issuance is a very political and sensitive topic and the nice thing is that it is very encapsulated. All of the complexity is in the macroeconomic thinking and then it distills down to just one line of code which is the issuance curve. And so my suggestion is to punt this to after the beam fork

um and and not spend any resources on it right now. And a similar thing could be said with the VDF project which is trying to improve the randomness. By the way, I brought one of the VDF rigs that we manufactured. And um the the reason here is that all of the complexity is encapsulated in the hardware. And again, it's one line of code essentially to to to integrate it into the into the beam chain. So what should we focus on? Well, I would argue that the highest priority is actually this moon math cryptography. both the the quantum security uh for the for the

at the stations and the proposals as well as the stockification of the chain and the good news is that not only is it the highest priority in my opinion but it's where we're making the most progress and I think we should also focus on on the staking including 3SF and rainbow staking and the good news here is that we already have a rich body of literature that have pushed the state of the art and things like 3SF at this point in time are fairly well understood. So what I would do basically is have this strategy where we we anchor ourselves in something of very high quality the postquantum test net. We nail that part of it and then we grow

from that point onwards uh incrementally which is called the beach head strategy. Right? So we establish a beach head with postmontum and then we move our way up to related topics and if we can nail this then I think we'll be in a fantastic position to nail the other things and it's part of the reason why we'll have a round table later today on the postquantum test net. Now another strategy is you know with such a an ambitious project is to to be pragmatic and you know reuse infrastructure where possible and and I this is a slide that I had in devcon there's a lot of infrastructure that we can reuse from from libraries to even like funding infrastructure

and I think we also have an opportunity to to partner with lots of of teams that didn't exist when we were doing the beam chain so we didn't have a devops team, a security team, incentive team, testing team, and networking team. All of that is stuff that didn't exist when we did the beam chain. So, so the beacon chain. So, if we were able to ship the beacon chain without it, and also without all of all of that stuff, all of that basically had to be built, I think we're in a great position uh to to be successful.

Now, one question that I get asked a lot is, do we need nine new consensus layer teams in addition to the six existing ones? Do we need 15 teams? And um I guess there's two parts to my answer here. Like one is that I'm expecting natural consolidation. What historically for the beacon chain we had 10 new teams appear and those consolidated down to five. I'm expecting something similar here. But also what I would encourage is specialization and we're starting to see this. So for example the quadrillion team this they are networking experts and the creators and maintainers of the C++ library. Um and I think it makes sense for them to focus on that as as a

library. Um similar story for Kakarat right they are snarkification experts in the context of Cairo and I think it makes sense for them to focus on just the state transition function and its snarkification and there's all sorts of other opportunities as well for teams to to specialize. So for example, we need to have the postquantum equivalent to BLS. You know, someone needs to write that and that could be a library that is beneficial to all of the teams. And there's also some middleware around having multiclient infrastructure for multi-proving and all of that stuff.

Now, one of the things that has happened recently is there's been a massive reorg at the foundation, specifically when it comes to um the protocol R&D. And we basically have a new captain or new captains, one of which is in this room. And on June 2nd, they basically made this announcement that we have these new strategic objectives. And what that means is that for the short term, for the next 12 months, we have things that we want to do which are scaling DL1, scaling the blobs, and improving UX. And one of the things that you notice here is that the beam chain doesn't fall into any of those short-term priorities. And so what we need to do is just need to be

patient until June 3rd, 2026. And I think at that point, you know, we can start becoming more aggressive. So for a period of a whole year, I think what we need to do is basically put our heads down and and and and and basically do the best work that we can in preparation for the the medium-term future. Now, this is um one of my slides uh from from the the Defcon talk. Um, I would actually argue that is my most hated slide ever because the people complained about how the timelines are so long.

Um, but I think it's I I like this slide. I don't think there's nothing wrong with it. Um, and one of the things that has happened is that the the pilling phase I would argue has successfully ended. Um and and now we have you know these 15 candidate uh beam teams 6 plus 9 that are you know potentially going to be building building clients and now you know we we're very much in the specking phase where we're writing subspecs for different modules and eventually we will produce a full feature complete spec.

But going back to the first point, there's going to be this period of time here where we should not disturb the existing devs, right? Because they have this very important mission around the the short-term strateg not not not too early. Okay, any questions so far? Okay, great. Let me just move on then. So part two tactics. So here what I'd like to do is focus on individual work streams within the the beam project and often times highlight this this this uh nice thing that time

is usually to our advantage that the the the beam project you know spans multiple years three four maybe five years and the fact that we have so many years is actually a structural advantage which I want to highlight. So what is the plan for Poseidon? One of the amazing coincidences is that Shhati 56 and Ketchuk were both eight years old when they were included in Bitcoin and Ethereum respectively. It's kind of a coincidence, but what I'm hoping we can do is basically have a similar story for Payon. The Son is five years old and hopefully over the next three years it will really mature into a very robust and and trusted hash

function and there's like all of these efforts to accelerate this maturation process. So for example in the first half of 2025 alone the Foundation has organized three different cryp analysis workshops at in in in three different locations inviting experts all around the world to try and break these hash functions. And we've also given six different grants to teams around the world to think about breaking this hash function over the next six months. And so I really do think that if nothing happens and no breaks are found then in three years time we will be in a great position and and pose down will have aged by fine wine.

The postquantum cryptography is going very well. And one of the features here is that we have a very modular design with different components and different people working different experts basically working on the different modules. And um one of the the the nice things here is that um we we have designs which are extremely simple and you know in some sense close to optimal. Um, and one of the nice things is that where most of the complexity lies, which is the the the signature aggregation, we're going to benefit from snarks improving over time from the broader industry. So, you know, in the short term, we're we've

started the process of building a minimal ZKVM to snify the u the the attestations recursively. And um you know this ZKPM should improve over time as the state-of-the-art of research also improves. Now one thing that I'm curious to see how it unfolds is the quantum narrative. It seems that every quarter, every six months, the drums get louder and louder and louder as we get quantum computers with more and more cubits and the algorithms improve. One of the amazing things that happened is that last year the state-of-the-art for breaking discrete log was was an algorithm that required about 10 million physical

cubits and then earlier this year that number was brought down to a million physical cubits and now just a few weeks ago we had a new paper which brought it down to 400,000 cubits. So we have the the quantum computers that are increasing in cubits and then the algorithms improving and it's possible that this quantum narrative again is going to age like fine wine to our advantage. Snification the amazing thing here is that all the the industry is just doing the work for us. We can just sit back and relax. This is a ZK the ZKVM tracker uh from Eve proofs. And what's happening is that every week we we get a new tick and a

new green box. And so by the end of this year, basically this whole section of the of the spreadsheet should be essentially completely green. And um we'll be able to reuse all of that super sophisticated ZK VM infrastructure to our advantage without doing any work. And uh we're going to have a talk um this morning u that is going to kind of highlight the fact that this is happening in practice. Um so risk zero is going to basically be announcing that they've managed to snarkify the whole beacon chain as it exists today and that really bodess very well for snarkifying the whole beam chain as well.

Now finality I'd say is also going pretty well. So we have uh a whole team within the firm foundation dedicated to consensus and and finality. Um and what needs to be done? Well, Vitalic wrote this minimal spec which is uh 112 lines of code. We need to do some last mile integrations and we need to do formal verification. And what I think will happen is that here again um time isn't to our advantage in the sense that a lot of the competitive blockchains have much much much much faster finality on the order of seconds. And so you know every year that passes is is one where you know there's more of a desire for for

Ethereum to catch up with with the state of the art rainbow staking. We're going to have a whole talk on this, but the the the basic kind of TLDDR of rainbow staking is that we take validators which are very bundled uh a very bundled role and we unbundled it into into testers, includers and delegators. And one of the advantage of rainbow staking is that for the last three roles, the barrier to entry is extremely low both technically and financially. you only need one one E.

And for the attesters, the plan here is basically to have a capped number of of of attesters because that's limited by the the number of um signatures that we can uh aggregate per slot. And over time through Neielson's law, which is the improvement of of bandwidth 50% per year compounded, we'll be able to increase the number of validators that we support all the way potentially to one one million validators.

So the idea is to basically aggregate a whole million validators signatures uh per per slot. Okay, I already mentioned that block production we have these these three EIPs and basically the plan here is you know just to to make small improvements right if you take EPBS for example in order to get APS you just need to add an auction mechanism which auction you know it could be execution tickets it could be executions auctions it could be execution staking there's there's a whole design space but a lot of the complexity um is basically handled by by EPDS And then for fossil, you know, what I expect will happen is that the beacon

chain will have vanilla fossil and then there's all sorts of improvements that we can add on top like light fossil and and zk fossil if we if we deem that to be valuable. Okay, one of the final slides issuance. So I already mentioned that issuance is a very um delicate topic. Um but I don't think it should be completely forgotten. And the the the thinking that I have here is that this trend here is going to be like a pressure cooker, right? The more stake we have, the more negative externalities that we have and you know more and more is for example, more and

more pressure to have LSTs, um more and more pressure to um to not have if uh you know be be allocated to DeFi things like that and I think that that's going to ultimately lead to a breaking point where the community will say yes we now it's clear to us that we have to change the issuance curve and um the the the tactic here basically is to do all of the preparation necessary so that when this day happens it's just a oneline change of code in order to implement this is change uh within consensus Okay, that's it. Happy to take questions and yeah, looking forward to the the

talks coming up. [Applause] Um, I didn't quite get the part where proposer gave this unbundled version of validator. Um, the proposer will only need to stick one. That's uh Yeah, I'm a bit surprised by that. Could you expand? Yeah. So the way that the unbundling happens for proposers specifically and here I'm talking about execution proposals is APS. So the way APS works is that there's some sort of auction and um so for example execution tickets um you buy tickets ahead of time and then there's some sort of a lottery process

to determine who will be the proposer for that slot. And in order to participate in those auctions, the minimum amount of E required will be some one E. And this is just a very basic den of service uh protection. Yeah. So this is fossil, this is APS and this is dedication which is the standard now for prostic. So with the testers like you said it would start with quite a low number of was it 32k you kind of anticipate 16k.

Yeah. You anticipate we're going to have to massively like reduce the number of testers and kind of gain them back over time and like do you see that being a problem? Uhhuh. Okay. So the good news is that today we only actually have 8,000 operators. So the reason why I kind of think 16k is a good number is because there's a lot of buffer relative to what we have. The bad news is that we don't have consolidation yet. So what I'm hoping will happen is that when we introduce postquantum public keys, the existing validators can specify the same key for all of the validators that they control. So, it's going to be uh basically speeding up consolidation

above and beyond what we're going to see uh with uh with max. Um and yeah the the the main worry that we have basically is that if a very large entity for example Coinbase decides to not consolidate they want to be like maximally adversarial where they split all of their stake into equal size validators that are just at the limit then that could be a denial of service and it could push up the minimum amount of stake to to to be a validator way beyond uh 32 potentially you know closer to a thousand and so what I'm hoping will happen is that in the shorter term

we can rely a little bit on social dynamics whereby you know Coinbase are not trying to be adversarial as we know them today and then over a period of just a few years kind of harden the L1 to reach a million validators and the reason why it grows by four every time here is because The the proposed signature aggregation is a two-step is a two-layer aggregation and when bandwidth grows by a factor of two you actually get a compounding on the two layers. You get a factor of four increase in the total number of signatures that you can aggregate. And so every two years bandwidth doubles. So every two years we should be able to increase by four. And so this is only an

eight-year kind of journey where the only thing that we're doing is increasing just changing one parameter as internet. U there are no aggregators on this slide. Uh do you consider them kind of as part of testers or they justic members that do not have any stakeh? Yeah. So the my mental model for who are the aggregators is that they're primarily a subset of the testers and um specifically my assumption which I think is a reasonable assumption is that 10% of the testers will have the the compute necessary to do the aggregation. So 90%

of our testers can be on Raspberry Pi Picos or on phones or whatever and then 10% can be on a laptop powerful enough to do the aggregation. But I think it would be nice and I think that's the natural design to make the aggregation permissionless so that anyone above and beyond who's not an attesttor can still help with the aggregation altruistically and yeah the way that it would work in terms of selecting the aggregators and you know this is this is something that is good for the devs to be here is that I'm hoping that the default is that you are and so I'm hoping that the way that the clients are built is that When you boot up your client, it tries

to aggregate a thousand signatures, for example, and it times how much how many milliseconds it takes. If it takes less than 100 milliseconds, then you automatically enrolled as an aggregator. If it takes more than 100 milliseconds, then your computer is a bit too slow and we're not going to enroll you as an aggregator. But overall, you won't even notice that you're an aggregator because the the CPU load and whatnot will be tiny. There's been some discussion recently about um provers and their requirements hardware electricity. I'm curious what's the the Drake take on how that will age like fine line too.

Okay, so this is the Drake take um let me go through this in detail. So in 2022, Succinct, the company behind SP1, founded itself over the whole premise of Snockifying Duplic. And what they were doing basically, they wanted to build bridges or whatever, Oracle and whatnot. And what they achieved was using a very very powerful machine like this beefy workstation with a terabyte of RAM or whatever. They achieved to only snarkify the sync committee and they had this this throughput of you know once per clock as opposed to once per slot and they had extremely high latency. Now in 2020 2025 what's happening is that ris

zero who built a ZVM is revisiting this problem that succinct was trying to tackle and this is one of the talks this morning so I won't ruin it but what I'm hoping will happen for the beam chain is that we're going to have everything will be green here meaning that the prover can be a single laptop CPU so a single MacBook CPU will be able to stockify the full chain at every single slot with only one slot of latency, meaning in real time. And so the honesty assumption is extremely low.

We just need one guy in the world who has a laptop who's willing to help out. And and and surely we have enough. And and we can do a similar trick to the testers. We could say, you know, if if your computer is powerful enough to snagify the chain, um, for example, produce proof of a state transition in less than 100 millconds, then you're automatically enrolled. um and you won't even realize that you're generating these first but most of the validators 90% are still assumed to be on extremely weak devices. Um I think this is I don't want to go into a topic that maybe has been Pandora's box and it's talked about many times but I am interested in you still hear a lot of debate on postquantum

about how close quantum really is and uh even I saw recently some people saying that actually a lot of ink spilled for no reason. We maybe don't even need these uh postquantum cryptography uh the quantum computers will have a very hard time breaking these things. So in light of this kind of cloud of this uncertainty, when was postquantum really matter? Like uh how do how do you think about navigating that uh that dynamic, right? Um so I have the the luxury of have so I live in Cambridge and um the father of my son's friend is the founder

of one of the largest quantum companies in the world. Uh and um you know I get I get to pick his brain and yes he he does confirm with me that like a lot of the headlines uh are you know just fluff. Um, but he also very much acknowledges that there is a lot of real stuff and he's actually extremely bullish, maybe also because he's biased on the on on the future of quantum. Um, now I guess my take regardless of the technology is that the the narrative, the FUD is going to play to to our advantage. Uh, whatever happens. Another thought that I have is that it's going to take a very long time

for you know the the operators to move to postquantum. So we need to plan for this for for this transition period. The way that I envision doing it is basically we have a hard fork where we allow the validators to specify a postquantum key and then there's a period of time for example one year where they specify their key and then at the at the end of the year whenever the the beam activates only the subset of validators that have migrated over uh would would uh would be involved as as as being validators and we want to make sure that this number is high enough at 80% or 90%. So we might have to wait even more even more than than one year.

Um the other thing that I'll say going back to the narrative is that we're starting to see it with Bitcoin. So for example uh recently Black Rockck had this uh addition to the ETF perspectus. Um and this is you know something I I can share like um you know the cryptography team for example had a call recently with Black Rockck right just to explain to them what is the situation on Ethereum and you know even though even if the fundamentals of quantum are still you know maybe a decade out or maybe 15 years out um the narrative is just going to get louder and louder and louder and

I I think we we need to as a as because Ethereum sells security. Uh I think the only reasonable approach here is to be maximally conservative and I just wonder if everything so fast, how do you see process? Yeah, great question. Um yeah so the okay um the the way that I would tackle the spec writing is the divide and conquer right so I would start with subspecs for individual modules we already have a subspec for 3sf written

by metallic we already have a subspec for you know one of the most complicated pieces which is the the aggregation of signatures by um I want to see just all of the subspecess uh uh kind of uh written out and and and full modules like for example the postmount module being uh the combination of multiple subspects and then from a timing perspective what I would do is basically only put the pieces of the puzzles together once um sorry yeah once we're no longer at the do not disturb the devs uh thing because what

will happen, I expect, is that once we make a big announcement saying, "Hey, we have a fully featured uh spec, there's going to be FOMO and then, you know, all of the teams will want to be one of the first to to implement and we don't want that to be disruptive to the short-term objective of scaling the L1, scaling the L2, and improving improving UX. So, yeah, it's it's it's a little bit of a of a political and tactical uh balancing act. Why do you think you should not disturb the data as opposed to having them engage on?

Uhhuh. Yes. Okay. Yeah. So the mental model that I have is that it's 10 to 100 times less expensive to do research and to provide feedback than it is to write code. And we kind of saw this historically with the beam spec where sorry with the beacon spec where the researchers would whip out a new spec every month. And then the poor developers, you know, they had spent six months implementing it and now they have to to restart from scratch. And so I think we should have the devs be engaged using this lightweight feedback mechanism, but we should not have them write a single line of code. Like all of the code that they write should be on

the the current in your slide about like going to like a laptop CPU. Why is it a CPU? Why can't you just do a GPU on a laptop? Because if a CPU is possible, why not do a CPU? And like back of the envelope suggest that CPU is fine. Um, so a single CPU today can do two million per side on two hashes per second. the the beam chain to traditional function is just essentially just signature verification and it's way way less than two million. So like the ideal outcome is actually maybe like 10% of a CPU should be enough to startify the whole game.

Okay, thank you so much for the questions. Next up we have Dimmitri from the Foundation. [Applause]