ep 12 – Ethereum, Merge and Beyond

Transcript

[Music] welcome to web3 with A6 and z a show about building the next generation of the internet from the team at Asics and Z crypto that includes me your host sonal choxie this show is for anyone seeking to understand and go deeper on all things crypto and web 3. in last week's episode we did an overview of proof of stake blockchains so in this week's episode we do a deep dive on all things ethereum which this week makes the big move to proof of stake in the merch but our conversation while it certainly will go into the merge and share lots of in-depth and behind scene details with one of the core developers and the bottom line on what changes what doesn't also goes well beyond the merge into a high level overview of what comes

next what's top of mind and more as a reminder none of the following is investment business legal or tax advice please see 86nc.com disclosures for more important information including a link to a list of our investments but now let me introduce our special guest in this episode is Tim Bako who runs the core devs calls and protocol support for ethereum foundation and before that was a senior product manager at consensus joining me to interview him we also have Asics and Z crypto how to research Tim ruffgarden who among other things before joining here led the economic analysis of EIP 1559 on proposed changes to ethereum's transaction fee mechanism for the ethereum foundation and we also have Ali Yaya General partner at Asics and

see crypto who leads infrastructure as well as many other Investments and before joining A6 and Z was also a software engineer researcher as well as core developer in Google's open source machine learning library tensorflow in the long and wide-ranging conversation that follows we take turns interviewing Tim going from talking about how we got here today and what went into the merge in the first third Tech Trends such as Roll-Ups data availability EVMS and more as well as hot topics including proposer Builder separation and others then go deep into the co-evolution of the Proto protocol and the community talk lots of methods and process behind the outcomes including sharing views on token governance Shadow forks and so on as well as the nature of distributed

collaboration especially between r d and of how Innovation happens in a decentralized way but first we begin with a quick snapshot on ethereum today the first voice you'll hear is Tim bees followed by Tim Arts foreign [Music] is really a blockchain that's like as decentralized and censorship resistant as possible but at the same time to do that in a way that can accommodate a large number of users and a wide range of use cases and this is probably like the two main differences would say something like Bitcoin which also is quite a line from like a values

perspective with regards to how they build the software is ethereum is willing to allow more expressibility in terms of what's being built through the evm obviously and also has this roadmap where we would like to scale the chain Beyond levels where like every single node on the network verifies every single bit of data but still maintain very high security properties around that and relatively low hardware and bandwidth requirements to run a node on the network so that's kind of like a very high level View and then the big thing we've been been working on as part of that recently is transitioning from proof of work to proof of stake what's known as the merge so this idea with the merge is that ethereum currently has a

proof of stake chain that's live that's testing the soundness of this design and production and all of the applications are running on another chain that's under proof of work and the reason for this is that we wanted to launch the proof of stake chain in an isolated environment so that if it had any issues it wouldn't affect applications and people's funds on the main network but now that we've seen it run for quite some time we were confident in migrating towards that as the way to secure the network and so we basically go from using proof of work as a consensus mechanism to ethereum to using proof of stake and the neat kind of software trick that allows us to do that is the software that runs ethereum proof of

work is actually a bit agnostic to what the consensus engine is so it runs proof of work on it there are mainnet but if you have say ethereum test Nets or even private networks when we talk about like private blockchains these don't run proof of work they run another algorithm so the idea with the design of the merge was well what if at some point the ethereum mainnet stops listening to proof of work and moves to proof of stake and that's got a high level what the transition is about so the beacon chain famously uses proof of stake for civil resistance unlike proof of work and you know one thing I think that's interesting about the ethereum vision is everybody loves to talk about the environmental aspects of proof of work and how those are to a large extent mitigated moving to proof of stake but I

think what's interesting about ethereum is the idea that there may be additional really important benefits of switching to proof of stake yeah that's a good way to put it and maybe the converse would be I don't think it would be sound for ethereum to move to proof of stake if the only benefits were environmental right it's like that's obviously a huge part of the mix but we want the network to be secure and ideally more secure and the first thing that proof of State gives us that we don't have in proof of work is we can identify in protocol specific validators and these validators as the name kind of mentions they've put up a stake so they've put up capital in the system and that allows you to fine-tune rewards and penalties at a much more granular level than you can

under proof of work because in proof of work basically you pay people to do the right thing and you hope that the opportunity cost that they face if they do the wrong thing is so big that they kind of converge on doing the right thing over and over but there's no way to kind of penalize people who don't follow the protocol rules especially in a granular way so in proof of work you have some quite extreme options like changing the proof of work algorithm to something else which was make all of the mining Hardware not work in a specific setting you can have some tweaks like you could nudge the algorithm towards like certain types of hardware and whatnot but the challenge with those is it's a very broad way to discriminate like you can have honest miners using the software that gets discriminated

against and vice versa so the first thing we get in proof of stake is this idea that we can identify specific validators we can reward them if they follow the protocol rules and we can penalize them individually if they do not that's a massive Improvement just because it allows us to really pinpoint where we want to apply rewards and penalties and the other thing is ethereum is designed to be quite resistant to imperfect conditions like we don't need 100 of validators to be online 100 of the time to produce blocks but we do need most of them to be online most of the time so what we can do is we can scale these penalties that you get for say being offline or doing something malicious in the protocol relative to how many other people are doing the same

thing as you and this is too neat properties one is that if you're an individual validator just like a hobbyist at home and say your internet goes down and it's quite decorated from the rest of the network you'll get a small penalty because you're offline but it won't be scaled if nobody else is offline because the network can kind of chug along without you but on the flip side imagine you're an attacker and you control like a third of the stake and trying to stop the network from routine finalization the penalty that you incur while this is happening grows exponentially so if you're penalized as this large actor affecting the protocol much more harshly so this is another neat thing of proof of stake is not only can we specifically pinpoint validators and apply penalties and rewards more granularly but we can specify the level

of uptime in a way that you expect and the very harsh if this gets into really bad circumstances and be very lenient if it doesn't as a way to incentivize people who have a regular internet connection and not data center access to be validators on the network that makes a lot of sense that you can do very surgically targeted penalties and rewards because in some sense you know who the validators are in the sense that they've registered on a smart contract that's stored on chain right you don't know who they are but you know which pile of capital which stake has committed the offense so one person could have like two validators and one of them goes offline you can penalize just their validator that that's offline so yeah we can identify every unit of

capital and treat it independently I mean should I think of this being at all a concession to how permissionless ethereum is and it's just that it's worth it in exchange to get the sort of stronger security or would you actually assert that there's no change in how permissionless it is as a blockchain I don't think there is so like there's many there's many different concerns being a consensus participant I don't think for ethereum they change from proof of work they prefer Stakes You could argue that they get better but you know I'll take like the strong proof of work you hear first is how hard is it to actually like become part of the validator sets can anybody join so on ethereum anyone can join the proof of stake validator set the amount required

right now is 32 ether and the reason for this amount is there's a trade-off between how much stake you require and the bandwidth requirements because if you have your entire stake divided in 32 ether chunks and say you went from 32 to 16 then you have twice as many messages to process on the network as kind of more effective validators and that requires higher bandwidth connections so there's this trade-off where you can lower the dollar cost but then you raise the infrastructure cost of people and so we settled on 32 each but anyone who has that can participate in the protocol and obviously the price fluctuates but that gives you basically the rights to be like a first class block producer people sometimes will compare this to proof of work saying well you can buy a GPU for

like five thousand dollars or whatever the price is might have fallen since then and kind of join proof of work that way but what you're doing when you have a single GPU you're usually joining like a mining pool right you're not the actual entity producing the block you're averaging out your hash rate with all the other participants in that pool and get a share of the rewards you could choose to mine on your own but the odds that you would ever find a block are incredibly small so I think proof of State gives us a fairly low barrier to be a first class validator there's also many options for people who don't have that amount of capital to join staking pools rather than mining pools and then there's plenty of different flavors and shapes and Trust assumptions but they definitely exist and I think the last

thing I'll say that where ethereum's a bit different than other proof of stake chains is ethereum really values this idea of having non-validating nodes still verify the contents of every single block and whether you're in proof of work or proof of stake ethereum kind of relies on people who are not part of the validator set to also run nodes so that they can verify whether validators are actually following the protocol rule so every node on the ethereum network again in proof of work today improved after runs through every transaction of every block and if a validator or Miner today did something like print themselves a million eth they would reject that block so the right that you're giving the validators is not the right to set the

protocol rules it's the right to Faithfully follow those and have some level of discretion Over The Ordering of transactions in the block but they don't have the rights to like create invalid transactions and this is something where oftentimes you have these two concepts of large requirements for validators and proof of stake being conflated so you can have a system that's proof of stake with really high requirements to run a node and that means you have less people running nodes and validating that those validators are being honest but that's kind of independent that's more about how do you throttle the throughput on your network and nothing of that changes on ethereum between proof of work and proof of stake well I think this would

be maybe a great time the story of what has led us to this moment with everything that's been going on with ethereum both in the human sense and then also in the technological sense where we are today with the ethereum technical roadmap and where you see it going in the next couple of months compare how a crypto Network like ethereum evolves with the way that say protocols like TCP and other protocols at the core of the internet evolve but would love to maybe start with your take on the human element of how ethereum has evolved and how the mergers has come to be it's funny because in way the way the protocol is structured dictates how the humans coordinate around it and what I

