Keynote: [title redacted] by Justin Drake | Devcon SEA

[Music] I'll do better so the the weight is almost over the thing that I've been working about on for almost all of this year is called the beam chain so so the beam chain is a proposed redesign of the consens layer that incorporates all of the latest and greatest ideas from the research road map and the goal is to try and transition in a safe and fast manner from the beacon chain that we have today to this beam chain which is much much closer to the final design of ethereum now before I share more information I have two disclosers um disclaimers disclaimer number one one is that this is just a proposal this is my proposal and the proposal will only go forward if there is rough consensus with it going forward and the second disclaimer is that there is no new token there is no new network and we're reusing the same ticker and vitalic was very very clear as to what this ticker is now I in in the rest of this talk I want to take what may sound like a totally crazy crazy idea and convince you that actually it's maybe not so crazy that it might be a reasonable proposal to put on the table to completely redesign the consensus layer and first I want to tell you a little bit more about the beam chain and what the big picture vision is all about so the scope of the beam chain is specifically the consensus layer and I'm excluding the data layer with the blobs and the execution layer with the evm and the reason is is that the blobs and the evm are directly consumed by applications and there is a need to be forward compatible and so the the um the opportunity to modify these two layers is rather limited on the other hand the consensus layer is not directly consumed by applications and so there's a big opportunity to shake things up a little bit there now why am I proposing now to do this massive red design of the consensus layer and it basically boils down to the fact that the beacon chain is kind of old the the spec uh was frozen 5 years ago and in those five years so much has happened in particular we have a much better understanding of me five years ago we were extremely naive when it comes to me and since then we've seen the market really Blossom and and and and and grow and we also have uh a much better understanding of mechanisms that can help us mitigate the the negative externalities of me secondly from an engineering standpoint we have this wonderfully powerful technology called snarks where there's been plenty of breakthroughs in particular we've seen snars become olders of magnitude faster over the last five years and we've seen the Advent of ZK VMS ZK VMS are amazing technology that allows any program in the world to make use use of this very powerful technology without having to be an expert in cryptography or in SNS and then finally with the benefit of the of hindsight we now know what the mistakes we made with the beacon chain and we have a bunch of technical debt which is extremely sticky and tends to Pyon over time and maybe now we have an opportunity to clear this technical debt so I'm Sugg testing putting the greatest and latest of the consensus layer road map in the beam chain so I guess it might be worth spending a little bit of time looking at what exactly is in the consensus layer road map there's basically nine different items and I've categorized them in three different buckets block production staking and cryptography so the block production has to do with me right now we have a lot of centralization at the Builder and relay level and one of the things that we want to do is have inclusion lists that dramatically improve sensorship resistance once we have censorship resistance with inclusion list we'll be in a position where we can cleanly decouple the validators From the Block production Pipeline and this is called a tester proposer separation and there's ideas like execution auctions and then the final uh item here in the block production bucket is faster slots maybe we can take the 12C slots that we have right now and Shrink them all while preserving the invariant that if you are on a home internet connection you can participate as a validator as a first class citizen even if you are in Australia with a high latency internet connection second bucket is staking the researchers I think have come to consensus broadly speaking that the current issuance curve is kind of broken and that there is an opportunity to improve the health and long-term outcomes of eum by changing it uh the second uh item in the road map here under the staking bucket is this idea of dramatically reducing the total amount of e to become a validator from 32 e down to just one e and there's ideas like orbit that have that have been circulating around recently and then finally this is an idea that has happened that has been talked about for many years is single slot finality can we dramatically accelerate the process of ethereum gaining finality and then the final bucket has two big ticket items number one can we snarfy the whole of the be the the the consensus layer in real time using reasonable hardware and then finally can we make the cryptography that is securing ethereum sustain aable for the next decades and centuries and make it post Quantum secure now the coloring here is meant to suggest whether or not the item in the road map can be done easily incrementally or or or whether it can't so the five sorry the the the four green items here in the top left corner are items that I think can be done and should be done in incremental Forks on the beacon chain but then when we get rid of those we we're left with big ticket items the red items that I would argue are best done in a more holistic way so take chain SN ification for example in order to achieve realtime proving of the beacon chain with reasonable Hardware we're going to need to change the hash functions we're going to need to change the signatures the way that we serialize and meriz the state and this is a mass massive change to the uh to to to the beacon chain and so maybe there's an opportunity while if if we were to make such a change to change other things at the same time and then a similar thing can be said for the bottom two red um boxes faster slots and faster finality the truth is that 5 years ago our mindset was Security First when we designed the the beacon chain and performance was not really a main consideration and with the benefit of hindsight we found that there are designs that preserve all of the security that we want and at the same time pick some of the lwh hanging fruit that is available to us to improve performance okay so this slide here is trying to show the mapping from the consensus laer road map that I showed you and thealex broader road map we have some items that are classified on the emerge some that are under the scourge and then a couple that are under the Verge and the splurge and the whole point of this slide is to communicate the fact that the beam chain is not about changing the road map more so than it is about identifying a specific subset of that road map and accelerating it and putting a mimetic wrapper around it now one thing that is new uh in in in the uh consensus layer road map here is the fastest slots and the reason is that the discussion around fastest slots has happened this year in 2024 but thealex road map diagram was only last updated in 2023 now in addition to being able to potentially accelerate these big ticket items there's a lot of technical debt that I mentioned that can be clear cleared out if we have single slot finality we no longer need EPO we can just have slots um the the deposit contract that we have right now is kind of crazy and it's it's a remnant of of the merge and things like the sync committee is infrastructure that we won't need going forward if we have real time real time SN ification of the beacon chain and the list goes on and on and on and this is an opportunity as as I mentioned to just clean it up all in one go and you if you're interested in learning more about some of these uh Beacon chain mistakes last year I did a whole talk where I I talked about 20 or so different mistakes that we made in the beacon chain design okay so this is the big picture view of how we have done upgrades to the consensus layer since Genesis so in the bottom left here you can see we did Genesis in 2020 and since then it's been an extremely regular pattern every single year we've had a new fork and every time we had a fork we made one incremental change to the consensus layer so in 2021 we added sync committees in 2022 we did the merge in 2023 we added withdrawals and then Proto um Proto dang sharding and and soon in 2025 we're going to increase the the the max effect effective balance now what I expect will happen is that over the coming years we will continue doing these incremental Forks um and we will be picking up the low hanging fruit um that that that was marked as green bubbles in the in the road map in the top left corner of the road map but then we're going to kind of hit a wall and the reason is that once we've picked all of the low hanging fruits we'll be left with all of the big ticket items that are much more difficult to do in an incremental fashion and this is where the beam Fork happened the beam Fork is an opportunity to have a Quantum Leap Forward in terms of upgrading the consensus layer all in one go and one way to think about the the the beam Fork is as a batching opportunity we're batching multiple upgrades into one one single fork and this has benefits both technically and from a governance standpoint and one way to think about this batching opportunity is as oifc accelerationism this might sound like an oxymoron but the basic idea is that we want ethereum to go in maintenance mode as soon as possible and right now there's this tension because we know that there's these big ticket items that require a fundamental rearchitecturing of of ethereum and the more we drag it along the further ethereum will be in a position where it can comfortably aify okay part two I want to try and highlight some of the technology that is that is going into the the proposed uh beam chain and the way that I would frame this is basically in erors of ethereum consensus initially we had the proof of work era of ethereum consensus and then we moved to proof of stake and now we're potentially entering this ZK era of fum consensus and in this ZK era we would be making heavy heavy use of SNS as a technology so one place where we' be making use of snars is snar ifying the entire beam chain the entire consensus layer and this is where the ZK VMS become extremely extremely handy so imagine that you have implementations of the beam chain in various highlevel languages in Rust in go for example what you can do is compile these highle languages down to bite code that the Z kvms will understand and get SN ification without having to worry about the details of the SN ification process now one thing that I do want to highlight is that the only part that needs to be snar ified is What's called the state transition function which is basically the crystalline core of what it means to be a consensus client all of the infrastructure surrounding the state transition function for example the networking or the syncing or you know the the caching optimizations or the fork Choice rule none of that has to be snar ified and ultimately the state transition function is a small subset of what it takes to build a client and what we've seen recently in the last couple years is risk five become the de facto industry standard for these ZK VMS so risk five is an instruction set and basically you can take highle code and compile it down to risk 5 and we've seen seven different uh companies provide these risk 5 zkv Ms you may have heard of risk zero and sp1 and the list goes on and on now one little side note here is that this exact M technology which is extremely powerful can also be used at the ex execution layer for the evm but that is a completely different story to the beam chain story it's one which is extremely exciting because it means that we can dramatically increase the gas limit as well as vertically scale eum layer one but this is going to have to be for a different talk the other place where we make heavy use of snars in the beam chain is with uh aggregatable signatures we want to have postquantum aggregatable signatures and the proposal here is to use hash functions hash functions are postquantum secure and you can use that as a basic building block to build your cryptography so we would have hash based signatures that are produced by the validators by the ATT testers and we would also have hash based SNS where you can take many many thousands of signatures and compress them down to just one proof and with these two combined you get a hash-based post Quantum aggregatable scheme that could be used for ethereum and one little nice detail is that this aggregatable scheme is infinitely recursively agre aggregatable so you can take Aggregates of Aggregates of Aggregates which is something that we can't really do today with BLS so it's much more flexible and the reason why I have this proposal here today is because in the last few months the progress in per performance of snar ifying hash functions has gone through the absolute roof so for those who are in the know we're now able to prove on a laptop so this Benchmark here was done on a laptop CPU a MacBook Pro we're now able to prove 2 million hashes per second which is an astounding amount of hashes per second and this means that this hash based proposal has the potential of being extremely performant for the beam chain now in addition to the ZK the very powerful Z kvms and snars that we would be using I also want to highlight that to a large extent we would also be reusing existing infrastructure so the networking libraries lip P2P the serialization libraries simple serialize all of that can be reused as is today same thing for the ppec PC is the the the framework that we use to write the formal specification sorry the um the python specification and and the unit test and we can also reuse protocal Guild all of which is infrastructure that didn't really exist when we started with the beacon chain and the same thing can be said about teams when we started the process of the beacon chain there was no team there was no consensus client teams so the five consensus client teams that we have today this is Manpower that that could can be reused and doesn't have to be rebuilt and in addition to that we have dedicated teams that will put in place for the merge for example e panda Ops which does Dev Ops and the security team within the foundation and I also want to give a shout out to the incentives team and to the applied research Group which are also teams that all of this infrastructure didn't exist and we can just reuse it for free okay final part is so here I want to try and highlight some of the next steps and how I see the the future so one possible outcome here is that starting from 2025 we start the the the specking process so this would be something that a small group of researchers would would do uh and it would take maybe a whole year and then in 2026 the building process can happen where clients would start writing production grade code and then in 2027 would start an extremely thorough testing process to make sure that this is all production grade and safe to deploy on mainnet now the next step for me as a researcher would be to start writing the executable spec which I call the executable road map and the idea is to take the pixels that we have of the road map combined with the the hundreds of thousands of words that have been written on E research and in academic papers as well as all of the ideas that lie in the the minds of researchers combine all of this and extract The Core Essence which would be this executable spec and ultimately it would be a very small document roughly 1,000 lines of python code now one exciting thing for me here is that the beam chain assuming that there is rough consensus to go in this new direction would be a fantastic onboarding opportunity to bring fresh blood into the space especially for the consensus clients so today we have consensus clients in North America in Europe in O Oceania and I'm very pleased to be able to announce today that we have already new consensus client teams that are willing to build beam clients so we have one which is based in India which is called the Z team this is a beam clients written in Zig and then we have Lambda class in South America that has signaled an interest to also write a beam client and so if you want also get involved and we're going to need a lot of excellent Talent we're going to need speckers and networking experts and coordinators and cryptographic experts and and client devs please reach out at this email address and beam up with us on this new adventure thank you so [Applause] much right let's hear one more time come on a bigger round of applause that was a fantastic presentation really really good really appreciate it and I'm sure the audience appreciated it as well now now is the time to ask your questions or if you see an interesting question pleasee up vote it now for those of you in the hall don't leave yet okay just give us some time because the volunteers need to clear a bit of the space there are still a lot of people outside so at the end of Q&A don't move stay where you are because our volunteers need time to clear the hall later okay so just stay where you are and I'll instruct you at the end of Q&A all right Justin let's look at the first question with the five votes right on top deploying many changes at once is risky in that if any one change gets delayed or has a bug they all get stuck or roll back how hard have you tried to break them down in incremental batches okay great question so there's many things that I've tried to do to try and drisk the beam chain the first one is to encourage all of the incremental upgrades remember the four green items in the road map that could be done ahead of time and by going through the process of these incremental upgrades we're going to go through a lot lot of the of the lessons and a lot of the hard work and discover the challenges there and then um the other thing that I'll mention is that the beam chain is really only about changing the core of the client which is the state transition function and a lot of the the potential opportunity for bugs whether it's a networking layer or the merization libraries or you know the fork Choice rule a lot of that infrastructure can to a large extent be reused another thing that I want to do to drisk the beam chain is make sure that all of the existing clients are on board because ultimately these are you know 50 men and women that have many many years of experience building consensus clients and they know what a lot of these pitfalls are and then another thing that I would say in terms of drisking the beam chain is that we would have an an especially intensive testing period which could last for example a couple years this is what I had in the strong man timeline and during that time we would do many many rehearsals on Def Nets and test Nets so that we could grow confidence that there isn't a bug in this big upgrade excellent thank you for the answer indeed testing is very essential when it comes to the blockchain and updates now the question that I've seen has gotten the most votes of any of the room so far 20 is the number to beat are you okay Justin with people calling this ethereum 3.0 the meme layer of ethereum wants to do this okay great question so in my opinion the moniker airm 3.0 is not appropriate and the reason is that the beam chain is only about the consensus layer it's not about all of the firm layer one it's just a consensus layer excludes the data layer D sharding and it also excludes the evm and there's lots of exciting stuff happening at these layers of the stack as well so this is why I've tried to avoid the etherum 3.0 monik all right I mean it's a fair Fair answer as well but people will do what people do best and they'll call it ethereum 3.0 and we'll get a few new coins and people ask all the exchanges will my ethereum change and all of that um but let's go to the next highest voted question which ZK VM will be used for beam chain as there's no standardization of ZK VMS okay fantastic question so the amazing thing about the proposed design and actually this is an idea from vitalic is that the snar ification would happen off chain and would not be enshrined in consensus so what that means is that every independent validator can choose which ZK VM they prefer so they can use any of the seven risk 5 ZK VMS but they can also use non-risk 5 Z kvms and ultimately by having this offchain SN ification it means that if there's a bug in one of them it's very easy to fix if there is a performance optimization and one of them you just update your client and you get this this performance optimization and also it means that we don't have to pick winners and we don't have to add a lot of complexity on chain all of this is offchain complexity at the social layer all right thank you we got 30 seconds you want to take the last question at the top any way to accelerate that timeline oh we moved uh okay okay okay well let's take the first well okay they voted for 18 19 okay let's do that one why are e researchers obsessed with lowering issuance it's come on guys we need the da to agree consensus where is the consens okay Justin take whichever question you want okay I'm happy to answer all of the questions later on outside but um any way to accelerate that timeline please email us at beam.

chain aim.org if you want to accelerate let's go all right ladies genten