Is Beam Chain Good For Ethereum? With Justin Drake
18 Nov 2024 · 1:00:41
Andy and Robbie Klages of The Rollup sit down with Justin Drake in Bangkok to unpack Beam Chain, his proposal for a major consensus-layer hard fork aimed at accelerating Ethereum's roadmap. The conversation covers single-slot finality, programmable execution sharding, and using zk-SNARKs and zkVMs to snarkify the consensus layer, along with the debate over ossifying Ethereum versus continuing rapid iteration.
Speakers
Topics
Transcript
you know some of the feedback that we got on Twitter is that it's not ambitious enough yeah they want to make ethereum ambitious again how do we prevent commoditizing what we falsified and then the builders just like polished it a little bit around the like Max Resnik are saying we should be ending for one second okay yeah so there there's a lot to unpack here welcome in from from Thailand from bangok uh here today with Justin Drake a just a couple short hours after his presentation about chain Justin welcome in um and how are you feeling after your presentation hey thanks for having me guys um so yes um I was really hyped up for the presentation yesterday you know I've worked really hard to try and get some sort of a
proposal that uh people feel comfortable internally within the the researchers and the devs and uh the room was absolutely fully packed and people couldn't come in I was told there were hundreds of people who couldn't come in uh who had to to to watch it online um a lot of people have sent me you know personal messages saying that they're very excited uh we now have new Beam Team clients so um in addition to uh to the Z client and to the Lambda class client uh we have the never mind folks for example who are interested and a bunch of people sent me emails to beam.
chain e.org uh you know all sorts of skill sets uh some some researchers some developers um some networking people and so now really what I want to do is let the dust settle and incorporate as much feedback as I can in The Proposal because ultimately this is just a proposal this is the beginning of a potential accelerationist Journey for the eum road map and um you know some of the feedback that we got on Twitter is that it's not ambitious enough yeah they want to make ethereum ambitious again which is kind of crazy because um you know what I'm suggesting for the specific subset of the road map is extremely ambitious but I think maybe
what we need to do is zoom out and look at the big picture because people want things to change now like next year or this year even um and I think there's there are things to to look forward to that will be shipped incrementally uh in addition to what I'm proposing which is this kind of this big fork which would happen in four years or so yeah I I think that incremental uh hard Fork would only get us so far and that's sort of what the timeline and the road map is set out to be right now and so to people for people that are claiming that it's not ambitious enough this is actually chunking up a lot of that road map and going at it in one in one shot and that's quite ambitious at least more ambitious than the current
road map yeah so when you look at the etherum layer one it's has three sub layers it has the consensus sub layer the data sublayer with Dank shotting and it has the execution sublayer with the evm now I think the basically part of the confusion was that I only focus on the consensus layer which is in some sense the most you know conservative and slow and ambitious part of the road map but there's going to be gains happening at the data layer and the execution layer relatively soon so for example at the data layer right the Mandate is basically to to to ship full DK Shing as quickly as possible and we're going to
incrementally get there with steps like P and basically increase the number of blobs um and you know my personal extremely bullish take is that we're going to go way above and beyond what full Dan shouting is advertised as and the reason is that internet bandwidth just grows over time 50% per year that's neon's law and we're not going to get you know 128 or 256 blobs I think we're going to get 1,24 blobs per slot eventually um but yeah it's going to be a whole uh progression over over the years and then at the execution layer one of the things that I'm extremely excited about and I think the community is also getting really excited about is this notion of SN ifying the evm having
ZK EVMS and ultimately having native rollups and um the amazing thing that we have right now is a very vibrant ecosystem of zkv Ms this is something I highlighted in my talk we have maybe 10 or so ZK VMS the vast majority seven of them are risk five ZK VMS but there's also non-risk 5 ZK VMS there's like mips there's there's Cairo and there's all sorts of others like like valida and ultimately what's going to happen in my opinion is that next year by the end of next year we're going to have the EV L1 evm fully snfi really so what does that mean it means that for every single block we're going to have a proof which
is going to be Genera by some subset of these vendors and one piece of alpha here is that uh the foundation has been working for several months on a new website e proofs. org is not live yet but I think it's worth sharing the basic idea is to have a block Explorer for evm proofs so that every single slot you have a block and then you would have all of the proofs of validity from all of the various vendors so we're partnering with um risk zero and sp1 kind of as launch launch partner for this website and the idea is that for every single proof that's generated we have um you know metadata like how much how many seconds it took to generate the proof
and two how many cents did it take to generate the proof and what I think will happen is that many of the vendors purely as a marketing expense will be willing to you know snakify the whole of the L1 just to be on the website and compete on the leader board that is some Alpha and and uh one thing that vitalic said in his Crypt panel yesterday was that he thinks that the that that the terminology of zero knowledge and snarks is going to slowly just kind of uh fade away and we'll just stick to the word proof while there are technological implementation details that are important to understand between the types of zero knowledge proofs this also kind of uh overlays into this broader new uh new site and new data dashboard right so to a very large extent the word
ZK has lost its original meaning of zero knowledge it's the royal DK which basically stands for all of advanced cryptography uh that we are consuming and accelerating within the context of of ethereum and to a very large extent that's going to be snars which is basically just proofs um but the the memetics of ZK are pretty strong you know it's like a very short term and um I think it's okay if we just change the meaning and have this understanding is just a royal ZK and we'll see what sticks um you know people have tried to change for example ZK rollups to validity rollups and that hasn't really worked out I mean proof rollups doesn't
sound too good um so I'm still personally bullish on the memetics of ZK but of course I agree with italic that ultimately it's about fancy cryptography which ultimately itself is about proving statements about and and the EF has invested quite a bit into ZK and this entire ecosystem has has invested quite a bit into ZK and 100% yes and you know this is part of this larger bigger picture shift uh and you laid this out in your presentation from proof of work to proof of stake and then now into ZK and so kind of walk us through this this evolution of ethereum this is what and you mentioned mimics and people are calling this ethereum 3.0 so kind of
walk us through the mics of this that was David huffin right there that was his question right um so I I do want to kind of linger a little bit on you know all of the Investments that that we've made because I want to highlight a few things one is that we've recently started a $20 million formal verification program we did a podcast with Alexander Hicks and all the way through this that was a great uh episode go listen to it uh and basically this is closely tied to the ZK VM story um and there's going to be a lot of for modification of the risk five circuits for example that that that are being done another thing that I want to emphasize is that a very large portion of the eum foundation is basically this team called psse
um it has an extremely large it's the largest team in all of different foundations what P stands for uh it stands for privacy and scaling Explorations so it's basically SNS the Privacy part of snars and the scaling part of SNS um and they've gone down all sorts of directions and they themselves have a ZK VM team within psse and they were one of the the Pioneers that started to snarfy the evm way back when we didn't even have you know this new direction of of of ZK VMS and you know again like there's this e proof website that will go and accelerate the the SN proofing the good news is that I think we can release the pedal a little bit on accelerating it because the whole ecosystem is funding it you know there's
these companies probably have combined hundreds of millions of dollars of VC funding I mean I just checked this morning sp1 received so sueding the company behind sp1 received 55 million in one of their latest rounds um so this is amazing accelerationism I think what we need to focus on you know at DM Foundation is maybe things like standardization public goods like standardization and and form more verification because those teams want to ship as fast as possible they want to be number one and you know security sometimes might be a lagging thing uh relative to to actually shipping now to your actual question around you know this transition from proof of work to proof of stake to ZK um you know it's a little bit of an exaggeration in the
sense that it's still proof of stake but it's kind of Pro proof of Stak Plus+ where we make use of this really powerful technology which is snars and the idea is to make use of it in a couple places place number one is to snarfy the entirety of a feum let's snakify it all um and that includes SN ifying the consensus layer and the the evm so what does that give us it gives us several things the first thing is that any entity that is consuming the ethereum chain can do so with extremely low resources think uh a mobile phone or Smartwatch basically you're just
verifying a single proof and that allows you to sync to the tip of the chain and to know that this is a valid chain so if you're a user for example using metamask right now you're trusting in fura to tell you what is the state of the chain you won't have to do that in the future if you want to build if you're consuming the FM chain for example on from a a smart contract in another L1 and you want to build these trusted trustless Bridges then again you can make use of that if you're a validator you need to be synced up at the tip of the chain and basically the vision is that the validators can just run on their smart watches in the future so we're dramatically lowering the barrier to entry to becoming a solo validator yeah um and then the kind of the final
amazing thing about SN ifying things is that we can enshrine the SN ification of ethereum within itself okay that sounds a little crazy that sounds interesting can we have the smooth brain um explanation here the smooth brain explanation is that there's going to be a ZK VM pre-compile so that if you want to launch a ZK rollup within ethereum it's a one line of code right so there's this notion of programmable execution Shing so previously way back when 5 years ago in the road map we had execution shouting what is that it's basically 64 or, 24 copies of the evm exact copies and they would each have
their notion of state and they would each kind of grow asynchronously relative to each other now we have a so much better road map and it's it's basically synchronous programmable execution shouting so let me go through like all of the terms the first one which is maybe the most important is programing able so instead of being limited to just 64 or, 24 shards programmers around the world can just deploy as many copies of the evm as they want so that is horizontal scaling of the the L1 evm and for them not only do they have the convenience of just having one single line of code to deploy an evm ZK rollup but they can also have the
privilege of not having any bugs they don't have to worry about that and they don't have to worry about governance whenever the evm changes right because the evm is a is a living being there's new up codes that are added or the gas schedule changes and all of those changes will be immediately reflected in this in in this pre-compile um another amazing thing about the the the the ZK evm pre-compile is that it it the the gas limit can be set arbitrarily High and the reason is that the validators that would be verifying the the state transition function within the evm they only have to verify SNS and those you know it just it's a
constant amount of time it takes say 1 millisecond to verify an arbitr large amount of of State Transitions and so what I expect will happen is that we can take what is currently the 30 million gas limit on L1 and increase that maybe 10x maybe 100x but then the programmable um shards can just go completely crazy and remove the gas limit entirely what on our last podcast we talked about base the L2 and we talked about how the we talked about the relationship between me and contention fees versus their congestion fees and there's a lot of back and forth but basically we we came to the conclusion that the reason they don't have much fees due to congestion is because they just keep raising their
gas limit yes and and that's why 80% of their fees come from meev and contention yes and so now we're going to raise the gas limit and kind of remove the need for congestion on the evm is that the right way to think about this so one mental model is that previously the bottleneck was on the validator side of things the validators are kind of assumed to be very weak they're like raspberry pies on home internet connections and there's only so much they can do but with snarks we're basically removing this Boton neck on the validator side of things and now the botton neck is going to be on the Builder Andover side of things ah so unfortunately you know you take any virtual machine just because of the you
know the laws of physics it can only process has so many transactions per second you know we're going to max out the number of transactions per second I think um uh what is this project um that that is trying to go to 100,000 transactions per second um mega yeah Mega rise and other some yeah so there's a lot of projects out there that are really trying to push the number of transaction and let's say that the ultimate ultimate is like a million transaction transaction per seconds then what's going to happen is that the effective gas limit is going to be dictated by this the laws of physics and then now we're going to create a a you know a fee Market within within that context and ultimately it's going to be the the builders and the provs that have
to deal with you know maybe large amount of state or large amounts of computation yeah yeah and I think uh in addition to the to the broader uh consensus L1 changes from that are impacted from snark ification it also is very applicable to l2s uh which kind of ties into another aspect of beam which is faster finality effectively and uh and kind of improving the L1 uh from from that perspective and one kind of core issue for l2s right now is interoperability between l2s is very problematic from a perspective of security because the the only way to do it completely verifiably is to wait for the L1 to uh for a block to be confirmed and then eventually finalize which takes
12 seconds and then 12 to 18 minutes so how does this snark ification of the L1 in combination with the kind of further rhetoric of uh improving the finality how does that kind of all tie together to build this broader more stronger rollup Centric future right so one one one of the issues is that um the the l2s today basically are using the L1 as a as a mechanism to force include transactions and basically the one of the the worst cases for them is that um you know the L1 kind of tells them to force include some transactions and then they force include them and then the L1 rugs them and reorgs and tells them to force
include different transactions that are inconsistent and so now the L2 itself which thought that it had finalized can't finalize and so what happens in practice is that the chains will just wait for enough confirmation or even finality before they're comfortable processing the the the the force transactions and single slot finality basically dramatically reduces that now one of the things that I want to emphasize is um single SL finality is a little bit of a misnomer and the reason is that from a throughput standpoint yes every single block you finalize every single slot you're finalizing a new block so the frut is one block per slot but the latency is actually three slots
and the reason is that fundamentally the process of achieving finality is kind of a couple rounds of interaction um and so you know there will still be like this little tip of the chain which won't be finalized now one of the things that I'm a PR proponent of is this notion of Base rollups where basically you're synchronizing the forced inclusion and the default sequencing mechanism so if if one reorgs the other automatically reorgs and everything stays safe so this is one you know potential path forward to solve this problem of the L1 reorg and all of the complications with the forced inclusion log got it um one of the things that that we're talking about here is is snark
ification and then and then you know there is this movement to enshrine these elements into the L1 um kind of part of the role of centric road map was to to actually push a lot of that into L2 and not do a lot of enshrining and so what has been the philosophy as to like what to enshrine and then what to push off into the l2s yeah so the ultimate philosophy of a f I think is you want to be maximally simple and still provide the basing building blocks that people can program around and so I think the move from uh execution Shing to programmable execution Shing is very much in that direction I mean the programmability allows for these rollups to have custom sequences and governance tokens and fee
tokens and all of the infrastructure Around It ultimately the virtual machine is just a you know piece of technology that will get uh commoditized now we can actually go one level further and this is something that I'm really excited about about which is to to boost the programmability by not enshrining the evm itself but enshrining a ZK VM underneath it and specifically risk 5 so you could imagine that instead of having a ZK evm pre-compile we have a ZK risk 5 pre-compile um and the the idea here is that the evm would just be basically a risk five program bite code um that would be interpreted in real
time by the actual native virtual machine which would be risk 5 and risk 5 is much much more lower level you can think of it as being a CPU and actually it is manufactured as a CPU uh in in in um in various computers today uh and one of the really kind of cool things about using risk 5 as the underlying virtual machine that we would enshrine is that the there would be no more uh bike shedding around the gas schedule and the reason is that we could just have one gas be one cycle of a risk five CPU got it okay so now that we've so in this in this practical world that that we start to implement beam chain uh or at least like the specs that you have laid
out one of the core ones was the reduction of the slot time and as well as single slot finality how did you get to the mental model of okay rather than the current 12C block time we should basically divide this by three get a 4 second block times three three of these in one block per se um how does that like why did you come to that exact uh that exact like figure because a lot of other folks in the ethereum community or at least some prominent ones um like Max Resnik are saying we we should be aiming for one second uh block times okay so there's many different thoughts that I have here the first one is that I think a lot of uh to a large extent the L1 slot time is not as important as people
spin it out to be people like back wrestling for example and the part of the reason is that we Notions called preon right and this is you starting to become the de facto standard you know we have the arbitrum that has 250 millisecond pre-confirmation we have the the the super chain that has two two seconds pre-confirmation and even base rollups are getting pre-confirmation and ultimately I think the the end game for pre-confirmation is is zero milliseconds so the slot time is basically zero and the only or call it 1 millisecond let's say okay and then from the perspective of the user the only latency is one ping time okay right it's the time it takes to reach the the sequencer and back and that that is optimal so with
pre-confirmation I think to a very large extent the problem of long slot times moves away but for for base prec confirmation specifically there is this one problem which is that you know some percentage of the time it might be 0.1% it might be 1% or it might be 5% I don't know um like the validator like might be offline or whatever it is and then basically pre-confirmation skip a beat so for a whole slot you don't have pre-c confirmations and that is a bad ux um I mean arguably you know this is something that we experience on the internet every day you know I'm traveling around Bangkok and then you know sometimes the internet connection is not so great and it takes 4 seconds to load my web page and you know my life goes on and it's fine but most of the time let's say 95%
of the time it just loads within 100 milliseconds so I think uh that's one consideration and basically REM reducing the slot time down to to 4 seconds is really just about reducing this worst case thing that would only happen like a small percentage of the time now to answer your actual question about why 4 seconds as opposed to 12 seconds well basically what happened historically is that 12 seconds was picked to be extremely conservative uh it was picked to be very close for example to the exist the previous slot time which was 13 seconds um so we wouldn't necessarily be accelerating the evm that much uh that much more but what needs to happen in a single slot is basically a round of attestations what does that mean it
means that some subset of the validators need to make signatures these signatures need to be gossiped and then they need to be aggregated and included on chain and what we realized is that you know with the constraints of ethereum we can probably safely bring the slot time down to 4 seconds now the important thing here is is with the constraints of ethereum right ethereum is a very unique project uh that is trying to be extremely secure extremely credibly neutral and extremely robust and two of the big requirements that we have are number one if you have a home internet connection with high latency in Australia then you should still be able
to participate right uh and then the other big constraint is that we want to have extremely high amounts of validators and economic security and we want to be aggregating you know tens of thousands of signatures per slot and this is an extremely ambitious thing to do from an engineering perspective right imagine taking tens of thousands of messages that get gossiped around aggregating all of that in just a matter of seconds so one of the things that I actually want to drisk at at the very beginning of kind of this this this journey is is precisely that how how can we aggregate all of these data stations as quickly as possible because Ely what is consensus is just a a fancy mechanism to count
votes one of the things that you mentioned in your presentation and also vitalik mentioned and sort of this possibilities of the ethereum road map and the merge is a tester proposer separation and and so kind of you know you're mentioning aggregating a bunch of signat uh signatures together and like kind of attesting to that that's what happens when we produce blocks like how does that mechanism change in a tester proposer separation so it it doesn't change it's kind of when you're validator today you have two different roles role number one is that you're an attester which is that you're basically voting on the tip of the chain on a regular basis and then there's a completely different role which is called proposing where you basically propose a new block on chain at tester propos a separation as the
name suggests is that it's basically completely decoupling these two roles instead of being bundled as as the role of the validator they're unbundled and instead basically the expectation is that the validators are only doing the attesting and the proposing comes from the The Wider market so basically there is an auction which is actually in some sense more permissionless than it currently is because you don't even have to have stake anyone around the world including the validators but also including anyone else can just participate in the auction to try and win the right to propose the next block so right now validators are doing both but in in attest or proposer separation validators would only be doing the attesting proposers would be this
permissionless auction mechanism yes and just to be clear like the role of proposing right now to a very large extent is just signing a header blindly that you receive from a relay or that ultimately came from a from from a building so like 99% of the effort is kind of away from the validators and what APS is all about is just taking this 1% and like very cleanly putting it away and if you do that you clean up a lot you remove timing games as a concern for the validators you remove me spikes you remove worries about pre-confirmation and sophistication and you know having to deposit collateral um and so ultimately I think it's a very healthy
thing that can make the validator set extremely unsophisticated and ultimately the end game is that you you're just a dumb validator on a smartwatch in your home internet connection and and and and and that's enough now one of the the worries you know that that keeps creeping up and I think it to a large extent you know it's unwarranted but you know that is a discussion to be had is that people think that um you know this is going to be really really bad for Block building because it's going to be like hyper centralized now the framing that I have is that the validators would still be responsible for the most critical part of block building which is including transactions on chain
censorship resistance and the proposal that we have is called inclusion list specifically fossil so the ilil in fossil stands for inclusion list and the idea here is that at every single slot you have 16 validators that basically build lists of transactions that they've seen and then these lists get uh aggregated into one master list and then that is the starting point for the builders to go build that block now what I imagine will happen is that the vast majority of transactions will be in the inclusion list and ultimately what the build ERS will do is just like polish the list a little bit and there's two ways in which they can polish it one is that they can reorder the transactions
and two they can insert transactions here and there and what they would likely do is you know at the very least include one transaction at the very top and one transaction at the very bottom for the front running and back running and so what will happen uh in my opinion is that ethereum would be like extremely healthy and have decentralized block building from an inclusion standpoint but then like the very fin um piece that that is done by the builders would be centralized and the you one mental model that I have here is this notion of raw material and polishing so you can imagine that the validators provide the raw material to build the blocks and then the builders just like polished it a little bit around the edges safe is moving the
world's GDP onchain with the introduction of safe net safe is taking this to the next step very soon check out net. safe. Global to learn more about how safe is moving the world's GDP on chain welcome aboard on our journey into the singularity this is the endgame road map for frax and fractal the new L2 out of the frax ecosystem that is totally based on fractal scaling frax is a modular L2 blockchain built by fra with modular and fractal scaling in mind fractal scaling is based on the mandal BR set of fractal images is and it explains how l2s become l3s and the
entire app chain life cycle goes through its Evolution the frax ecosystem is made of some of the top builders in the space and has stemmed from its OG days of the frax stable coin it is now in the LST space the LRT space and this frax L2 joins the existing Suite of frax products including fra Swap and fra lend you can see FRA faery the bridge to go from any chain arbitrum optimism or main net into the fractal main net Bridge your tokens and bring your FRA assets into the fractal ecosystem join today to
get the best out of fraxel you are still early join today take part in our Expedition into the singularity redstone modular oracles are available on 50 plus chains trusted by over 100 clients and over 6 billion in total value secured visit redstone. Finance to find out more yeah I mean th this is part of this like I I think there's really people want inclusion lists fossils and proposals people want execution auctions people want orbit like we want all of these things that are part of the beam chain proposal the main push back here is faster do it faster we want it now
faster faster faster yes I mean everybody in crypto has like the mentality of like the rat that has like like that gets the peanut butter and then wants it again I mean so but part of that though is this oif accelerationism because like can you pill us on oif accelerationism yeah like like how are you balancing this idea of ethereum as this like immutable credibly neutral extremely decentralized base layer versus okay we need to to make these changes to the Bas layer and like you know is this the end game for ethereum or like how do we how do you balance ocation versus like we need to improve the L1 and and speed and safety because people want it now but they don't want it to break ethereum and so to accelerate OIC I think it's to do it quickly but you can't s like we don't
want to sacrifice the safety of the system okay yeah so there there's a lot to unpack here um so one of my kind of mental models fortification is that there's there's two types of reification there's unhealthy ossification and healthy ification the unhealthy sophistication is basically where you're not able to evolve and you have stuff you know that you want to do and the reason why you're not able to evolve is because you're crumbling under your own weight right like for example you're securing so much value that you become so conservative that you paralyze and then you now what you've aifi is kind of the suboptimal design and you know that's going to lead to ultimately like frustration and opportunity for
competitor to come in and all sorts of other negative external ities and then there's basically the healthy oif which is you've reached a point which is close enough to Optimal it's good enough and it means that you know you enter this maintenance mode where you know you've effectively cleared the whole road map and there isn't this tension where you know in the future there is this big rearchitecturing that we would would want to do and and you know the reason why people want deification is because ultimately eum is about providing certain about the future we don't want to be like rugging people and and changing the apis and whatnot and you know this is to a large extent why um
why we can't you know change the the evm right the evm needs to be maximally forward compatible and so already there you know it's kind of crazy to think that that the evm would change to something very different unless you know we do this kind of crazy rabbit of out of the Hat where we go one level down with risk five and then now that allows you to build other virtual machines on top on on top of RIS five um yeah I mean like one thing you mentioned earlier was the the commonization of you know things like the the evm so how do we prevent uh uh commonization like once we aify right that's kind of it we enter maintenance mode how do we prevent uh commoditizing what we've
aifi uh how do we prevent commoditizing what we have aifi well um no we want commoditization and alific these these two things are aligned right um I mean when you started the question what what came to mind is um kind of this this mental model that was shared recently I think by by David on Bank list which is that um there's kind of this this decoupling of responsibilities right like in some sense what the L1 is there to provide is you know infrastructure and technology and what the l2s ultimately are there to provide is BD and new users and things like that and this is a story which is only starting to happen now because initially
you know the big projects like arbitrum and optimism and ZK sync like these were like technology research shops right they raised hundreds of millions of dollars because it takes you know an army of Engineers to go build these fraud prooof games and these snark circuits But ultimately what's going to happen is that the fraud proof games and the SN circuits they're going to commoditize it's not going to be a differentiator for the rollups what's going to be the real differentiator is something other than technology because the technology whether or not it gets enshrined within ethereum and I think it it will to a large extent um it's it's not the differentiator if you're in a world that is commoditized and so if you look at base for example which was mentioned earlier like they have an
obvious kind of value ad which is to connect all of the millions of users that they have and bring them to eum if you look at optimism for example they have this really interesting strategy around public goods uh and this is the kind of of of mentality that we need yeah Justin so I think one last thing from from us and I don't want to be selfish because we have so many Community questions to ask you um the last one is on our podcast that we did uh several months back we talked about eth the asset and how you're thinking about the way of long-term value acral uh amongst other kind of properties of money and this monetary premium and and your one of your core points was around the economy of scale of being this kind of large data availability provider and
and and earning fees long-term if we get into this world of 100 million transactions per second um ethereum ends up generating billions of dollars a year in fees from data availability I think I may have to fact check me on the 10 million transactions sorry 10 million sorry okay I was getting a little ambitious we're gonna make a theme ambitious again and so now that you've proposed beam chain and these these really core improvements to the L1 Bas layer has your has your thesis on the ethereum ass e the asset monetary premium or value kind of properties the the mental model of that has that changed or is it is it still the same it's still the same okay so like my my fundamental mental model is that there's
two parts to the the valuation proposition the first part is flows and then the second part is monetary premium and you know I say first and second but actually in some sense the contribution of the monetary premium is much larger than the flows I think it's roughly a 9 to1 ratio so 10% of the value comes from flows and then 90% comes from monetary premium and on the topic of flows I'm still extremely bullish On Da and the reason is that da has strong Network effects you know there's people out there on crypto Twitter that will say oh it's commoditized and um and that's actually like far far far from the truth and the reason you want to like there's several reasons why why this is the case the first one is that if you want shed
security if you want you know undeniably secure money Legos that other people can feel comfortable composing with then you need to consume aerum da and so that's already like a huge Network effect and um you know just stepping back in terms of like the availability of Da right we're we're constrained by basically a 100 home internet connections and the reason is that each validator needs to be on on a home internet connection and DK Shing full D Shing gives us a 100 home internet connections for the whole world and so sure you know it's 10 million transactions per second but like that is going to be a drop in the bucket in terms of all of the world's activity transactional activity okay so what are
the network effects number one I've already mentioned it it's uh shared uh security but then there's another one which is shared synchrony synchronous composability and the reason is that if you go use one of these you know commoditized Das like Celestia well guess what you're now introducing a new new sequencer you now have the Celestia sequencer which is playing a key role in the production and settlement of of these transactions and so now you can't have synchronous composability because synchronous composability is all about sharing the sequencer and so now that you have two it doesn't work anymore and then there's the final thing that only realized in the last few months which is that in order to make use of this magic
ZK VM pre-compile or ZK risk 5 pre-compile the data needs to be available meaning that it needs to be published in the blobs in the aerum blobs and this is a technical detail whereby in order for the validators to be able to receive these SN proofs anyone in the world needs to be able to produce the proofs but to produce the proofs you need the data to be available and so this superpower of of having the native rollups only works for rollups so there's no such thing as a native validium there's only native rollups got it we got community questions yeah thank you Justin um and I I think Rob and I both share share the sentiment that you get a lot of flak uh for from the ethereum community from
from the broader ethereum uh space and I just think that uh these ideas uh that you propos you put yourself out there um and you know they're ripe for criticism and and for questions so please take some of these with a grain of salt and uh feel free to answer them as you please okay we we'll start with some of the some of the less spicy ones um but maybe the this is a difficult one uh 2077 Collective is asking what would it take to accomplish this entire Vision in one year um I mean what what I'm what I'm hoping will happen is that we can ship the entirity of the aerum road map this decade by 2029 by the end of 2029 so we
have five years now what I what I'm basic what I've basically done is that i' I've looked at the big picture and you know we have these these three different layers uh consensus data and execution and I think data and execution are definitely on a on a path towards completing like kind of this this 2029 Mission but then the the part that kind of seemed to be um you know changing way too slowly relative to the ambition of the road map with the consensus layer and so this is why I you know I I I I want to accelerate it now to answer the specific question ethereum doesn't get anything done in one year right like even if you want to do like the simplest of change um you have to go through the whole consensus and
governance uh process and that and that takes way more than a year because you know it needs to uh first of all you need to gain rough consensus within the community and then you need to go write an EIP and then you need to write a bunch of tests and then all of the different clients and there's like five of them even if you the consensus layer or the execution layer uh and then you need to go schedule the fork and all of that overhead just takes one year and so this is the the reality that I've come to accept that ethereum ships one fork per year and and this is what we've seen since since the merge we've had the merge in 2021 and then we had the fork in 202 so in um we had the Genesis in 2019 and then we had a fork in 2020 2021
2022 2023 2024 and we'll have one in 2025 and uh you know the the thing that I've been you know that I want to pour acceleration is fuel on is basically uh increasing the size of the the forks that do happen once a year I see um and so I think for the next few years realistically we can only have like these relatively small Forks but if we have this parallel effort uh to the to the incremental approach then maybe in four years time we can have this Mega Fork that kind of wipes clean the the the road map and basically closes the Gap with research as ethereum is approaching its Giga gas era I think the ter would be a giga Fork it would be a
giga Fork yes um I mean the other thing that I want to try and highlight is that one of my goals was to try and create I guess a shelling point that the community can be excited around and in some sense the fact that it's not next year but it's like several years in the future might be an advantage in that context and this is something that I've think we've seen you know with proof of stake and the merged there was kind of this buildup of excitement over multiple years and something for people to be excited about one of the pieces of feedback that I got from the community is that you know oh we're now in maintenance mode and we're doing all these there's nothing to be excited about well now here we have something that is that is you know really ambitious really exciting and sure it
takes a few years but that is the price that you have to pay to be in crypto you have to be a long-term thinker um otherwise uh you know go trade meme coins got it um Okay so we've got Josh from mantle uh Justin's having a great time when when and what can existing rollups with technical debt do so the the good news with with with rollups is that you know they have access to governance and so you know they have the ability to change and so you know technical debt for them is maybe like relatively easy to clear especially if we have this pre-compile coming in so if there an evm rollup which is the best majority of rollups
are then at some point in the future um they can just have this one upgrade to just clear like all the thousands of lines of code that they've written for their evm circuit or evm fraud prooof um so I'm not too worried about the technical that what I think the rollup should be thinking about is growth growth growth users users users um and yeah in some I mean one of the things that that theic shared at one point in one of the telegram groups is that um you know the the L1 is competing with Bitcoin and the l2s are competing with Solana right so there's this this this notion that you know etherum is only interested in infrastructure and there's no apps and users but you know that is the remit of the L1 because the the user
the the users of the L1 are developers and then the US of the users are is retail there's this level of indirection and I think it's a we should kind of embrace the separation of of of concerns and you know the L1 should focus on infrastructure and the L2 should focus on users another one here from ether is money that is their handle um do you think real time ethereum ZK proving will be available uh when beam chain goes live into production by the end of the decade yeah yeah yeah 100% um I am extremely bullish on real time proving um the latencies are just going down and down and down and down um and one of the things that I do want to highlight is basically there's this trick that you can do which is that the proof comes uh
for the current slot comes uh at at the beginning of the next slot so you have a whole slot to produce a proof like a whole seconds um as opposed to having to compete to be the number one fastest prover so we're not talking about 100 millisec real time proving we're talking about maybe 4 second real time proving which is much much much easier to to to deliver upon that's an argument to keep the slot time uh slowish or at least one second and not 100 milliseconds uh so that there is more time to produce that proof and then we rely on pre- confirmations to make sure that we have fast finality or fast pre- confirmations yes exactly um I mean the nice thing with proving is that it's
honest minority meaning you just need one person in the world to go do it but for the honest minority assumption uh to be you know plausible and credible uh you need the hardware requirements to be relatively low uh now one of my I think the the ideal would be that the only requirements uh to go uh you know build a proof is to have a powerful laptop and you know there's like hundreds of millions of powerful laptops in the world and like hopefully one of them is like helping help helping AUM out with the with with the proving but if you need a Data Center and you only need one data center well that's not a very credibly neutral thing um and for the for the for the the consensus layer we can basically uh design it to be
extremely snog friendly right we can because we can change we can change everything internally and design it to be SN friendly and in that context a a powerful laptop should definitely be enough the problem I guess is for the evm uh which is not designed to be snar friendly and so here you could imagine um uh you know delegating the the the the building of the proofs to the builders that are more sophisticated you could imagine as6 playing a role or you could imagine kind of uh you know losing the evm and basically just embracing this risk 5 model um what will happen basically is that the really uh snar unfriendly up codes in the evm would would would have a much higher gas
price because they would consume more risk five Cycles so it would be kind of this uh this onetime relatively big change of the gas schedule uh but it would make the native virtual machine of ethereum um you know priced uh properly for what we want to do which is this this notification yeah I'm glad that you brought up the A6 point we have a question from Greg the Greek on how much more research is needed in verifiable delay functions and are we opening up the door for vdf A6 we already have vdf A6 there's already two vdf A6 that have been manufactured there's one from Chia and the foundation also manufactured uh an ASC in collaboration with fcoin um so it's a small batch of test A6 that we
manufactured there's only a 100 of them um actually there's some in my hotel room that I'm giving give giving away um and you know the the production was successful in the sense that we have these vdf A6 they work um the the the thing that happened is that building and and and and shipping Hardware is extremely ambitious and we put in a lot of effort to just get these 100 out and there's even more effort to try and deliver them to the whole community and it gets very expensive and time consuming and and what happened is that vdfs from my perspective got uh deprioritized and the reason is that um Randal which is the random as Beacon uh
didn't get attacked or is not being attacked and there's just more important things to be working on but yes vdf is basically the the the one of the items in the road map is was kind of the the lowest priority in the cryptography uh section and it's something that uh that is a no-brainer because it's it's just a pure technological upgrade that just improves uh ethereum and gives us essentially perfect unbias Randomness now one of the things that I do want to highlight um is that we now have in production the very first uh provably Fair Lottery that is using vdfs uh so it's uh I think the website is eat thexyz or eat the. e. link um and they
uh they buil this this Lottery which uses you know vdfs and so you can just read the code and know that it's provably secure and the reason why I'm excited about these provably secure lotteries is because they can be they're basically Unstoppable lotteries that are Global they don't they're not limited to one single jurisdiction they're provably fair so there's no worries about the operator you know maybe playing games um and also the cut is like zero or absolutely tiny so for example in the case of e the pie there's a 1% cut which is capped at um I think 100 e or something I don't know exactly but basically there's like a reasonable a very very small fee that is taken which is in stock contrast to the government Lottery
where the average fee is something like 50% um and so my hope is that we can have you know on a weekly basis kind of the world ethereum Lottery uh where the price is multiple billions of dollars uh and it would be the the largest lottery in the world I know in my state the uh the lottery can get up to $400 million so yeah so knowing that the government will take 50% of that is just I mean come on come on uh another one from Bill s uh seems that there's some confusion about what this proposal will do to the other progress being made on the road map and other eips uh what kind of progress might we expect on execution layer or execution layer clients in this time frame and uh fully question mark
fully snark question mark L1 scale in question mark yes so the the the content of my talk was very zoomed in on the consensus layer and I think it's important to zoom out and look at the other stuff that's happening uh at the execution layer specifically um which is not my speciality the evm there's like one thing that stand out which is SN ifying the the evm and as I mentioned I think we're going to have that by the end by the end of next year um now the the next step after that is uh to make sure that we're comfortable as a community that we have enough client diversity within the ZK VM vendors and the performance is good enough to have real time proving for sufficiently many
of those vendors and once we have that then we can start adding the pre compile if I were to highlight another kind of big change to the evm which in some sense is a stepping stone to force notification is the the the veral statelessness effort so um the idea here of of of veral is that uh instead of compressing everything you only compress the the the the state right so with Sno you can you can drop the state and you can drop all of the the complicated calculations with veral you drop the state but you keep doing the the computation so basically every transaction comes with uh the data that
it's reading and writing to along with proofs that this is indeed the correct data that is being read and written to and then you just reexecute everything but you only have to store the the the the state route for the for the the corresponding block now one of the things that has happened in recent months um and you know we've had meetings here in in Bangkok is around this this notion of pivoting veral to something potentially much more exciting technically uh which is this binary tree um and the the reason why this pivot is potentially going to happen is because um well there's two reasons reason number one is that veral unfortunately
is not postquantum secure which means that if we go down the veral path then it means that maybe in a few years down the line we have have to do another change uh of the of of the the the the state tree and uh the the other big reason is that in recent months even we've seen a dramatic Improvement of the performance of snark ifying hash functions so in my talk I highlighted um basically one of the one of the benchmarks from the polygon folks where on a MacBook Pro an M3 MacBook Pro they're able to prove two 2 million hashes per second using just the one CPU not even the GPU and that is enough performance to have statelessness so the
basic idea is that you you have a binary Merkel tree which uses the SN friendly hash functions and then when you communicate the proof to user instead of sending the merel path which can give you pretty big you just compress all of the merel paths which is just hash verification into a single SN and so now you can answer any stateless query with just one SN so it's a it's a massive compression kind of technique that allows that effectively yes exactly and in just trying to wrap my head around this here yes it's basically like a compression technique which is a stepping stone towards fornification and it only has to deal with uh with the state and then and another kind of
really cool thing is that if we were to move to this binary stre model then the evm would become like a lot more snark friendly and so that would also tie in with synergies uh with the effort to St ify it a spicy one is why doesn't the execution layer get as much love right um the problem with the execution layer is that we need forward compatibility that is like the fundamental constraints like we can't just go break contracts um now one of the things that people complain about is oh the gas limit is too low and you know the devs don't want to increase the gas limit but the thing is that it's not to the devs it's not the devs that control the gas limit it's the validators right
the way that it works is that every validator has a vote and they can vote to increase the gas limit and so and actually there's this this this this website is it like pump the gas or something uh where they want to try and increase the gas limit maybe from 30 million gas to to 40 million gas and I'm all in favor for increasing the the gas limit and so you know if you want higher gas then just talk to the operators and increase the gas limit it is not something that the the the devs are ultimately uh in control of um now uh one of the the the concerns that's been brought brought forward is that basically the the amount of state would grow would grow too fast um now I don't think this is an issue the reason is
that like state is relatively small today it's on the order of of 100 gigabytes and the real issue is history growth okay so history is basically the sum total of all of the blocks and the state in some s is like the condensation of of all the history in the in in in the current state right the present is much much smaller than all of the past combin historical State yes and I what I think needs to happen urgently is that we just drop large parts of the history if you're running a validate a client right because ultimately consensus is about the present consensus is not about the past um and there's basically this this social layer expectation somehow uh that you know history needs to be kept
um there's a lot of work that has been done to try and get rid of of of of history in a in a in a responsible way I think it's like uh the 44s thep 4444 um and uh what I what I think can would be like a practical Way Forward is basically to have the more powerful operators um you know keep the the full history because at the end of the day it's just a couple terabytes like or one terabyte it's not it's not that much and then those that can't handle it um basically prune prune the history and rely on things like like bit torrent or the portal Network um or even like centralized Solutions like block explorers and whatnot that will be keeping a full copy of the history and
this is where you know the power of honest minority assumptions lie what does honest minority mean it means you just need one person in the world to have a copy of the history for the history to be available and you know etherum is just so widespread and it provides so much value to so many different actors that there's going to be you know hundreds thousands tens of thousands of copies uh regardless of whether or not you know some some few thousands of of validators uh that are on their home computers have a have a copy thanks Justin I think the last one here for you as we wrap up is the community wants to know how they can get involved and kind of what your call to action is for the community to help to uh support beam chain and how we can help uh to ship faster ship better and
make sure that we execute on this well right um so ultimately like the proposal is like an accelerationist effort for the whole road map not just for the consensus layer so if you want to help accelerate ethereum layer one then please contact me I'm very easy to contact uh on telegram or on Twitter there's also a dedicated email address that was shared beam. chain e.org as I said we've already received lots of emails there um and I think what what's going to happen you know in the coming uh you know months is that the dust is going to settle and we're going to see like who are like the the key builders that are committed to to help accelerate this future and like team formation will happen and whatnot um what happened
historically with the the beacon chain is that um at the very beginning there was a lot of excitement and there was 10 different teams that came in and then there was a consolidation period and now we're down to to five um and you know already we have eight teams so what I'm expecting to happen is that in the next few days we're going to have even more teams show up um and what I want to do is is try and allocate resources you know effectively and try and uh make sure that we we don't have a needlessly high amount of teams and um and so I will be pointing you know applicants to existing teams and I will be kind of encouraging the new applicants to uh to to to coals as much as possible Awesome Justin thank you so much uh and
congratulations on the proposal I know that it was a lot of work uh putting that together and that the community can be quite critical at times so Props to putting yourself out there yeah and again like this is just a proposal and the fact that we're receiving so much feedback is amazing because it means that we can improve the proposal so please keep giving the feedback and yeah the the future is very bright thank you thank you