mean by that ethereum unlike a lot of other blockchains has a specification which actually lays out their protocol rules like TCP IP or HTTP and it has multiple implementations of that specification and the best non-crypto analogy I found for this is web browsers like you can think of ethereum clients as like the difference between Firefox Safari and chrome where you open a web page on them you get served the same web page there's obviously a large amount of commonalities that these products follow but they also have pretty significant degrees of freedom like the experience of using Safari is different from the experience of using Chrome and vice versa and because we have this setup this means there's no like single code

base to which you can make a change which changes the rules of the ethereum protocol we basically need people who work on each of these implementations to agree to a change for it to even brought into the specification and then re-implemented across those and we could talk more about the community's role in adopting those changes but just like looking at the core protocol itself this is like a really interesting process because at what we now call the execution layer what's the proof of work Network today and we'll keep running the applications after the transition to proof of stake we basically have four full-time teams in four different organizations ranging from consensus which is kind of like a huge Tech startup till Aragon which is basically

you can think of it as like a very thin organization on top of a bunch of Open Source developers and others where there's like these teams of different shapes and sizes in different parts of the world they each have an implementation and each get a say into what change changes happen to the protocol and not only do we have this on the execution layer the proof of work chain but when we designed the previous state chain we went with the same process so now there's another set of teams on the proof of stake chain which each have their own client implementations and similarly you need to agree the changes before they make it onto the network so that means after the merge we basically have these nine teams five on proof of stake four on execution layer who all sort of need to coordinate with each other and at the very least

they need to agree to a protocol change for it to be the first step to be proposed and then potentially adopted by the community that's a really interesting environment because there's no one who can single-handedly push changes in and even more so uh now with the previous text side there's not even a client implementation team that's part of the ethereum foundation so on proof of work we have guests obviously which is quite well known but on the proof of stake side none of the actual production code is written by people who are full-time part of the EF there's this really interesting dynamic where because we have this reference specification even though you might have some code base that has a large share of the network they still can't single-handedly change things on the network that's like

a very neat property about how we're organized has been tricky to navigate the various incentives for all of the parties involved in upgrading to the merge the short answer would be yes it's hard to navigate this because there's a bunch of different people I would say we're not diverging usually at the level of incentives like it's quite rare that incentives diverge a lot because people need to put years of work into building these clients and whatnot and if they choose to do that it's usually because they want to work on ethereum and further the protocol so I wouldn't say we're ever dealing with anyone who's like in bad faith trying to nudge the incentive significantly in another Direction the thing we do get a lot is pretty intense technical disagreements and this is the other bit I think is

interesting is because you have all these teams you allow for a bunch of Engineers with very strong personalities if they disagree with how things are done they can go write their own client and do better and this is kind of amazing because if you just had a single client there's no way you could get these humans to work together on the same code base they just are too opinionated and smart I guess is like the combination of both like they have good ideas that explore different parts of the trade-off space and probably the most well-known example is Aragon today was originally called turbo gas and it was literally a fork of guests re-architecting it from the ground up which started as one guy running this as a side project and is now I believe the second most used client after death the

fact that we had the ability to create a new client from scratch which takes completely different architectural decisions it's pretty wild and so we spend a lot of time discussing those types of issues how decisions in the protocol May leak into implementation details and how do we balance that with having multiple teams working on this I mean speaking of disagreements between sort of strong personalities on technical issues I've been listeners to tune into one of the awkward devs calls which you can hear Tim Biko an action is perhaps the most patient person on the planet Earth it's incredible it was really incredible I know you could probably write a whole book on this what's your been your biggest lesson learned from facilitating and managing these that you think could apply to

other open source and decentralized communities if anything comes to mind it's definitely a lot of learnings I think so it's interesting because a lot of other communities don't use live calls like we do and sometimes a bit envious of them because it's a bit of a tricky medium but when ethereum governance is stalled we're not really sure what the fundamental issue is so figuring out like what's the thing that's actually blocking you from moving forward and the thing I spend a lot of time thinking about and like I try to like judge my performance by is are people actually arguing about the core issue and a lot of time for many reasons you spend so much Cycles discussing some sort of tangential thing and people don't want to get to like the root cause of the disagreement and if I do my job

really bad we'll spend six months discussing something and never get to the heart of it yeah if I do it really well maybe in six weeks we can actually get through the issue regardless of the outcome so I think it's easy to just like go around in circles even in group team meetings that are not decentralized this happens you don't really know what people are debating or fighting about unless you get right to the core of what are we actually talking about right and even more so would a team meeting like say you work at the same company you have like a lot more shared context right and awkward devs in the research team of ethereum I think we do have like decent shared context but we're not all in the same company we're all in the same countries not all the same time zones so the other thing is that when

these discussions are in the abstract they're actually worse than when you have something concrete to react to that's actually yeah that's actually a huge one you know there's been a lot of talk about like censorship resistance lately yeah and whatnot yeah and that's something actually I think we do well on ethereum so we have this research Discord and we try to keep like the topics and the channels focused on like technical subjects so instead of having like a censorship resistance one we'd have you know like a proposer Builder separation one right like I think it's much more possible to like make progress on like tractable technical issues than on like these hard philosophical questions and not that like you need to completely ignore or dismiss them um but it's like you can spend years just arguing yeah like the concept but having like a technical trade-off is I

think in this environment the best way we can move forward because you can get the consensus on that and even though people's values might not be yeah I agree 100 and even in classic works whenever people want to have a philosophical debate it just inevitably becomes a religious debate yeah I just remove it to let's talk about it at the end of the thing when you have something concrete to react to because of precisely that even when it's not technical because it's just the only way to move forward yeah yeah but you know just sort of philosophically and practically this is really the heart of what something means in decentralization and Theory versus practice there's a common question of why do things take so long you know like what is ethereum take long to do things and that's obviously tied in here but is it all boiled down

to this kind of model of having people coordinate both on the engineering and development side and then also kind of on The Human Side right no that's a great question yeah there's definitely a root cause you can think on both sides on the people side there's actually two things that I believe make things take longer than if we were just optimizing for Speed the first is which we were talking you have all these different teams actually implementing the protocol and so not only do you need them to agree like you need them to agree conceptually but then you need their software to interoperate like you need the actual code to agree and a large part of the merge testing is just figuring out okay we have like five proof of State clients four execution clients that's 20 combinations how do we make sure each of those 20 pairs Works

across every possible Edge case and that obviously adds literally 10x more combinations than if we had one on each side so that's definitely a big part of it and what you get from that is that if there's a bug in any one of them you can switch to the other and that bug doesn't get enshrined in the canonical ethereum network if you think of what's the thing that ethereum provides what's like the value prop is you're providing some sort sort of settlement layer execution environment for computation that's very secure and so imagine there's a bug in one of the clients that prints a billion ether you've kind of ruined the whole value prop you can't really trust it as like a settlement Network anymore so having these different clients as a ton of complexity but that's the upside of it yeah we're not ever relying on a

single one of them and the other human part I think which slows down is as the community grows the amount of stakeholders grow and you can think of this as like ethereum in its earliest stage is building like a tech product right you can merge to master and ship things imagine if they're in pre-genesis you can make changes incredibly quickly and even when ethereum launched obviously you need some coordination to ship things but there's kind of nothing at stake on the platform like there's no applications built the value is minimal if there's a bug there it's not the end of the world if you look at ethereum today we have on the order of hundreds of billions of dollars of economic value on this trillions settling per year so if this thing's breaks the impact is

quite big but even beyond that to make changes to this you need the community to sort of agree and believe that like those changes are worth it and unfortunately we're kind of at the point where there's no more really low hanging fruits right if there's something that's just like a pure wind will do it they won't be contentious it'll make things better and no one will agree with that the point we're at now is like there are trade-offs right and when there's like a genuine trade-off as your stakeholders grow then you get more and more people on each side and the default is basically like inertia and one way to think about it for ethereum you could imagine something that would have been easy to ship four years ago mildly contentious today and then five years

might be like impossible to put in the protocol just because nothing has changed technically but it's harder to coordinate the social aspect of it and it kind of makes sense with the value prop of ethereum because if again what you're offering is this economic settlement layer for people as more people use that you want like higher and higher predictability for it you don't want the rules of the protocol to change overnight and this is probably like the biggest critique that bitcoiners make of ethereum is the rules change all the time time and you can't trust that you build something on the protocol and it'll still work five years from now and I think over time we do have to address this and make that lesson less true and vitalik recently gave a talk saying the development is going to look like an

s-curve but there's definitely a recognition you can't keep changing this thing aggressively forever because it chips away at the stability that it provides Tim I was wondering if you could tell us just a little bit on a more detailed level about the testing process leading up to the merge because you know one thing that I find somewhat exasperating is it seems like some people believe that nothing has been happening you know like obviously the rollout has been delayed many times but anyone paying attention would see there are these kind of Milestones being passed at a regular clip so I was just wondering if you could talk about the sequence of test Nets and so on yes of course and I'll even like zoom out a bit more because people feel like the transition has been delayed for years right like not just months and if

you haven't been following ethereum for five years this won't be obvious but there was a different design for ethereum's proof of stake early on that got quite ready to ship around late 2017 2018 and then we decided to drop that and to start again from scratch and this is where probably the first round of people thinking proof of stake is delayed came out of because those people have been waiting for it since 2018. the reason for it is just the design for the original proof of stake was very coupled to how the existing ethereum chain worked it was basically like a special smart contract who could do things at other smart contracts couldn't and it had a lot of limitations the biggest of which was the minimum stake of 1500 East which was quite large and so it just wasn't a great design and additionally

