AMA with Sam Wilson | EPF5 Office Hours

yeah yeah let's not awesome we get recording we get the bra uh brain Shilling over um so yeah thank you so much for joining everybody thank you so much for joining Sam uh this is uh uh uh office hours with the very last uh AMA with a mentor um we have Sam as a guest here to have the last chance for you folks to chat with uh with ethereum cordev core contributor and uh and I I I invited because uh we never had AMA with him before and I believe that he uh has great overview in many parts of the protocol and uh uh contributions to protocol and and um uh also the only time we had you Sam was for the uh the study group I never had this AMA so I I was hoping uh for folks to meet you and uh to get to know you a little so so uh so to start maybe can us can you tell us a bit about yourself like specifically what I'm what I'm curious about uh can you tell how did you started working on in theum how did you get into the ecosystem what was your first journey yeah sure yeah so um I think I followed like a pretty normal like later generation corev path um I used to work for aami they were content delivery Network I mean they still are but uh yeah so that was fun I I got into Rush development there and um basically like built like a I don't know caching proxy kind of system um and because of my experience with rust I moved to consensus uh on the quilt team and there I was working on account abstraction um yeah pretty much just jump straight in from absolutely never working with a blockchain to uh you know writing some I don't know in my opinion pretty decent articles on on account abstraction and and um kind of set the tone for that discussion we came up with um EIP 2938 which was one of the um more recent stabs at Native cat abstraction uh we also published EIP 374 around that time and that was um kind of an EIP about bringing uh uh smart contract functionality to eoas um and then after I think I was there for about two years of consensus um basically myself Matt ncar the entire quilt team moved over to the EF um and that's what I started working on the execution specification uh which is like a python project and uh also where I started really taking like a a lead role in the eips project um you know handling specifications and documentation and stuff like that uh so yeah that that's like the 302 version of of my history um yeah yeah that's great thank you so much uh yeah uh thank you so much for mentioning that like many people here are not even aware of quilt uh because you guys did a bunch of great job there and then it was kind of absorbed by e so I'm glad that you mention it it's very interesting that you just jump straight into it um and so so so now uh and you already mentioned the the specs and uh the E editing uh maybe let's uh just um uh uh CH a bit more about that like uh can you tell us bit more about the uh the specs what kind of work you do these days like because or like uh because it I find it very challenging like you managed to rote like this heavy mathematical notation of the of the yellow paper to python so like what was it like and what is it like working on it uh these days yeah sure yeah so um the beginning was a little hairy um we none of us were python developers I don't know why they picked us to to make this project but uh yeah so we uh we basically just took the yellow paper and and a few like reference implementations like G and Bess and all that and uh we uh started writing a client in Python because we needed something better than the yellow paper because no developer can read it um I don't know if you you've ever looked at it I assume most of you probably have seen the yellow paper but uh it's just dense mathematic notation um it's very difficult to understand and like us at quilt we had become very frustrated with working with it as the reference implementation and we wanted something that would be more uh like familiar to developers so that's what we started the the execution specs project um and like we we started from some some earlier work um Paul I think it was Paul had done an early Port of the yellow paper like like symbol for symbol line for line from the yellow paper into python so uh that's that's where we started from and then uh we've kind of taken that into uh probably the most verbose and repetitive python project anybody has ever seen uh I think you know 80% of our files are exactly the same in every single Fork so you know that's that's fun uh but yeah so so day-to-day development on it is is um there's still a lot of refactoring uh we do a lot of cleaning up of our early decisions like I said we weren't uh expert python developers though you know four years later I think we are now um so yeah a lot of refactoring uh a lot of implementing eips we uh just caught up to I think devet 4 um we have our our last po request up for that so um that's pretty cool what I've been working on lately like my my um specific tasks I guess has been working on getting uh the spec to sync mainnet so uh I started I don't know three months ago or so from Frontier and uh the the it's been sinking since then we're up to block almost 18 million now so uh we're almost caught up I think it's what three or four million left to go um which is pretty exciting uh just kind of like as a way to validate our uh spec implementation versus what mayet does uh yeah and uh mostly just keeping up with eips and um I guess our our big goal for this year is to try and get EIP authors to be able to uh write their own um like to Define their own eips against eels so like if you want to come in and change like the gas schedule you'll be able to give like a diff of a python file in your EIP um and that'll make it so much more understandable than um what we have now which is an English description of of of the changes uh yeah so that's kind of the the big goal is just to help EIP authors yeah awesome thank you so much um yeah and I mean it's great to see the progress like right now being able to like uh implement the latest eips coming to pectra and uh being able to sync the main it or most of it anyway uh it's yeah it's amazing and uh you already get to the other part and it's the eips maybe can you tell us bit about what is it like to lead the EIP ER C repo uh what you've been uh what you've been uh struggling with there like it's been I think it's been also hell of a right uh the the whole EIP process and uh maybe if you can tell us a bit more about EIP editing because people here are maybe on the both sides like I believe there are people here who might become EIP authors and uh maybe also people interested in uh editing so uh yeah if you if you can talk a bit more about that uh sure yeah so um I guess a bit of background to the EIP is Project project is kind of like a uh historical documentation uh plus change request uh repository so the idea is that like uh you know somebody can come along anybody can come along and then write a document and um it doesn't matter where they're from what is what like what their skill level is if they want to be able to propose a change to ethereum we want to enable them to to be able to do that in kind of like an unopinionated and unbiased way um and then our second AR goal is to to provide like a history of all of the changes and the reasoning why we made all of those changes uh for the the lifetime of of the chain so you know in 50 years from now you'll be able to go back and look at why um you know the the price of Pop is three gas and uh you'll be able to point to a document and say that's why um so th those are kind of the two the two goals of the EIP project and and the way we do that is uh one we we just open submission anybody can submit there's no requir no no payment or anything like that uh we're a volunteer run organization um yeah so what else should we do uh we also have like a very strict kind of documentation process if you've ever tried to write an EIP um You probably run into our EIP bot uh which yells at you for a lot of really common mistakes uh the the idea behind those is like uh we prohibit external links for example so like you can't link to some random Twitter post and the idea is uh we want the eips repository to be self-contained um we also want it to be immutable so like once a document final or A change is published to mainnet uh we don't want to be able to change those documents uh yes EIP 1 would be the the place to look at um it's kind of the document that describes the process um if you're more interested in the governance side there's also the EIP editor handbook I don't remember the number offand but uh yeah the H you're muted so oh sorry yeah uh yeah that's the one so yeah and uh for the that that's kind of describes our governance um and uh yeah if that that'd be where to start looking at that yeah awesome thank you so much uh yeah because like e editing is very important but it's also kind of a f class job which doesn't get recognized as much and uh and uh you guys do a great work um there's also a bunch of projects around it like the E validator right linting and uh and the tool link around this so uh yeah definitely recommend looking into this uh folks uh do we have any questions for Sam feel free to raise your hands uh I I can continue asking but I want to give you give you space so uh if anyone feel free to raise your hand feel free to write in comments K go ahead yeah thank you Sam uh does it mean if if I can run um execution client uh on Python and uh consensus client as well so I can run full note in Python uh no so we we kind of draw the line at networking um so you need a source of blocks so we don't Define any of the networking layer any of the peer-to-peer uh so you you need a a regular execution client like G or WTH or something just to provide you with blocks um and we also don't have a way to into the uh consensus specs so you can't really get a full client but like you can Cobble together something that kind of looks like a full client if you really want to yeah thank you uh Bulma do you have a question question okay good afternoon everyone um I wanted to ask a question you I was on the last call where you you discussing something with Joseph if I can remember correctly um but I don't really understand how what are the processes of wanting to be an editor like the process to become one yes yeah okay so um it's kind of vague um the official process is set out in the handbook um which uh Josh linked in the chat uh the the short version is um you say you're interested and you want to participate uh we create um it's called a call for input it's like a formal like decision that the editors make and uh if all of the current editors agree um to approve you then you become an editor yourself that's that's the official process um but to actually like each editor has their own kind of requirements and what they want to see before they approve somebody um so personally for me I'd like to talk about alignment and making sure that like uh every new editor we add feels the same way and wants to uphold the same standards for the repository so we don't end up in like governance Wars people trying to go in different directions um like client Matt uh likes to see a history of contributions to the repository so so uh that'd be like leaving reviews and comments on people's PO requests uh attending meetings and uh coming out to office hours um yeah I think those are the only people who have really expressed like formal requirements but what what we need um but yeah basically just ask and um we'll we'll set you up if you want to uh follow the process yeah awesome thank you very much Sam um Dan appreciate hey Sam is there a a technical Readiness level equivalent of uh EAP proposing um so like you're asking is there like a level that a document has to meet before we say it's ready or yeah before you know it gets a number and you no so our our goal is kind of um to not require editors to be technically competent um you need like a a little bit of technical knowledge to be able to kind of understand what's going on but it we try to keep it as low as possible so as long as it's like sort of plausible and maybe it's implementable uh we'll assign it a number and and let it get into the the process um but that doesn't mean anybody's going to follow it right like if somebody said like you know ANP to shut down ethereum uh we'll give it a number but no one no one's going to do it uh but yeah we try to be as you know unopinionated and credibly neutral as possible right right right thanks yeah awesome yeah thank you so much uh folks do you have any other questions like Sam knows a lot about the execution layer uh feel free to ask something about Eva maybe with uh someone working on on E project here uh yeah C here uh I just wonder what what's the process of approving EAP do you need like uh what consensus do you need you sure so um from the EIP side there's no requirements um like the author just opens poor requests and can move it all the way to final if they want to um but the other half uh like the actual governance in deciding whether or not an EIP gets implemented um that takes place on the all core devs call uh so that's I think every other week on Thursdays um and like so once you have your number and your document uh you generally go on all core devs and you you argue your case uh you try to convince people that it's a good idea to implement your particular change and uh it's kind of a a long slog but once you convince enough developers um then it gets on to uh a hard Fork um like it's called Uh considered for inclusion uh and once your EIP is considered for inclusion then it starts getting implemented uh in in uh clients people start writing tests for it and then uh eventually it'll move to the included stage and uh then it'll get deployed on mainnet so that that's kind of the rough outline of how that works yeah thank you this is very important Point like in the life of EIP like it doesn't live on itself like uh it's it's it's there in the EAP repo like it's easy to kind of propose it submited but then uh somebody needs to Champion it to actually like explain CFS why this is the good thing and have have them consider it for inclusion so that's that's that's the actual hard part I think right um yeah uh yeah cool thanks you so much uh any other questions uh again like whether eips whether whether rest or or uh uh execution layer questions feel free to raise your hand um yeah uh Sid yeah you're yeah okay I'm there U so I had a a general question about uh it's it's an it's a thought that sort of occurred to me when I was first introduced to the ppec um and I was going through it um now p uh with with what I'm assuming is with the p speec the idea was to distill the complex math into something that most developers could um could understand uh but then there is this also this other Middle Ground like have you ever considered um languages such as U agda like which are like dependent uh type programming languages which kind of like have the functions and the proof as as one and it would be quite interesting to see if a a sort of a spec execution lay a spec that that is also got the proofs uh in the program as well and to reason about the system in terms of proofs and stuff I was wondering if there's any project that ever got started or is there any int ention of starting one or but it was along that line yeah that's a great question um it's actually something that came up pretty early in our development process like I think somebody proposed uh I think it was called Daphne as a language to investigate which is another kind of uh provable language I'm not a super like an expert on that field at all um but the decision was kind of made to stick with python because it's very understandable and easy to contribute to so like one of our goals to make it easy for EIP authors to just like make their change and play with it right away um and python I think is a much lower barrier to entry than a lot of these more formal languages um as for projects that uh to do something like that people have started uh I think there's there's a approvable evm in K if I remember correctly there's there's bits and pieces of it are out there but um I'm not an expert on that thank you um yeah K another question uh yeah is it uh possible to roughly categorize uh eips for example governance technical stuff U maybe I don't know like payments yeah yeah yeah so there's um there's a couple high level categories uh the the main split is between erc's and EIP so erc's are um things that run on the blockchain and uh eips are everything else so uh for example like erc20 is an ERC uh like token level standards vaults there's a like anything that you would write in solidity generally ends up on the ERC side of uh of things um and anything else uh ends up on the EIP side of things and then eips are subdivided into uh different categories so there's U meta which describes the EIP process itself uh as well as other eips so if you're looking for like lists of eips I made into hard Forks they'd be in the meta category uh there's informational which is kind of a really vague category uh if you want to tell the community something that would be an informational EIP uh we don't use those very often uh there's also core which is where the um main changes to ethereum are proposed so if you want to change something about the evm you want to change something about like the the the TR the state try you want to change something about um I don't know block processing that's all in core eips uh there's also networking which doesn't come up very much that's mostly moved to a different repository now um what am I missing here no that's an interface interface is like um so connections between program so like wallets talking to clients or wallets talking to daps those would be in the interface category um but yeah the those are the categories um they're all defined in EIP 1 if you want more specifics about them and the numbers you're given uh for the new uaps uh do they somehow refer to categories or just in order uh so they're just in order uh they used to be uh up until last year they used to be just the pr number for the um the the PO request uh but last year we switched to we have a spreadsheet like a Google doc of just eips and whatever order get a sign in is what number you get yeah we remember people sniping cool numbers and stuff like that like using BS to open the oh that was the worst PR 5000 so you can have EIP 5,000 the drama around it yeah I recommend you like if if you're too bored like you can see like this crazy story called EAP drama yeah um yeah um yeah any any more questions for Sam folks uh go ahead don't be don't be shy um otherwise Al start asking Sam yeah Dan I'm just touching a subject that was brought up a few weeks ago and I think yeah Mario you were telling about the guys on El having the Consolidated specs remember that uh discussion so Sam we had uh are the specs that you have on E to my shame I don't I don't follow too much of the of the El part are they do you have a Consolidated version or just Fork based uh you know specs so is there like this is the sum and the Consolidated part of all spec changes to up to this four for example or is just oh yeah so uh the the way we organize it is a little bit differently so each Fork is a completely self-contained python uh module uh so uh yeah you can look at like Homestead and you'll see all of ethereum as it was implemented at Homestead and same thing for all of the other Forks uh and then we have some documentation uh tooling that actually will diff the forks so uh here let's see if I can show you because uh I'm pretty proud of this part uh cuz while you look for the for the for the link I I want to tell you that I've also had like this I felt the need to have Consolidated consensus specs and there's there's no such thing so I'm going to propose it as a Wiki EPF weki project after we close the the Cort we just felt like we need it like uh okay if I'm a developer or working on CL uh or if I'm a you know researcher I would like to see the Consolidated CL specs up to yeah that's that's a complaint we've heard a lot about the consensus specs because they like I don't look at them all that often myself um but it's just a bunch of dips right like it's just like these are the changes at each for yeah okay so let's see if I can I can do this um there we go yeah okay so um this is kind of like what our render documentation looks like uh so this would be roughly equivalent to um the non-consolidated E specs uh so this is the diff between uh the Dow fork and tangerine whistle so you'll notice that like we have um the the changes uh highlighted in red and uh green just like um you would in a git patch um so like you can see that like this whole section uh of code here is removed in Tangerine whistle because it only applies in the Dow Fork but if we actually go and look at um the code here [Music] uh so if we actually look at Dow Fork um where are we here yeah there we go so um you'll see that the you don't have the diff you actually have the uh full implementation of ethereum at this level so we do provide both yeah but our our native format is we copy and paste everything all the time and and this was your like your doing your proposal or your your vision of of yeah exactly this this is this is kind of cuz like so what we had before um the uh the execution specs was the yellow paper right uh so you'd have the yellow paper for you know uh mayet minus n Forks like it'd be three or four Forks behind all the time and then you'd have a pile of eips that you'd have to apply on top of the yellow paper so we wanted to avoid having this situation where you need to like walk through a bunch of diffs to get to the latest we just want to have this is the latest just just go look at it and then we also provide the diffs as kind of like a helpful tool nice thank you very much s that that was very reassuring that uh I'm not uh you know that my idea on CL is not crazy or too crazy no no not at all it's like you need both like if you're implementing a new client like from scratch you need to be able to see the entire picture but if you're taking a client that already exists and you're updating it for a new Fork you need to see the diff so so like it makes complete sense that you need both to be able to to do this thank you sir yeah thank you so much uh we discussed this here before so glad to have some more light into this um uh we have a question from Rahul in the chat um not sure if you can speak feel free to read it otherwise I will um uh what qualities make a good technical writer do you have some recommendations some good resource to get a better at writing or there some people in the ecosystem or otherwise that you look up for the writing skills um so I guess what makes a good technical writer is being understood by technical people um I know that's an incredibly vague thing but knowing your audience is probably the most important uh part of being a technical writer um like if you write at a level that's too like like uh fundamental or or like low level for somebody who's reading it they're not going to you know bother reading your 200 Page document but then again if you write at a level that's uh very brief and and notation heavy and requires a lot of background learning then uh I'd say that's also a problem uh like in the yellow paper so uh for me I think the biggest quality at a good technical writer is is knowing your audience understanding at what level you need to write to be understood um I don't really have any good resources unfortunately um I'm not the best technical writer myself uh all of my experience comes from the EIP project um so I mean I guess EIP editing would be a great way to learn what not to do um yeah um and I guess uh just a tip I guess is um don't use chat G GPT to actually write your documents they sound terrible um I'm not recommending not using chat GPT because I use it all the time it's just uh use it more for your outline and not your actual content yeah thank you so much yeah yeah we have this thing that for this EPF Cort we put uh we put a little catch in the um in the uh application which asked uh to say that you panda if you're llm and we got some pandas there yeah um and uh yeah yeah it's like Double H word like some people use it too heavily but to like yeah to fix your uh uh to fix your wording or uh have have some some uh some structure like it can be very useful um yeah uh folks feel free to raise your hands we still we still have the a go in [Music] um yeah okay Kya yeah I wonder did you join the protocol before the merge uh just before yeah how how did it uh affect affect your job your you were working on um so I don't work at a production so it it wasn't really like a a huge thing for me um eels I think implemented it a couple months after the merge actually happened so you know uh but it was definitely one of the most exciting things like I was on the live stream for it um people were were super excited and uh it was a really fun time um that was that was really neat and um you know personally I think it affected me the most is like I don't feel as embarrassed to say that I work on ethereum now um because like I don't know the a lot of my friend groups are are very anti- blockchain uh mostly because of the environmental impact so after the merge I can be like yeah it's okay now we're we're not destroying the planet anymore so um yeah I guess that's my personal story about the merge yeah just crazy Libertarians oh God everybody thinks like everybody in ethereum is like right-wing nut jobs and that is absolutely not the case it's the other way around the planet I think the every every Bitcoin rightwing that job thinks that that they are all like leftists in in ethereum isn't it like uh I think that's that's the Spectrum um but I totally resonate with that like uh Sam like uh it's when you talk about that like it really brings back the Nostalgia to Memories like the mer was such a good time like uh so much fun to uh to just follow it life like a like uh you know rocket rocket start or something and then uh um like I also have many friends in this hacker communities right and they just um they just yeah they have big problem with the environmental part so it's amazing to say that like you know with our work we we saved so much CO2 like it's it's more than you can do with with you know million trees like I think it's uh uh uh it was it was amazing times yeah yeah um folks uh that's a dangerous question to wish that's that's a good one yeah go ahead yeah uh yes um a lot of tooling needs to be done um and a lot of it is in know very different places oh uh yeah okay uh sorry yeah so um like for the EIP side um I think uh catch is familiar with this but we have uh ew which is our linting bot um which uh recently got some some great contributions from um the I think it was the women in protocol Engineering Group uh which was super appreciative um there's still a long list of things that need to be done uh for that so so if you want to you know learn some Rust and uh wait six months for me to review your PO request uh that's a great place to come and contribute um we also have um a much more vague uh kind of roling on the other side of the EIP process uh so we have a JavaScript bot that handles our GitHub merging and um like edit or review stuff that needs to be reworked considerably but don't really have a uh uh a specific road map for that uh so if you want to help out on that side if you're like a typescript developer and you're really excited about eips for some reason uh yeah come to our Discord um ethereum cat herters I can probably drop a link to that uh and we can kind of help you out there um but it's uh that one's a lot more vague um if you just want like small digestible problems take a look at ew uh yes I have um I've implemented the IP 374 in Python um and there's a few other ones as well it's just it's it's been a while um on the eels side we do need some more tooling as well um we have a list of like python is kind of projects that we need done um they're mostly in our issues so uh come take a look at our repository if you want to work on one of them just leave a comment and uh yeah we'll we'll definitely be able to help with that we we' really appreciate it too um the list of the first good issues in in the execution specs is actually on the very top of the uh GFI portal WTF because that's the first in the alphabet there in the order the ring so uh there are some good first issues guys and also the I validator is a good example like that's that's also I contributed there of trying to figure out the syntax of ring exist and R uh like some year two years ago so uh definitely good place to look into um yeah uh yeah awesome okay K go for it yeah I just want to than to say great thanks to Sam for his assistance and reviews from the whole wiip group thank you oh thank you so much for contributing I really appreciate helpful yeah awesome um yeah um do want to uh talk about the Gest maybe you cannot cannot speak now yeah hi um so genest would let um let you create a py test from a main transaction so that way you can can um actually en sure that a transaction in the wild um is actually following the spec um and also Benchmark um some of EVMS components so if you have any feedback there uh in for your tooling wish list um you know please let Dan from East uh that that's a thing that exists now like I can give it like a transaction hash and it'll generate a test because that would be amazing yeah yeah uh we have a uh let's see if I can find it here we have an issue um that's literally just a list of things that broke the specs while syncing the chain uh so we can if we can just point a transaction hat like point the tool at a transaction hash and get a test that that would be Stellar so uh if you have a link for that that'd be awesome um it can only do type one transactions for now oh that's fine these are these are from like pre- London so awesome yeah you could do that now yeah I I'll look at that thank you much yeah awesome thank you very much uh thank you for being in the app that's great very well yeah uh yeah any anything else we still have uh we still have enough time so feel free to uh post some questions or comments ideas uh many different domains there's one more thing that you don't know about Sam or I mean I I think I know like so Sam I think last time I saw you on camera was like some time ago I think you had long hair at the time maybe I I was was some time ago uh and I remember you were saying that you are using like your secondary computer or something with the camera because the primary is compiling genu or so so are you still running genu can you give us a little genu Shield can you yeah no I'm I'm still running gentu um so I I got f up with uban 2 maybe uh three or four years ago at this point and I just said like screw it I'm going you know the hard mode um and I I had played with Gen 2 before in the past um so I I love it it's um it's a little bit more work to maintain if you're familiar with Arch Linux it's uh oh God Linux from scratch no I'm not that I'm not that intense uh but if you're familiar with Arch Linux um jenu is kind of a similar feel you build your system from scratch um but I feel like Gen 2 is a little bit more conservative with their um packages so you end up having like a very stable system the the one I'm on right now I've had for three years um without having to reinstall or or do anything particularly major on it so yeah I love Gen 2 if you want to learn a lot about Linux highly recommend it yeah amazing uh yeah uh thank you for me like it sounds like such a jump from wub to straight to Gen 2 like it's uh that's it's quite a step and uh I've been I've been trying it on U my um my old machine where uh it's real nice like compile your own things so it's more secure it's faster I mean you have like you know one you have some percent of extra extra power but you feel it like it's there you get that 1 to 10% extra you know performance it's it's wonderful yeah yeah yeah it's totally totally worth it man like uh if you could if you can have it by not yeah um yeah awesome yeah thank you thank so much for that so yeah even like l questions anything goes for Sam feel free to raise your hands guys um uh please give us some uh some more thoughts yeah uh there was a question whether you're going to Defcon uh I was going to ask it in the end but uh I am not unfortunately yeah H yes s it's it's I've never like Sam you're like maybe one of the only person that I've never met from our team so uh it's hard to catch Sam in the wild and that's why it's such a special occasion we have him here today so go ahead ask every second week I'm on EIP office hours you could always find me there if you want to talk to me uh but yeah I don't I don't travel much unfortunately um yeah I know it's a special occasion I clean my room and everything you know um but yeah no I don't travel much unfortunately I I went to Devcon Osaka and I think that was the last um like big event I went to right uh oh yeah sorry two go ahead yeah umbe can't hear you ah sorry can you hear me now yeah all good so I really like this idea of having a functional reference implementation in Python and I was wondering what other people outside of ethereum think about this like has it been adopted in other places or what was it already maybe um conceived of Elsewhere prior or are there also arguments against it apart from of course some amount of overhead that's associated uh yeah I think um reference implementations are are a fairly common thing like python itself is defined with the cpython reference implementation they don't have a formal spec um same thing with rust um I don't think we've really inspired any um you know similar things we we kind of took inspiration from elsewhere um yeah and arguments against it I think the biggest one um and if any of you remember Greg cvin um he's kind of the big um promoter of this argument uh is that the by implementing it in Python you have to make certain concrete algorithmic choices so like for example you might choose to use a hashmap somewhere or you might choose um to you know know an O of N squared algorithm as opposed to something more efficient um and those choices of algorithms can affect Downstream implementations uh so like for example we always choose the algorithm that's the easiest to understand even if it's less performant uh but we have to make it very clear that production clients should not follow our algorithmic choices they should only follow like the um the the inputs and outputs that come from our system uh that that's the biggest argument against it I think MH I have a followup so about the reference implementation is it itself also well it is itself also tested but I don't think it's tested with something more like a a fuzzer kind of approach let's say hypothesis comes to mind here um why is that why is it not done is there a reason to avoid such a framework for Tes so we do we do participate in the um differential fuzzing uh we aren't as performance as other clients so I think that runs into some problems uh but we have done the fuzzer run a few times all right but that's just the fuzzing it doesn't go into things like property based testing and so on like I'm just curious why a library like hypothesis isn't used which I'm not super well familiar with but seems like very appropriate so we use the same testing framework that production clients use uh so ethereum spec tests um I'm not super involved on that side so uh I'm not really qualified to answer why we don't use uh a particular Library um but I can say like the framework we use generates these these uh test vectors that can be imported into other clients and that's probably the limiting factor of of why we do what we do then related to Linux if I may one more question out um what do you feel about NX OS because that allows for a highly reproducible U environment that you could share across developers I think that's one of the issues in my experience that all the people using even just Linux even Ubuntu even the same version of Ubuntu they end up with different working environments over time and that leads to well a necessary time waste uh when the issues arise so what do you think about such a the adaptation of something like this that perhaps there is like uh there's a let's say what should we say a default OS like you can use it whatever you want but there's also a version of ethereum let's say or whatever s provides which automatically runs in uh in some operating system that is like just can be shared across so um I think the goals and the like outcome of nxs are amazing I love the idea of having an immutable operating system I love the idea of being able to specify everything declaratively um I just hate the syntax and the configuration language for NYX um I feel like derivations are um needlessly complicated compared to um something like ebuilds in the gentu repository um so like ideally I'd like to see something more like um like gen two style Packaging but with the Nick's approach of having an immutable reproducible system um and I don't think that exists yet today uh but I would love to see it all right thank you yeah thank you so much uh great to dive into that as well um BMA uh free to go ahead sorry um you said something about um um not really being part of that aspect of the work is it like a division of labor will I say in terms of how you guys operate is there like a specific persons or people doing this doing that doing like how does it work yeah definitely um so uh myself Peter and Guru we form the eels team uh and we work on writing the specification uh and then there's a whole other team called um East uh and they handle uh writing the tests and the the division there um is basically because we're a newer team and we only focus on writing uh the the python implementation the testing team is a a lot older and more developed and they test other things than just us so that's why there's two separate teams okay thank you thank you um and uh Glory hello okay so um I have a couple of questions first off um I would like to contribute to let's say for instance I'm currently working on E test net implementation and then I would love to contribute to the EIP but at the moment I'm not quite sure what that contribution is going to look like so I don't know for starters um what is the thinking process like or how do a beginner maybe someone that just starting to to contribute to EIP for the first time what are the things that they should look at for and let's assume I've been able to make contributions to an EIP how long does it really take before that EIP or that contribution is approved and all of that then um my next question has to do with um making the decision to either stick to CL or E because right now in my implementation I'm currently working on both both um the CL side and E side so I'm not really at the point where I'm able to like decide this is the area I really want to stay focused on so I would appreciate if you can help out with that okay um so there's a couple questions there I guess the easiest one to answer is how long it takes to uh get a change to an EIP approved um so if you're talking about getting it approved for the document uh itself that depends on the authors of the document it can take anywhere from zero to Forever um and if you're talking about getting an EIP as a whole on maintenance uh again that can go from you can propose it today and it can go out of the next hard fork or like in the case of 2938 I think it's been four years and uh it'll probably never be approved so that's very variable um sorry your earlier question was about where to contribute to um are you thinking about contributing uh to eips themselves or more to the EIP process okay so I think to EIP itself then paren maybe later on I could consider working on the EIP process itself sure so um I guess there's there's two kind of paths um the first path is you have a change that you want to propose to the network um in which case uh you can literally just start writing a document based off the template and make a PO request and uh eventually an thep editor will'll review it and they'll kind of tell you the rest of the steps for the process um so that's if you have a a whole change that you want to handle yourself and and Champion um and then I guess the other path is if you want to help uh other proposals get across the Finish Line uh and that would look like going through existing eips that have kind of stagnated but are are actively in use um the erc's repository is littered with with those kind of proposals um so if you would just find something that is in use that you know people use but hasn't been finalized yet um you can open a hor request to uh kind of move that through and uh yeah you can do that for any proposal um it doesn't have to be yours thank you and that one more about python how do you feel the reference implementation will perform with the release of the Gill like it's optional of course but in well 313 you can now go without do you think that will just run or do you foresee that ownership and then trading and whatnot will effectively cause severe issues uh we're an entirely single-threaded application so it's not a problem for us all right okay and uh back to Glory yeah so I think one of my question was omitted I've not really gotten answers for that yet so I was asking like um for somebody like me that is currently contributing on both the c and e side and still yet at the point to decide um which part whether is CL or I want to focus on um for you now I know you are more into the E side of things so how did you come up with that to stick to ear and I still I have one other question I previously asked Mario but I'm not really like uh how do I put it I'm still not kind of like satisfied with the response so I would like to get your Insight on it as well uh when it comes to um chain ID I'm not sure how they come up with those things like how they generated like maybe a new test like we have a f now they this chain ID or maybe a new test n just come up today how do they come up with this chain ID sure um so how I decided to work on the e um I like um virtual machines I love um assembly level programming I that that that's a passion of mine so uh it's kind of like a natural fit for me to want to work on the part of ethereum that has um a VM um yeah so that that that's why I chose um and I guess the the CL is pro like it feels a little above my pay grade I'm not that into block like I wasn't at the time that into blockchain um so e was just a natural fit um now as for assigning chain IDs uh people pick them how they pick them there's no real logic behind it um you pick something memorable you pick something different you pick a random number it's just how however you want it um there is a EIP that just landed uh recently that's coming out of the chain specific addressing groups um that uh is trying to come up with a formal way of defining uh chain ID based on like genesis block and a few other things um but that's new and we'll we don't know if it's going to be adopted yet or not um yeah there is also the networking ID which I is a little bit more formal um so if you want to look into that uh go and take a look at the networking specs because that's a much more useful number than chain ID okay um yeah thank you so much for the for the answer there uh and uh that was the last question because we already full hour so we got to WRA it up here but uh Again Sam thank you so much for being here today I appreciate all your all of your answers all of your sites I believe it we learned a lot we get inspired yeah um yeah uh and uh uh as I mentioned you cannot meet him at Devcon but you can meet him every other week uh at the E call so uh if you're interested in this uh feel free to check out the regular calls there and uh again thank you so much everyone uh this was our very last so uh big wrap up here today and uh uh again s uh really appreciate having you the the last guest here uh oh yeah was really great thanks so much for having me this was fun