there was all this work happening on scaling ethereum around sharding that seemed to have a lot of like Common Core architecture patterns or design patterns so it made sense to a couple of those two efforts together and so we decided to instead of trying to tack on proof of stakes to the proof of work chain and then tack on sharding in another way like reimagine what would the system look like if we designed it from scratch you know there's no Legacy code coming in from the core theorem chain and so from like 2018 to 2020 this gave rise to the beacon chain so people designed that developed it test it and then in late 2020 the beacon chain actually launched as a proof of stake mainnet with like real funds in it so about six months after that the beacon chain had like

tens of billions of dollars in it had been running pretty smoothly since the launch so now people felt comfortable with the idea of actually using that to secure all of ethereum and it's also worth noting that between like 2018 and 2021 there was a ton of more stuff that got built on ethereum so the stakes were much higher to change the systems so in May of 2021 we felt confident that okay this Beacon chain is working it's secure it's working at scale we can start thinking about making it the core consensus there for all of ethereum and like we were talking earlier on the engineering design for this was will keep the clients that actually run the evm like guess Basu Aragon and another

mine and we'll simply tell them to stop listening to proof of work and listen to the proof of stake as a consensus algorithm and introduce like a communication layer in the beacon chain down so that the proof of stake chain can tell the execution layer what's the latest head of the chain but from the execution layers perspective it's where they get like a heaviest head from proof of work or a latest head from proof of stake it doesn't matter you get the block you run it and this was the General design and so in May of last year we basically had a couple client teams try to prototype this over a month to see could this actually work could you actually run a proof of stake chain which is talking to an execution layer sending it blocks have the execution layer run the blocks verify that it

actually follows all the protocol rules and return a response as to whether it did or not so we managed to prototype this in May I think that like goddess confidence that this architecture would work it was a prototype so we spent the summer fixing all the bugs with it and when we came to the fall the thing we wanted to prototype was transitioning from proof of work to proof of stake so this is the other kind of very complex part of the design is there will be no downtime there's no like turning ethereum off on proof of work and then moving to proof of stake it's literally instant so you get a last proof of work block and then the next block is proof of stake there's like 13 seconds between them one way to make this concrete for users is if you send a transaction right

before the merge it'll be in the mempool you don't know on which side is going to come up and it's not really going to change anything so that was like another design goal is just how do we have this be frictionless for users developers and infrastructure providers last fall we basically prototype this so we got everyone again together and launched a quick devnet which started on proof of work launched the beacon chain ran through the merge and finalized on the other side and so that gave us the confidence that you can actually move from one to the other again it was just the Prototype lots of bugs so we spent most of the Fall fixing that and right before the holidays last year we had something which we thought was a mostly final spec like we knew there would be some weird edge cases that we'd not have

to correct for but that the high level specification was a sound so we put up a first public test net called kinsugi and the goal there was still one stress test our clients and run them through a bunch of edge case scenarios and find what breaks but two also start reaching out the applications and infrastructure providers to make sure that this worked for them like our assumption was that it wouldn't break you know uni Swap and infer and maker and all that but you're like okay can we get them to deploy a version of UD swap on this and not even just a smart contract working but all the connections between the UI and whatnot so we did all of this in early winter we found these edge cases in the specs fixed them and in March we had another public test net where we

basically have I wouldn't call it a spec Frozen but definitely like feature complete so we launched another test net with that and then we started moving from Mostly fixed thing specification level issues the fixing implementation level issues again we weren't like 100 confident like we had high confidence that like the spec with sound but we would find issues with you know many of the implementations in specific edge cases and the new thing we started doing to test this is this idea of Shadow forks and at a high level what we do is we have all the clients and testing teams take notes tell them the merge is happening and run them like on mainnet so they basically Fork off Main net with a small number of nodes and they run through the merge and they hopefully make it on the other side and the things

that are neat about that is you get the state size and database size of mainnet and people tend to think that blockchains are bottlenecked by the amount of transactions per second this is not true the thing that bottlenecks blockchains and specifically ethereum is the amount of contracts and addresses that exist we call this the state everybody's address all the smart contracts all the data and that and this is why like mainnet is much harder so the shadow Forks were really helpful because they allowed us to test it's really early in the process but in the highest Stakes Network obviously without disrupting mainnet itself so we ran these shadow forks and we're still running them at the frequency of once or twice a week we went from in March April finding issues and like client implementations and fixing those

to like May and June we were at a spot where we would find issues more between specific pairs of clients right like we were talking about earlier because we have five proof of State clients for execution once it's like 20 kind of pairwise combinations so it's like taku and Aragon or method mind and Nimbus and it's that specific combination has something we need to fix and that basically brought us the summer and then the last step in our process as with like every hard Fork is we have existing test Nets that we use that we want to run these upgrades on before and even though they're test Nets they're used by the entire Community as well so say like an application has a new version of their smart contract like the new ens contracts they'll deploy it to a test

net before they deploy it to mainnet so ideally we don't want to break those because they're quite useful for the community this summer we started feeling confident that we could upgrade through these test Nets we started on one that was kind of the most chaotic and already stated for deprecation then we did the second one and the last was the Gory test net which has the trailer proven state test net it's used by the most people like the most projects the most takers is like a final dress rehearsal before mainnet and then we would be comfortable for midnight so that's like the main testing Arc we do a bunch of other stuff in parallel there's you know fuzzing of this a bunch of unit tests gets written a bunch of simulators and integration tests like there's plenty more to that but it was really this

process of just going for prototypes which add more and more complexity to spec which we've worked through the edge case through all these implementation and then all the pairwise combinations and then through all of these public test Nets and this is where we're at today that's great I think that gives us a very visceral sense of the sense of responsibility around doing such a big upgrade for such a system that secures just so much value so yes yeah I think I know the answer to this Tim but I think it'd be really good to get your personal philosophy on token based in protocol governance and just at a broad level another way to think about tying this in is as we talk about people humans coordinating just also philosophically sure so my thoughts on token based

governance so I think this comes back to the stakeholders where if you have a project with a very narrow focus and the value accrues to token holders then I think token based governance is totally fine like if the set of concerned stakeholders perfectly overlaps with the set of token holders in an ideal world overlaps proportionally like people who owns a lot of tokens will be really affected and people who don't won't be too affected but I think sure token governance is great maker Dao is probably one of the examples where this actually is quite well structured but then if you start to move towards a system more as like a public good or something where the amount of tokens you own doesn't necessarily make you the best stakeholders and even more so the

amount of tokens you own today then coin voting governance makes less and less sense and this is why when you think of something like the ethereum network even today you could argue protocol developers and developers of the major applications have an outsized role in governance relative to like their ether Holdings if you take I don't know some investment funds who's bought a ton of ether versus the developers of the client teams and maker Dao uni Swap openc and all those folks the latter will have a stronger say in what shapes the ethereum network and this is because we don't do coin voting and the downside is it's much more messy of a process right you can't just like point it on chain and say like okay we have 51 that

we can go with this but the upside is we are able to consider input put the design around like a much broader set of people than just pure ether holders and again especially ether holders at a specific moment in time which can change quite a lot yeah one analogy I was thinking of I live in San Francisco and the other thought that was in the back of my head is what if the voting was decided on chain not just by purchasing tokens but like just like who shows up and participates right and then I was thinking about how there's a study about the incentives for who does show up and doesn't and so there's a lot of like conflict there yeah it's really fascinating to watch play out and maybe it's tied to what you were saying earlier about they're just simply being multiple client implementations but then

what's kind of happening in order to move things forward so they don't just get stuck in committee are there subgroups yes so I'll talk about this in the pre-merge world because it gets a bit more complicated after the merge but ethereum's history up to today on the proof of work chain we have these core developer calls which my day job is to facilitate where the client developers of the protocol and a bunch of research researchers and also anyone who wants to join like they're fairly open get together and they chat about you know potential changes for an hour and a half every two weeks if you want to make a change to ethereum we have a process called ethereum Improvement proposals uh which is eips yep yeah and this is copied from the

VIPs from Bitcoin which are copied from the Pips from python so it's a fork of a fork of a fork of a process and this is basically just like a standard or like a set of templates that you can use to specify your change like you come and you say oh I want to add a new OP code to the evm that does X then you'll specify why you want this op code what it does some test cases what it should do with this input and that input and security considerations and usually people will put that together and then get some initial feedback by client developers researchers applications who you know might be interested in using this and then once they have something that's pretty solid they'll come on on these core developer calls and they'll ask people feedback for it most of the time there's a Dos

Vector hidden somewhere in their idea so like the most common response is they come on the call there's a way to abuse the system with their new feature and so they go back to the drawing board for a few months and come up with like a fix for that usually then they come back and they have something good we then need to think through how we release software on ethereum and we basically follow like you can think of it as like a waterfall process from software development and the reason there is there's really high fixed costs to making releases on the ethereum network because we need everybody to upgrade their nodes at the same time there's a risk that like if they don't do it right they're on the wrong chain and whatnot so we really try and bundle features together with a release we don't ship things as soon as

they're ready on a regular Cadence so when we think through these upgrades we need to think about okay what are the most valuable of all these ideas that people came and presented which ones are roughly the most valuable and also are they fairly isolated from each other because you could imagine two features that on their own are fine but if you ship them together the testing and potential security issues grow exponentially so this is what we then spend a lot of time discussing of these potential candidates eips which ones are the best subset and this is mostly done by client developers and researchers and there's no one metric to look at actually if there is one it's like the security of the network everything needs to pass the bar yeah it's safe yeah

right but then beyond that there is no method and we call this rough consensus you get people to debate it and and the other bit actually the full thing is rough consensus and running code you start trying to write the code for it right and see is this thing actually what you expect it to be is there any weird unexpected issues and usually what we'll do is when we're planning an upgrade we'll have our first subset of things we're quite sure about either because they're very important that people really want them stuff like that and then it just gets tested for several months eventually gets deployed on mainnet then we run through the cycle again so that's at a very high level how it works and then there's a bunch of edge cases when you get to the details for historical context for those that

don't know that that phrase rough consensus and running code actually comes from the OG motto of the internet engineering I don't remember what it's called task force or something but basically it's about hacking and figuring things out and making Innovation happen in a very kind of emergent way and I don't know if you guys know venkatesh Rao yeah he used to work at Xerox which is when I first met him he's known as vgr on Twitter but he has a whole section on this very theme Ian Mark Andreessen were initially working on a book together I edited the first three chapters for it so I remember this phrase very vividly and you know there's like a whole school of thought around it so I don't want to derail us but just want to point people to that resource a website called breaking smart if they want to read more

about it and what that means and I think the idea of rough consensus and running code to them was a key argument for how Innovation is going to happen in the modern era which I think is super interesting because that's kind of how it's played out with the ethereum foundation yeah that's how but as we've been working on the merge we haven't had to work through through what feature are we doing because it's been pretty clear instead of having four teams decide on one side and five teams decide on the other it's been blind teams working together on this specification so that spoke an interesting literal merge of the processes as well and one thing we're thinking about now is what is the right level of coupling between those two layers after the merge because there's a bunch of changes we want to do on the proof of stake side and there's a

bunch of things that kind of anchor and proof of stake like sharding and whatnot but there's also a bunch of things we want to do on the execution side and improving the evm and scaling things there as well so there's value in these things being decoupled and being able to progress on initiatives independently but at the same time like I said earlier there's like really high fixed cost to upgrades so you definitely want to test things working together across both Stacks you don't want to have upgrades every month you want the system to be safe there's a few different things there but maybe I'll just circle back to the community in multi-client diversity and that kind of stuff this is something that is as you say I think very unique to to ethereum and you know people love to argue with the level of the specs

which consensus protocol is better there's also strength in multiple competing implementations of the spec and you also talked a bit about multiple client teams needing to coordinate from the very beginning and how that still shapes how the community works because you can imagine a version of ethereum that only had one reference client right it would still be a really cool blockchain it would be turn complete you know it would have this nice virtual machine and so I'm wondering if you feel like the protocol design somehow encourages the strength of the community or conversely do you think certain decisions were made in the protocol itself as a consequence as a community norms and ethereum so I just wonder if you could speak a little bit about what does it mean to you when people say that ethereum has a quote unquote strong Community or a strong social layer

presumably that's a broader Community than just people who are writing clients and people who work for the EF and then I'd also be curious to hear just about the back and forth between that community and the protocol itself that's a great question it's like definitely the community is not just protocol researchers or developers and you can almost think of it as like a production pipeline we need researchers to come up with things like the proof of stake design as an example of that you then need the client teams to actually write the code for this to work but the client teams put out the software they don't run the majority of the nodes they don't own the majority of ether they don't write the majority of the popular applications on the network so there's very much a need and a responsibility on

the community to then this decide if they want to adopt this upgrade and if protocol developers that researchers are doing their job well they'll proactively listen to the community and not put out an upgrade that's terrible and run through the motions of them refusing it if they can save themselves that hassle they will do it but just the fact that this check exists forces protocol level people to think about okay well people actually accept this change and do they want it and there's also like an interesting Dynamic on the other way where people who build stuff on ethereum or even people who'd hold a theorem like investors they'll have requests for the protocol right you know there's stuff that can make life easier for engineers and they'll pass through those suggestions in general the ethereum Community Values people building and

using the network so like developers and users tend to be quite highly valued protocol developers tend to be extremely valued for their insights into security like I was saying the most common reply if somebody from the community is like oh we should add this to the evm is some protocol engineer will just find it a Dos Vector in it and they'll say well we can't add this to the VM because it'll break everything and they might collaborate find another design for it but there's definitely like this back and forth that happens and you know I think more and more we're seeing like the amount of fields that are solicited grow so like Tim you've obviously worked on EIP 1559 and studied that deeply but that is something where it was quite interesting because a lot of the community was asking for it for either

ux reasons or because they like the idea of burning the fees I think protocol researchers were mostly concerned about whether these variable size blocks could be a Dos Vector for the chain but then there was this whole other area which like you've really helped with which was is this economically sound right like did the incentives line up and this is something that protocol developers didn't feel qualified to make a call on they could look at it and they could have a gut feel for it but they're not experts there and you see this you know in other stuff as well for example cryptography right we can talk about scaling and Bank starting and all that but there's some level of crypto that needs to be introduced where someone who's writing a client in go or in like Java they're not necessary an expert in the intricacies of crypto libraries and

that's a completely different skill set we have to draw on like a broader set of experiences as like the stakes around the economics of the network or introducing like a cryptographic vulnerability grow Tim I was actually curious if there is a particular controversial or contentious debate that you've had in the recent months so I mean we've been working on the merge for like a year so we kind of feature froze everything else so we haven't talked too much about new features but what I think is actually interesting to think about is this idea of eip374 for people who are not familiar it's a form of account abstraction it's a way to get someone else than the end user to pay for gas basically and do do other things as well

but the canonical use case is you have a user who's used ethereum and like they don't have gas to pay for something but they'd like to take an action play a game by an nft so could the nft platform or the game create them an account pay the gas for them and have that in a pretty secure way well there's been many proposals for this over the years and there's one that's reached a spot where like it is technically simple and this is eip374 I don't think there's any risks to the protocol in in adopting it but there's contention about malicious actors exploiting at more the application Level and basically what this means is when as a user if you want to give a smart contract like access over your account you are basically

giving them access over all of your funds and whatnot you would then create this class of contracts on the ethereum network which has you know the equivalent of root access to some users accounts and you could imagine somebody deploying a malicious version of that potentially waiting for a very long time to get a bunch of approval so they could behave honestly for a long time getting a bunch of adoption and then at some point they turn on the evil switch and drain all those people those accounts and this is something interesting because you you see today that ux and end user safety around funds and whatnot is like a pretty big concern and yeah you could imagine an alternate world where like this was adopted in like 2016 right and it would kind of be part of

the risk profile of using a blockchain that we have today and there is like already a pretty significant risk profile right like people need to keep private Keys which is not something you get like in web 2. so you could imagine an alternate history where this gets proposed in like 2016 or something and people are much more comfortable with this because users are much more technically sophisticated and then you shift this and then maybe you develop wallets with assumptions that this thing exists and they kind of end up looking different but today we're going to spot not that this change won't happen like it still might but it's definitely very contentious because of this and I think because of the level of adoption we're at and I would wager like if we don't get it in the next couple years adding

this like 10 years down the line imagine when ethereum is integrated across a whole bunch of different Financial things and whatnot people have a very good model of how a wallet should work what are the risks adding this completely different Vector that feels like it would be practically impossible I think that's an example that's a neat very neat I need an example of yeah where we're at right now yeah yeah I mean it's a little bit of you know building the airplane while flying it yes so quick lightning round section now this is like 30 second Super rapid stop I'm gonna quickly throw out some topics and this is really just getting at what's ahead what's next what's top of mind let's just go ahead and start with statelessness so super quick statelessness one question from Noah Citron on our team was what you think

will happen with stateless client development once the merge is complete do you have any quick thoughts on that yes it is very much top of mind it won't be like the very next thing you have to merge because we have to ship withdrawals and other things but it's very much the way we see scaling the execution layer yeah actually by the way for me the best definition I ever read about ethereum was as a distributed State machine I thought that was like such a nice Pure Clean way of describing it what is your view of what privacy will look like on top of ethereum down the line this this is a really hard question not a 30 second one we get it but yeah well I would want my absolute dream is for each transfers to be private by default not smart contract calls but

like you know 21 000 gas keep transfers if we have those private by defaults on L1 I think we would solve 99 of privacy issues I don't think this is likely to happen for a bunch of reasons we're going to keep seeing many different application layer privacies I think just like how in 2017 there were a bunch of good Concepts that needed a few tweaks and actually worked at scale in like 2022 I suspect it'll be the same for privacy like there's a trade-off between like how do you do compliance with privacy how do you ensure that there's no bugs and whatnot where I clearly have a lot of like brain power in the space dedicated on these things and the v1s might not work but I'm confident we'll get that I think l2s are interesting as

well the biggest challenge I see with like ltus is is privacy a competitive advantage or like a hindrance some extent and that'll be like a really interesting thing to see play out is the fully private L2 gaming more or less adoption than like the fully open one yeah Okay cool so a couple more quick lightning round things I don't know if you can do this very quickly but just at a very high level there was so much angst around eat versus eat classic ethereum classic and one question that Sam Ragsdale and our team asked just whether a fork can be zero sum or positive some and my short answer is I think they can be positive some I think the technical barrier to execute a fork goes up as blockchains are more adopted and that's

a feature another bug and that if like a billion people are using this chain you want it to be harder to Fork than if like a million people are using or if 10 000 people are using it I don't think they're impossible I think they need careful engineering and like a reason to support it in the long term this is the thing you can see like with ethereum classic is there was like a genuine philosophical almost desire there to keep supporting the chain with its original rule set and like you need some element of that some sort of mission or almost religious like thing because it's really hard to just maintain a blockchain like it's very exciting to Fork the thing like why will somebody be there like three years after yeah it's like this mix like yeah you need

probably a higher level of engineering skills the more complex the ecosystem you're forking is but you also need like a higher degree of intrinsic motivation because otherwise people just won't maintain the thing in and that's most of the work over the long term yep that makes a lot of sense back to the point about how the system ends up becoming ossified as time goes on I really like the idea of Shadow Forks as a way of testing new experiments and trying out new things and potentially serving as a counterweight to that ossification and so far they've really only been used to test the merge but do you see Shadow Forks of becoming a more General mechanism for trying out new ideas and

there's two types of changes I think one is when we change what happens in ethereum like adding a new OP code Shadow Force aren't really useful for that because there's no transaction that's going to like call that new OP code because it doesn't exist on mainnet when we change like the shape of ethereum in a way with something like 1559 or the merge or just the normal flow of activity on the network ends up in like a different shape or form I think this is where they're super are useful because it's extremely hard to write good integration tests for this just because of the complexity of the network and all the moving parts so for stuff like that I think it is super valuable and I hope that we'll keep doing them I'm really glad you brought that up Ali because I've been kind of

obsessed with the topic of Shadow Forks as well especially because earlier Tim you were talking about how at the end of the day ethereum is taking a very waterfall-like approach to software development and I love this theme of like things that are everything old becomes new everything new becomes old because I think of the shift from you know Cascade waterfowl style to later agile style and what's so fascinating me about Shadow 4K is it's actually kind of a cool hybrid in a way because it's a way to not do first bake it and then ship it it's actually a way to actually test in real time and and I'm actually particularly interested and we have to go in any detail here at all but what you can do with simulations as well because we often forget like the computational power we have available to us we can do so much more than we could

have you know like 30 years ago to figure out what real people would do because frankly I personally find it very very hard to believe that well the amount that you are doing on mainnet you actually are really going to surface that many of the edge cases it just seems like the edge cases are actually only found at great great numbers yes for sure and again it really depends the type of thing you're looking for but we do simulations but we also do like a ton of fasting which is really helpful and basically running through like every potential input and what we'll do we'll fuzz different clients against each other and compare the outputs like well we'll do a lot of that the thing is for some properties of the ethereum mainnet people talk about simulating the latency the nodes and whatnot all the time but I

don't know it's like the shadow Forks just so far have been better I'm not like an engineer I I can't tell you like why exactly why is it so hard to simulate it that well but I'm sure that's why people will figure out a good way to do it and it'll work but yeah I don't know why the shadowforks have been working like surprisingly well no that's great yeah and I want to program this at some point in the future is there just one quick misconception you want to tackle about the discourse around the merge like a common misconception that people have that you just want to bottom line for the audience you know the biggest one we see is like that the merge will produce transaction fees on ethereum it's at a high level it unfortunately doesn't there's a bunch of other things that ethereum is doing the

lower transaction fees but the merge is really just moving from proof of work to proof of stake to get the consensus on what's the last valid Block in the chain and it does that in a way that's obviously more environmentally friendly where we think it has better security properties um but the one bit that it doesn't do right off the bat is lower transaction fees okay so bottom line it'll have improvements but it's not going to actually solve that particular thing yeah yeah so not to get ahead of ourselves so let's talk a little bit about life after the merged and the Ambitions afterwards and in particular I imagine scaling will be front of mind I'm curious about the kind of the latest Community thinking around support for various Roll-Ups you know EIP 4844 proto-dink shorting all that kind of stuff wondering where things stand these

days of course so absolutely the focus is on scaling ethereum and one thing that's been interesting about ethereum scaling roadmap over the past few years is economic terms it's moved to like much more of a free market of different scaling Solutions competing and I think that's actually been a really positive change because you know we talk about like scanning ethereum in the future and the implication there is the changes we make to the protocol to make it more scalable but roll ups like are actually live today with production code which is kind of amazing when you think about it because if we were bottlenecked on client developers to write Roll-Ups clearly we don't have them written from client developers but also I don't think we would get the diversity just the fact that ZK Roll-Ups and optimistic Roll-Ups

are both a thing and there's multiple teams with like extremely qualified people going down those two rabbit holes that's amazing to me so I'm very happy that we've moved that concern out of the protocol but that said that there are things we want to do at the protocol to make rollups basically better and the main thing around this is Roll-Ups generate a lot of data which they need to like post back to the chain and they can execute computations really cheaply whereas ethereum doesn't charge that much money to store data on it but charges a ton of money to execute computation and this is like the core insights like why roll-up scale ethereum is they can run all this computation cheaply post back data or proofs of this

data or state this in the case of ZK Roll-Ups and it kind of amortize the storage costs which are less than the computation costs across all their users and at least the lower transaction fees so a lot of the scaling roadmap for ethereum is just how do we create a way for Roll-Ups to be able to publish this data to ethereum cheaper and then that reduces the cost and allows Roll-Ups to either you know accommodate more transactions or accommodate the same number of transactions at a lower cost the main way we do this is ADD basically a data layer to ethereum we want to add just some extra place in the protocol where there's no computation running there's basically just data that's stored there and then Roll-Ups can use this to store data and the other thing

that's interesting about Roll-Ups is they actually don't need data to be stored forever they usually only need data to be made available for some short amount of time and when people talk about data availability this is what they refer to as this idea that like you want the data to have been published for enough people to have had the chance to review it and challenge it in the worst case but that after that the importance of that data diminishes quickly so ethereum scaling solution is to add a data layer that not only creates more space for data but also isn't permanent like the history of the chain and because this doesn't need to be stored forever you can reduce the costs of storing data there because it's only a

temporary cost of the network it's not a permanent cost to every node and so there's two steps we want to take towards that the first is called Proto tank chardonia and dank rod and Proto Lambda are two of the researchers who worked on this hence the name I'm going to ask you about this later but keep going so in this first version of brutal tank sharding the idea is simply that we add a relatively small amount of data that's gossiped on the ethereum network alongside blocks and that's available for Roll-Ups to you use in this data expires after something like on the order of a large number of weeks or a small number of months and by just having this you can reduce the cost of Roll-Ups because they move from having to store data as part of the full

history of the network which is a higher cost to being able to just make this data available for a short amount of time and have the network forget it and so this is the first step towards that the Second Step once we have this Foundation is what we call think charting you're like the full tank charting is instead of even having all of the nodes download all of this extra data you can have no sample across a larger amount of data and get a really high probabilistic guarantee that all of the data was made available this is what we call data availability sampling so instead of basically having these blobs that are about the mega size you can create like about 10 times bigger ones but you just sample randomly throughout

them and have a subset of networks each sample a subset of the blocks and you get really high guarantees that all the data was actually there and published and so having this two-steps approach basically allows us to first shift this data layer make sure that this works that the data actually gets gossiped that you know Roll-Ups use it and whatnot and then we can scale that using cryptography I feel like when I first joined the crypto team six months ago I feel like the slacks is like Non-Stop about data availability and talking about Roll-Ups no I'm just kidding do you guys have more to stay here I wanted to ask Tim if you have a view of what the end game of blockchain scalability looks like so once some of

these pieces are in place and Roll-Ups can be built and there's all sorts of debates as to what ultimately looks like the unified layer that allows for decentralized computation to truly scale I'm curious if you have like a defined view for what that will look like so it's very hard to have long-term views in this space I find I do think one thing we get with ethereum moving to proof of stake is we have like a very high amount of Economic Security on the chain and if your version of like what you're trying to build for a blockchain is something like economic zone on the internet that's at the scale of a nation-state you need a very high amount of security on that chain because you

wanted to be able for people to transact in like large and small amounts and for it to be somewhat resistant so interference from other parties I think ethereum Clarity is is on the path there and there's a couple of reasons for that you know we mentioned like decentralization and lowering the pace of changes to the protocol so it can become more neutral and appeal to a larger set of stakeholder from like this kind of social or like political almost lands ethereum seemed like a really good candidate there we're just talking about Roll-Ups and they basically need somewhere to post data where they have a high assurance that this doesn't get censored and that it has been made available for some amount of time and I think the thing we get on ethereum is

that by coupling sharding to this validator set you basically get the economic weight of proof of stake Beyond this data availability Network right and then these Road Labs you know they can scale the computation and people now talk about things like l3s which is a roll-up that settles on a roll-up which settles on ethereum I can definitely see something like that where you don't need the economic security of nation state resistance for every transaction that you make but you do kind of want the foundation of it to be solid a weird way to think about it is like if you open the corner store in a country you don't need the highest Economic Security but like open in your corner store in the country with relatively high security

versus very low changes like your experience of running that corner store right totally and this is where I think something like an L3 that settles on an L2 that settles back on an L1 you can have lower cost things for use cases that don't require as much security but having this like solid foundation I think is quite important so I do think it's incredibly valuable to have a diversity of Roll-Ups and of execution styles that are possible and selling on ethereum there's a world where like we stop adding stuff to the ethereum network and we start removing stuff so you can think of it as okay now we've become the sort of settlement layer do we actually need all of this expressibility could we curtail it a little bit again hard to speculate on that it might be hard to make those

changes but I can see definitely ethereum just stabilizing and becoming this Foundation that's used yeah completely agree so we we've always talked about how there is a very high dimensional trade-off space for decentralized computation and various different applications require different optimizations simply land in different regions of the space and so it's nice that we have as many experiments as we have with different approaches for scaling blockchain computation because each of those experiments often lands in in different regions of that space I think one related question which I think is probably more more uniform at least across all of ethereum is what you see the future of the evm being like one

potentially controversial view might be that moving away from the evm might be a very healthy thing to do in the longer term or maybe you continue to support solidity solidity and maybe Viper and other other languages that developers directly interact with that is important to potentially preserve backwards compatibility with that but that ultimately the intermediate representations might be actually much more flexible and if we do for example if we move into a world where we have more efficient proving systems for zero knowledge proofs and we were able to prove for example something like the risk five instruction set or there are many approaches along these lines where it is possible to actually put a lot of the computation that's done on a blockchain inside of a CK circuit that

maybe is actually a good thing to move away from the evm and onto VMS that are much more optimized for that particular regular kind of use case and that that might allow us to get to a whole other level of scalability so I'm curious what you think about that what do you think is the future of vvm especially in the context of ZK relapse yeah that's a great question so I definitely agree with you in terms of what will the average developer on ethereum use that maybe not being DVM in a relatively short time frame I think if if you talk about swapping the evm on L1 for something else that gets back to this idea that large changes become harder over time it's almost like there's this race and there

are people working on like a full ZK VM you know could we actually replace the L1 evm what a ZK evm and greatly reduce that and I think it's like it's almost like a race between the research and the ossification of the protocol there's a world where like this is all possible in two years three years and maybe it gets considered in the last major upgrade to L1 there's a world where this takes like six years and it just feels not possible anymore I do think like that means being able to have these Innovations happen on L2 is like incredibly important there's a trade-off on L2 because they all talk about evm compatibility and evm equivalence and especially if you have like an optimistic roll up you want to be close to the evm but if we can find

ways where they can add new features or try different things and not scar themselves too much if L1 doesn't adopt it that's probably the most likely path I wouldn't say that there's like a more than 50 chance of L1 completely strapping out the evm to something else but it could happen but yeah it gets harder over time do you have a view as to how important it is to have full evm backwards compatibility for something like a layer two oh for Layer Two I think it's much less important and this is like another thing that's kind of interesting it's like even for layer one I think ethereum has the view that like recent history is the most contentious bit right and it's almost like if you can choose to secure a really long

history that's thinner or a larger recent one ethereum seems to want to move towards having more security over the more recent things compared to say Bitcoin it's like you know bitcoiners will insist about validating every transaction since Genesis I think ethereum's view is that most of the contention that can happen on history is on the recent blocks and you know in practice it's like if I ask all three of you what's the last ethereum block we might disagree because like there might be some Forks right now if I ask you like what's the block from like a day ago pretty sure we'll agree and if I ask you like the block hash from a year ago the odds that we disagree are tiny and also the cost of US disagree and you're probably too big to reconcile because so

much economic activity gets settled right you're not going to undo history from like a year ago because there's so much things outside the chain that get settled so basically the view is like if you move to a spot where like you concentrate all of your validators responsibilities and computing power on verifying the most recent history and you can allow people to always validate the changes up to them but not necessarily have every node on the network do it I think that's like a likely Direction Where We just accept that at certain points history is fixed and mover security budget more towards the recent that makes sense is separate but the related architectural question I was curious to get your take on how viable it is to build some of these

pieces in a very modular way so like one of you might be that you can actually build a data availability layer that's completely separate even from ethereum that Roll-Ups that are building on top of ethereum Might leverage versus having an approaches much more vertically integrated where you're much more opinionated about how the pieces fit together maybe this is something like tag charting ultimately and I'm curious if your take of the sort of the relative merits of each approach so like obviously you you can do it like in a more modular way and people do it so again it's like the question of do you want to have the economic security of the L1 back in your data availability layer as well and to me that's you can think of it as like a cost versus quality consideration you can have

something which just has lower security requirements and in that case yes maybe assuming your other data availability layer is you know significantly cheaper than ethereum and offers like a lower amount of security then yeah I think it is totally reasonable the challenge is like if you start integrating it's very hard then to untangle things that is probably the flip side of this and ethereum people always talk about modularizing the evm this is like this idea you know oh you could put out the vvm of like Geth or something and just have people work just on the evm and use that but if you bring back to this idea of security it's very hard to do that because all of the connections need to be secure and we've done it successfully with the proof of stake chain because we

did it from the start but it becomes really hard to decouple these things and for example if you look at the evm on the ethereum main net we have these execution rules that are pretty complex now around like if an account is already been touched in the transaction it costs less to access it again and whatnot and these things they make it harder to think of the evm as just a set of instructions because like it's not right like it's very dependent on this context and the thing is like those rules are mostly there for a reason because you like reach these problems with scale if you want the network to stay healthy as there's more scale so I guess in fact you can start modular as you gain really large amounts of stake or value on your network that you're depending on it becomes much harder to decouple things

if your thesis is things are going to just stay modular forever it's a bit harder to see that reach like a really high level of adoption and security because you're going to have to make trade-offs like there's no you start to get clean state today but like in five years you will have to do things and you will have a couple of things because of like some weird mispricing that you thought of and then you're back to like a similar design of ethereum you know ethereum is almost like started with the VM then you add the consensus then you add the data you might imagine somebody starting with the data and then you know they add like consensus and it's the only reason I don't know I don't want to like be dismissive or think that like it's not going to happen at all because

again like the space will humble you yeah but I think this stuff it always sounds so much cleaner in theory than whatever you like and it may be that it's something that just can happen over time as the interfaces and the abstractions become a little bit more clear and as we understand what each of these modules are actually supposed to do so it's actually possible to have clean specifications that separate them and in the meantime maybe it's maybe that the only way really at the moment is to actually build the thing and it means that it'll likely be entangled and vertically integrated but at the very least you have more freedom to explore the design space because you don't have to Define these rigid interfaces that presumably would be harder to change once you set them absolutely around this idea of defining the interfaces one huge

one in ethereum land is the whole idea of Mev right Mev and like the past two years went from like a fringe thing that a few people were looking at to now being kind of at the center of every protocol design consideration like the whole sharding specification was simplified because we assumed that there is any possible and people will be incentivized to download all the chart blobs and whatnot so it's really interesting how like if the space stops evolving then yes hopefully you get like really clean interfaces but it's and people similarly seem to think like oh Mev is like the last one of these you know it's like the last big no way yeah yeah exactly humans innovating not gonna stop there totally yeah it's not the end of history no yeah exactly but but it is

interesting how these things just like once you've like reached some level of scale then something that was not a problem becomes one because the incentive still optimize or attack that part of the systems are just much greater and this is a really interesting thing about data availability is we haven't really seen data availability systems live with like billions at stake on them and I think for sure that will drive the design of them and once we see that I think I would be much more comfortable in saying like Okay what does this look like five years from now but there might be something that comes up from there and I don't want to speculate this is what that is yeah yeah so let's talk about the new consensus protocol happening after the merge a little bit because it's this very

interesting hybrid of a longest chain style protocol and the so-called bft type Byzantine fault tolerant type protocol and it's kind of bespoke I mean it's not really copied and pasted either from any other project or from the academic literature and there's been you know as one would expect various bugs popping up and the bugs get squashed and that process is continuing dude but even maybe a few months ago I saw there was joint work between researchers at Stanford and the ethereum foundation around so-called Avalanche and balancing attacks and so I'd love your update on is the consensus protocol viewed as like pretty stable and pretty battle tested at this point or is it still being iterated on so for sure it is still being iterated on I think not only to fix potential issues which I do think on

that front we are in a pretty stable place but I don't think the ethereum research Community feels like the current version of proof of stake is its end State that's it I don't think there's vulnerabilities that are like critical vulnerabilities in the protocol or anything that would like the network at risk and the design is made to be quite resilient to those things right and the amounts also required to attack the protocol are quite high so yeah in terms of just like the soundness and the security yes they'll probably still be some issues but I don't think we're in a spot where like thinking through critical issues and things that would destabilize the entire proof of stick chain with regards to like previous mistake itself yes there are many things we want to keep improving and one that

vitalik talks a lot about recently is this idea of single thought finality or like gradual finality so one benefits that we get in previous take that we don't have in proof of work is this concept of finality where we get a very clean height in the chain where we have very clean bounds on like what's the economic cost to rewrite history past that and we kind of assume that no one would want to burn that amount of money similarly to how improve of Works you've assumed that no attacker will have more than half the hash rates for like an extended period of time and so we have this band where we say Okay past this point we're good if we don't expect reorgs and if somebody were to reorx this is how much they'd burn we don't have like a gradual way to get there

it's really like a binary which is kind of weird because in a way you would want the block right before to be like almost as finalized as this one so this is one big change that we'll probably see in the next few years is can can we distribute this economic finality more gradually rather than having it accumulate all in one shot that's one big part of it the other big part is this idea of proposer Builder separation so we briefly touched on Mev and today there's basically like a whole industry that's outside of the protocol that's dedicated to finding the best possible Arrangements of transactions and today the way this is done is this network of people we usually call them Searchers

they kind of come up with the best potential set of transactions they bundle them together into a block and this block gets proposed to a minor today and it'll be a validator after the merge the validator or the miner who receives the block trusts that the block is actually valid and that they'll actually release it and we dislike that this happens outside the protocol so one other big change we want to make the proof of stake is this idea of proposal Builder separation where like those two roles would be filled in the protocol and having some guarantees on both sides like a validator cannot front run the person who sent them a block but then the person who sends them a block cannot grieve the validator by sending him an invalid block or never revealing the contents so those are like two ways no we imagine proof of stake changing I

don't think we're at the end of how this looks like and like you said there's no literature for this and there's no there's no other thing we can copy unfortunately for most of this stuff um when there is we do copy it to be fair like there have been many Innovations from research Labs that are blockchains or whatnot that like if they make sense for ethereum we are happy to incorporate those but oftentimes we end up running into problems that people haven't run into before and we need to find solutions for them that was great thanks Dan oh this is really interesting I do want to Pro because we have a very unique combination in this room in this particular conversation on like just models for research you already alluded to this just now but earlier you were talking about how there's like this you

know this kind of pipeline like research to production and and one topic that comes up a lot and we're thinking about this even and organizing our own research lab which Tim obviously heads up and we have an engineering function as well and I used to work at Xerox Park so I have a lot of thoughts too on how these you know collaborations come about you know there was a thread from Peter at ethereum on Twitter recently and our own Elena Berger pointed this out that some core devs have voiced urgency around the division between the research and Engineering teams and she had a question at what layer of the stack is this most apparent we'd love to hear from you your thoughts on how this could be improved yeah that's a great question it is it is like really interesting because there's two levels at which the protocol needs to be safe

is one like the spec needs to be sound and this is where a lot of the research work happens and then two like the implementations that the spec need to work as expected and this is where you often see the Divide where and less so frequently but researchers thinking the job is done when there's a spec for it but then people like Peter on the get team he has to implement the whole thing and it's not as clean as in the paper when you're actually writing the code for it in adversarial condition this is definitely part of it over time the fact that we've now literally merged the Live code for the beacon chain and the execution layer has definitely made folks on the research team more aware of the implementation intricacies and similarly it showed the people on the

rotation team the research can work some of this stuff is actually can be used in production and I think we had like a mini version of this with 1559 that like it can be hard to like appreciate it if you're not a researcher if you don't see it working and I don't know that there's like a single solution Beyond getting the people to spend more time on the other side and like knowing more about it and I mean one recent example we were talking about proto-tang chardinian it has like a similar mechanism the eip1559 for how you price the blob so if more people want to send transactions you raise the price of blob transactions and then if less people want to send it you lower the price of the data on the blobs and there are some questions about like for sure like the base feature that's

basically be stored and on the research side they see the full world map and they think they'd want to move this to be part of the ethereum state because over time we might want to store like more information about the data there from the implementation side it's like well we already have a base view right in the block header and like when we get a new transaction in the mempool you do a bunch of checks against the block header to see if it's valid including checking you know does the amount of gas time relative to the base fee make this transaction have enough funds to pay for its execution so this is like a mini example but you know it removed this value to the block header now even though it's less elegant in a research way it's one of the things where it just

makes the implementation of it much simpler because it works with the the patterns in the actual code base and I I don't know that there's like a way to uproot force or like speed run this you just need people to start to get that right where does this stuff live in the actual production code and that just looks different than what you spend specify the high level spec for it yeah I was going to just say that Peter's quote which I thought was really funny I shouldn't laugh but it was very direct quote I'm extremely frustrated when a research proposal says quote everything's figured out it's just engineering now end quote and I chuckled when I saw that Elena shared that because that's literally the Crux of the types of debates we used to have at Park too you know and the way they solve that

is actually by not dividing the two parts they didn't Silo them they actually ended up with a model where they were embedded together and so that was like a way that they ended up um approaching that for a lot of the things that they were building that's a great Point actually and we do do that more and more so to take death as an example we've talked a lot about selling stuff for Altus there is a bit of scaling we can do on L1 as well and this is mostly through like statelessness and this has to do with not having every node store all of the state on the network but only the bits of the state they're interested in and to do this we need like a different structure for this state so right now you can think of like what we

use to store all the ethereum state as like a the shape of a Christmas tree it's like you know high and narrow and if you want to store bits of it it's almost like you need to cut like a slice of the tree it's like this long slice and you'd want to move to something that's more like a bush that's like short and wide and so you only need to keep a smaller bit and this is the type of thing that is very clean in the research right it's like well you know you just moved from this data storage to this data storage but that for something like death it's like literally rewriting every assumption they have about data retrieval from the state so they have a guy on their team Guillaume who that's literally his job he's like working with the researchers on that prototyping you

did Gap and thinking through like okay how do we take this face level pretty simple change from a research perspective like everybody understands what the old tree looks like what the new tree looks like why the new tree is better but how do you actually Implement that in the code and yeah for sure having people across those teams is super super valuable a picture on the Whiteboard can definitely be worth it a thousand lines of code no doubt about it so yes hey our wall is at the Palo Alto Center the entire wall was a whiteboard not just like a white board that was standing like a third of the space anyway Ali what were you about to say I was just gonna ask how often is it the case that feedback goes Upstream from the engineering team back to the research that causes respect yep I was

wondering the same thing I mean you could argue like the entire merge design is that right like so the entire first version of ethereum 2.0 the whole transition was like we're literally gonna build new execution environments and we're gonna get people to transition to that and then there was this feedback wall we already have this thing that runs the evm and it's called Geth and everybody uses it that doesn't have bugs Geth is short for go ethereum it's the go programming language implementation of the ethereum protocol on the current proof of work chain and after the merge execution layer aside so it's basically the software that people use to connect to ethereum so we changed like the entire respect to like basically reuse all of that software I think that's like

pretty massive one for minor stuff I do think it happens more and more you know I just mentioned this example around the ip4844 I think there's another one for example where a lot of the things around statelessness that are hard have to do with self-destruct and removing self-destruct is quite tricky but one engineering fix that's easy is you can just raise the gas cost to basically Infinity over time or something like that so so ideas like that I think more and more flow through and I think the fact that the two systems are in production helps a lot right that we can look at the Beacon chain look at like its actual behavior and its actual implementation and decide to make changes to that obviously it's not perfect and it never will be but definitely a better spot than like two

three years ago amazing okay so do you have any thoughts on sort of the foundation model Elena had a question about where the ethereum foundation gets its legitimacy Sam Ragsdale and our team asked like where does the future of public goods funding look like and I'm just trying to try these themes together for the history of an evolution of Open Source you know I'm very close studied the Linux Foundation talked a lot to Jim when you think of the parallels like Linus Torvalds and then you have vitalik then you have the ethereum foundation you have Linux foundation and that's been a very successful example of like a foundation and I wonder if you have any like top of Mind thoughts things you're thinking about along the notion of the foundation model and or public goods funding as part of that so I spent a lot

of my time thinking about how do we fund the base layer like the core protocol because that's where most of my efforts is spent and where I see most people working on and I think the EF has done an amazing job there like it's supported teams through very brutal times CZ took in hindsight see this as all self-evident but there were many times where like ethereum could have just been a failed experiment right and the foundation was incredibly good to just stick around throughout the times and support not only like people working there but just all of the contributors at all levels of the stock I mean you know people talk about like the uni Swap Grants um the foundation gave a pretty massive peace denominated programs the client team a few years ago so like I think that that's all been incredibly helpful

and has helped bring your theorem to where it is today I think that the thing that we're hitting on ethereum is just the ef's relative size to the ecosystem is quite small frankly like I don't have the numbers super quick but the EF without a report I think was in April where like the treasury is about under order of a billion might be like between one and two which is not nothing but ethereum is worth at least 100x that other projects on ethereum have a treasury of comparable size and many funds investing in ethereum have funds larger than this so like it's interesting because you kind of move to a spot where like capital is definitely not the differentiator of the EF yep very good point yeah you know the EF has like a really good job in trying to find

thoughtful ways to signal both within the community and outside of blockchain to the rest of the world why ethereum is important what type of things we think we should invest in and try to build but one yeah one other project I've been trying to help with over the past few months is this thing called protocol Guild where we want people working on the protocol to be funded idea leave for a very long time and ideally also independent of the entities they work with so one thing that like the EF can do like it gives grants to individuals it gets grants to entities but it doesn't really scale to like pay every single contributor to ethereum even though a lot of the value is in the actual humans and not just the orgs right there's a lot of people who we

want to make sure they keep contributing regardless of where they work and so this kind of summarize the idea what protocol Guild is trying to build some on-chained system where we can identify protocol contributors to ethereum researchers generally just like people we want to make sure keep contributing and then have projects in the ecosystem be able to just direct tokens towards that so that you can kind of think of that as like upside potential in the entire ecosystem that they're building that's actually not that dissimilar to the Linux Foundation from a traditional kind of Trad point of view with their corporate Partnerships only in your case you're doing it with different entities in a more decentralized way I think stuff like that is really exciting I mean this is not the only initiative

optimism is working on retroactive public goods funding Bitcoin has always been like a major supporter of this so I think if we can try a couple of these models and ideally find something that is like long-term sustainable and that's independent of a single entity that's really the the goal yeah that's the thing one question I had for you is because it's not credentialists it's obviously not credentialist this is a new space there's no quote credentials you have to show your work so how do people kind of learn in a decentralized org or rise up like is it just the work they do and their articulation or what is it I think it's definitely a mix you know it's it's hard to speak for all the others but for me I started out working full-time in crypto I was a product

manager at consensus working on their protocol team and so I got to start attending the core devs calls and whatnot even if you're if you're quite smart there's so many kind of non-obvious things about how this space works that just like spending time and learning by osmosis is is probably a good start um you know I spent like the first many months of listening dial core devs not saying anything yeah and then I think this was kind of a hack for me in a way is these calls can get like a bit procedural and sometimes boring so I started live tweeting them I was like you know not everybody has like two hours every two weeks to listen to all this people do sort of care about you know what what's happening on ethereum and if I have to live tweet them then I kind of have to pay attention because I

need to tweet what's happening so that's so I started yeah I started doing that and I did it for a year or two I think there was not a lot of people on the call that were basically not Engineers or researchers yeah and so just in terms of like opportunity costs it's better for me to spend my time running the calls than for an engineer who could just write code instead so that sort of happened a bit naturally at that point there was definitely like appetite in the community to better understand what's happening at the protocol level what's being debated and whatnot so I just started spending more of my time on that and I started writing these blog posts giving these talks trying to explain like what's being considered for ethereum what are the trade-offs what are people discussing and I think that people found that interesting so it's

kind of my path it it definitely is a bit different of the more technical side but I think this space is new enough that there's so many niches of things to like dig in and explore and expand that if you find something you like and it grows and it's not super hard to to grow the scale of your work because everything's so new to kind of just recap I mean first of all there is a gap in an opportunity community that was really unique to you because you are not researcher or engineer so you filled that Gap plus you had the fit so that's one idea the second is this idea of kind of showing your work like what you said about live tweeting and being engaged and kind of being throughout that process I think that's another really key idea and it's something we've

definitely talked about a lot the third thing I want to just say is just because it wasn't research or engineering it just shows how all kinds of skills are important in these communities we once did a podcast years ago it's one of my all-time favorite podcasts with Michael Rogers and Nadia Iqbal a few of my friends who both study and participate in the history and evolution and culture of Open Source and one of the things we talk about is how there's such an important role for onboarding and while this is not onboarding it is a way of bringing people along both the live tweeting and the way that those calls are facilitated yeah yeah and I do think the path is less clear the less technical you are if you're an engineer or researcher you know if you're like a zero knowledge researcher and you're wondering what to

do on it very clear someone will send you a list of 20 open problems you've got to work for five years and the farther away you are from that the more murky the problems are and sometimes it can just take more time to find what's the right fit but yeah I 100 agree that we need people to coordinate and help shape the space one thing I was wanting to ask you about and this is kind of a funny question but you know I notice it's cool how for instance you guys have like people's names from the ethereum foundation in the name of products and protocols so for instance like dank sharding for dank red or Proto as well and there's a few that are sort of named after people and I wanted to ask you like how did that come about yeah that's that's a great question as you you say

them I realize this happens more on like the consensus layer and proof of stake side that it does um on on the the proof of work or how funny yeah yeah so and I guess part of the reason is maybe because like there was much more new stuff that like got invented for the proof of stake side especially like you know recently in the in the past couple years so yeah you mentioned uh Deng chardine which is obviously dankrad and uh Proto Deng chardine which is Proto lambda's take on bankrupts thank chardonia specifications so yeah I think people work on this stuff and when they come up with something new sometimes metallics like will jokingly call it that and then it sticks um oh I was wondering where that kind of came from I mean it kind of also reminds

me of like when like you know ecologists like discover a new bird and or a new planet and suddenly like their name is a little bit in it which is kind of cool yes and there's a funny thing there the beacon chain one of the data structures is like a Proto array and I actually thought that this was like some fancy data structure I didn't know about but it's actually no something that Proto put together as well that's so funny but it sounded so it sounded so real exactly when I first heard Proto Danger I'm like ooh Proto what does that mean because I literally thought it meant like Proto as in Pre versus like you know Proto the name Proto which is kind of funny so just one other quick note along these lines is there a thoughtfulness behind how you do think about things like

credit as well as credit credibility and credentialism within a decentralized community like this and what I mean is to be more specific it's interesting because anytime you have a singular kind of centralized project this is true even of like very top-down managed products like a Hollywood movie which has like a credit role and real here you're working in a decentralized way and in many ways a lot of the work is kind of transparently recorded and commits and you know the code itself the history but on the other in other ways there's so much that happens off chain and that isn't recorded and I wonder if that ever becomes an issue because in any large collaborative Enterprise this is often top of mind for creatives and by the way I do think of developers as creatives

yeah no that's a that's an amazing question we definitely think about it and in a very kind of different way then I think most most other like fields and it's interesting for crypto because it merges all these different fields right like you obviously have like the big software and open source bit but you also have like a lot of people with like more of an academic background and they're you know credit excitation is like a much bigger deal and it has Frameworks existing for that kind of yeah exactly exactly I think publishing is a very interesting one where yeah there's definitely like some interesting tension there researchers on ethereum obviously recognize that like it's it's a pretty unique space and we have constraints but it can't be completely different from like traditional Academia otherwise we just don't get those people contributing like I'll take an example

of some Stanford researchers put out the paper about like some new proposal for for proof of stake design and you know if if they want to be academics and you know publishing is kind of part of what you have to do to to grow as an academic and obviously you know you don't want them to not be able to to continue their career there definitely are things where like we like as the ethereum community have like some preferences and try to nudge people towards there so for example eips which are like proposed changes to ethereum all have to be part of the public domain um there's authors associated with them but you know if you want to propose a change to to ethereum sure if it gets in your name will be on it and we'll stay there forever

um but but you can't like copyright that for example so it's something where we as a community have these values that recognize Credit in a way but but may not fit with everything else I think the other part that's like interesting is credited in the form of like attribution with not but the other one is like in the form of like recognition yes I want to hear more so on our team at the EF my team is called protocol support there and the main thing we do is we run these these core devs calls and whatnot but we do a bunch of other things and the trend van apps he's like kind of the master at this he spends a lot of time thinking about like what are things we can do to like recognize the work of people that worked on the protocol when they

launched a beacon chain for example he put together an entire physical book of like people's anecdotes and stories who had contributed he just put out he didn't want to do a physical book again but we did kind of a virtual book with the same thing for the merge amazing yeah those things end up being like really valuable artifacts because people see like metal needed like the work was appreciated by the community but like by their peers that they respect and yeah they get to remember that so that's one thing we try to think about as well as like what are some softer ways where you can give credit to people and it gets remembered I I love what you said there's two themes there one first of all that there's a difference between recognition and credit which I think is really important but secondly also that

it actually doesn't have to necessarily be artifacts that are physical it can even be just like verbal recognition in a meeting and to give you a concrete example that ties these threads when I used to work in education we used to study this Japanese form of professional development called jugio kenyu it was very popular in international math studies and science studies and anyway one of the things that we found in doing these observations in Japanese teachers classrooms is they had this process where they would all all have this Collective discussion of a lesson and a lesson plan and deconstruct it but when they present it to the outside world it was united front from the teachers of X School however this is the key to your point about recognition internally they were very precise about acknowledging so

so and so-san said this and building on that Mr so and so-san we did this which I think is really interesting because then it becomes very clear that people have heard you and they know what your contribution is I think we very much get that on ethereum as well because especially for the technical bits because everything is open source the research and development Community everybody knows who kind of did what because we see the codes they see the EIP exactly and it doesn't necessitate what kind of Ceremonies we used to have at Xerox Park where there's like an IP ceremony where everyone had to recognize who did what for what patent and what went into making such and such thing and so it's really good that you don't have to do that with um such open source yeah okay I've got that by saying to

contribute to ethereum right like the ethereum foundation is one consensus is one Netherland is one and so on and so I'm sure all these organizations have processed to recognize the work of their employees as well yeah one last question Tim if you had one thing that you wish you knew when you started that you could tell yourself what is like one thing you might tell an earlier version of yourself on this journey with the ethereum foundation and the work you're doing I feel like the thing I would tell myself it's more like if I were starting today like I think the biggest thing I've seen is like when I like started getting interested in ethereum I knew like everything that happened on ethereum like I could tell you every project that deployed a contract by ethereum and I think today it's like there's so much happening that

like all of these things are virtual right like you can be an expert in defy and Mev and nfts and whatnot and I do think there is value in specializing you get a lot of value from understanding one thing actually well because the space has so much basically so much hype and so much like people yeah trying to tell you know the most extreme version of what a thing could do if I were starting again today and like I guess what I try to do is if you can find one thing and really focus in it the space will pull you in a bunch of other directions regardless you'll end up reading about Mev and ZK and whatnot you're kind of forced to almost yeah if you can identify a focus then you can actually make really valuable contributions without being an expert

like you would have to be in most traditional Fields like there's so many ripe problems to explore that just focus in you can have a really really big impact well a great note to end on Tim baiko thank you so much for joining Ali Tim ruffgarden and I as we explored all these questions with you Ali and Tim thank you so much for joining thank you so much thanks everyone thanks Tim great to catch up yeah thank you this is great thank you guys thank you for listening to web3 with A6 and Z you can find show notes with links to resources books or papers discussed transcripts and more at asicsandcrypto.com this episode was produced and edited by sonal choxie

that's me the episode was technically edited by our audio editor seven Morris with Justin golden credit also to moonshot design for the art and all thanks to support from Asics and Z crypto to follow more of our work and get updates resources from us and from others be sure to subscribe to our web 3 Weekly Newsletter you can find it on our website at asicsnzcrypto.com thank you for listening and for subscribing let's go [Music] haha [Music]