EPF7 Office Hours AMA | Shane

Transcript

recording is on. >> Awesome. Yes. So, uh now more officially welcome everyone again. Thanks so much for joining us today for the very first office hours call of the EPF7. Yay. We got the next cohort starting and uh we got our special first guest guest for the office hours call. We are uh starting a series of AMAs with well core defs from people from the core ecosystem and our first invitation uh got accepted by Shane from uh Lighthouse. However, Shane is also a fellow from the very last cohort. So we wanted to bring him because he's the person with probably the freshest experience of what you are just about to go through. Um so hopefully share some of that as well.

But uh yeah, so thank you so much for being here. Uh especially you Shane, but all of you of course. Uh Shane, let's get started. Tell us about yourself. Like I'm uh curious maybe just to get get some of your background, you know, to get people idea like uh maybe what you did before the cohort like how did you even get to the fellowship? How did you Yeah. What did you do before and what brought you there? >> Yeah. Been doing open source for maybe five no probably like six or so years now. Um first was with uh in the Cosmos ecosystem. I was working for a DeFi focused L1 called Injective. So like three years there doing um let's say a lot of bridging type work. Um and then at some point I figured uh better to

move into Ethereum because like bigger validator set more decentralized in Cosmos it's like maybe 50 validators. So if I really uh you know at some point want to kind of feel like we're able to really democratize access to finance globally uh then you should not only be relying on like let's say a few validators to secure your chain. That's just like how I felt about it. So I moved over I want to move over to Ethereum found the uh uh EPF program through one of my buddies started doing uh the study group and actually the interesting part is I was doing the execution layer the whole time. I made like at least 10 PRs to Wrath. Uh I was working on the um EPF like wiki like at least 10 PRs there all about execution

layer stuff. So I was like really all gung-ho about that. Um I even like started talking to like the rest guys about a project to do. Um it was called delayed execution. So I found a project or like that and then I get all the way to Khan to do uh ECC. um going to get and then at while there I present like hey so I'm going to build on ref and then um they kind of mentioned like oh there's a part of delay execution that would be good to build on the consensus layer like as a proof of concept so I got in touch with one of the lighthouse guys and while I'm there one of the licens guys is like oh your project late execution is going to pretty much be killed by this thing called epbs it gives you the same like

scaling benefits and if you want you can come like help us work on that. So I was like, "Oh man, do I like keep on like doing RAS and working on this uh project that may or may not work out or do I uh switch over to consensus layer and do EPBS stuff?" And the more I thought about it is like I don't know when like chance like comes your way like take advantage of it. you know, if like a core dev from Lighthouse says like, "Come help us with this like potentially like big project that touches like the entire consensus layer," then uh I felt like the answer was should be yes to that. Uh so anyway, I started diving into consensus layer and I'm like pretty lateish in the cohort at this point.

It's like we're like a month in at that point. I already wrote my uh EPF like project proposal. Like I'm doing ref stuff hardcore, right? Uh but anyway, then like I started slowly doing more consens stuff and then e like EPBS got did did get picked as the um headliner for uh the Glamsterdam um like network upgrade that's coming up pretty soon fork and uh luckily that happened so I made the right move but there was definitely some chance involved there right like oh what if it didn't get picked as like the hard fork then like I could still have done EPBS stuff um but yeah these are these are things where it's like there's a lot of nuance and like navigating that you don't really know like where things are going to go.

You're just building and trying to um do something that you think is going to be useful, important, like helpful. Uh and I think that is like probably how I ended up where I am today by, you know, accepting chance and also trying like building [ __ ] I guess. >> Awesome. Uh well, thank you so much, Shane. I mean, you get through uh a lot of things there. uh like that you mentioned all the project uh choosing dilemas and dramas because well as you can guys see it's not easy we are just now in the face you know people are just looking around starting their research slowly choosing their project so it's a I think it's a good example uh you know we wanted to work on red but had to

pivot but it ended up being great benefit so uh that's I think a good lesson to like really analyze uh what you are working on uh guys you know not overcommit to click quickly but I think you will more more about the EPF experience later. I just maybe we could just jump to the present a bit like we are going to come back to uh the experience. I'm sure guys will have a bunch of questions about that. But what about now? What are you working on today? I'm curious. What are you up to these days? How is the lighthouse going? What sort of priorities? What's some sort of cool work uh in your like life as a core now? Yeah.

>> Yeah. Uh good question. So over and um so I work at Sigma Prime now which like is the one of the more bigger maintainers of Lighthouse and also uh Sigma Prime has like at least a couple other projects. One is called Ankor and Anker does like distributed valier technology. You can think of it as like in the consensus layer you have a validator client that's attesting to duties like attestations or making block proposals basically signing duties. Uh this anchor project is basically a distributed version of like a consensus layer validator client. So I'm just thinking purely about and that's like what I work on. I work on uh everything related to what's basically a validator client signing of duties. Um and we are making uh significant um upgrades uh

what's related to EPBS right now because that changes like it adds new duties like this thing called proposer preferences block uh signing is now obviously changed because the payload has been decoupled from the block. Um so it's pretty big effort. I mean to answer your question, I'm basically still doing EPBS just with a very strong focus on the validator client uh is a fun way to look at it and yeah like upstream PR lighthouse because I use them as like a dependency as a crate it's like rustbased project as anchor uh so anyway it's still really fun I mean it's like it's probably been about a year since I got went down the EPBS rabbit hole and like we're still on it uh and yeah it's really exciting the value client is like

um pretty broad ecosystem you know with folks like Lido and like we think about also like the block builders like Titan and those types of guys like blinded blocks um or like going away these types of things are like what we are navigating. Um so yeah I mostly focus on valid air client I guess is a in a nutshell. >> Yeah that's awesome. Yeah uh very well. So like I mean that's incredibly important like it's like the you know lighthouse is basically the BN and the VC right? So like you are a VC now. I hear that.

>> But yeah, working on the very important piece there. Uh yeah, that's really cool. And EPBS it's still going. I think that's like uh just to like give some context. I think you're very lucky there like uh in a sense like uh starting something in the EPF and basically still a year later now like you are the EPs guy and the client. >> Incredible trajectory but also like uh yeah was very lucky there at the at the beginning of the fellowship. Awesome. >> Yeah. No, totally. And still some still some stuff like uh in like the beacon API space like beacon API is what connects the validator client to uh the beacon node. So I've had a couple of the like EPBS like API modifications. Not a couple actually literally all of them uh

related to EPBS merge for the beacon API. I still have a couple that are open related to like block proposing. So that's just another way you guys can get um like into like core development besides just working on the clients. They have these other open source repos that kind of connect clients, let's say like a valer client to the beacon node. That would be the beacon API. And then there's like the builder API specs that connects like external builder to the beacon node. Uh and then execution API, right, that connects uh the like uh consistent layer to execution layer, right? So there's these other specs that you can kind of figure out a way to like niche into as well. Uh and it's good to understand and build on them. Like for me, I realized that like EPBS was coming. I had to like work on it during

the cohort and there were and I went to make some changes to the validator client and there was no way for the valad client to talk to the beacon node. So I was like oh that means I have to go modify the beacon API. So like during the cohort I just made this like massive PR to like uh add all the new endpoints and modify the existing ones. So I was just like you you're not always told like what to do during your cohort, right? You just kind of figure it out as you go. And just that one like change was pretty crazy because I mean the spec I wrote for BK API then gets implemented by all the client teams not just Lighthouse but like also like Nimbus and like Loadar and like all these guys. Um so that was really like one of the more

like cool things. Uh was not told to do and figured out I needed it and then ended up being like really cool um contribution to EPBS for like all the clients which I like best. >> Awesome. Yeah, thank you so much Shane. Uh that's great. That's a great advice right there. I think you you know really what you're talking about. So maybe like to ask one more question before I open the uh open it to the audience. Uh just wondering like so looking back at a fellowship like what is some uh knowledge that you wish you had at the time? Some advice you give to yourself you know like what you wish you knew when you were in these shoes like starting in the first office hours a year ago almost. Yeah. Um do you have anything you look back at too like uh uh

to yeah prepare yourself for the cohort maybe now or like looking back like what changed since then? >> Yeah. Um things would wish I would have known like at the beginning. I just think trying to decide your level of involvement in like your project is going to be a pretty is pretty significant and you're not going to like all it's not going to be necessarily defined by your mentor. A lot of it will be you having to try to like figure it out as you go. You don't know when you start like okay I have a mentor like are we going to be talking async a lot of the time or are we going to have like weekly calls and that honestly is just going to depend upon uh who your mentor ends up being and what kind of communication style that they have and

there might be like months where they have no time to like talk to you because they're working on like let's say the epbs like uh sorry the new hard fork right like saydam for now uh and then you'll just be at a point where you have to try to figure things out as you go and yeah the advice like I kind of have there is like progress beats perfection. Um just like pick a path and iterate on it. Don't just like spend so much time thinking and like going down like thinking up different designs like pick you know at least something to where you can start like building on that at least so you have more stuff to show during the cohort. Um I think like earlier on it can be um you might think like oh I should spend a lot of time doing like

let's say lots of research for the project and I think earlier on um I if I would have known this it might be better to just do more PRs. Uh and that's kind of the path I ended up going down like relatively quickly but I could have started even sooner to just kind of like start making contributions uh to the project. Like in the end, I think I got like 20 or so PRs to Lighthouse and uh that speaks a lot of volume because that's how you're getting like to know the team better. My favorite communication style is to talk on PRs. That's like you know a PR discussion is probably the best. Uh when I started at Lighthouse or I guess let's say Ankor um I was on a team with like three or four guys and I never had like a direct chat

with one of the guys until you know a month later like a one-on-one call. But before that we just only talked through PR reviews and that was beautiful. So uh it depends on you know you as person but um other like types of tips are just like when you're at let's say the conferences like uh Mumbai or which would be like uh DevCon uh yeah definitely go to as many events as possible that related to like core dev related work um go to talks and like reach out to people. I think that is a great way to like meet people in real life and you'll see them at like future conferences and you can keep your like foot in the door that way. Um, I think it's useful to stay involved to some extent like on the ETH R&D discord. Um, if you have like think about things that

you can contribute to like whatever you're working on on a thread that's related to your project. Uh, if you can go to like breakout rooms related to your project. Um, knowing these types of things like kind of you get a lot of alpha for one from doing these to understand like what are spec changes because you know I was working on EPBS and it was super in flight. you know, the consensus spec is up updating pretty regularly. Uh, and I could either be like very reactive, like only be checking PR changes to the consensus spec repo, or I could be involved in the conversations in the breakout room that like led up to those consensus spec PRs that would change the spec. And I liked the second one where, you know, I'm involved a little bit earlier on and there were times where I actually was

able to like make contributions to the spec itself. like I at least one PR to the consensus spec from like having these conversations in breakout room and it was more likely to get merged because we talked about it in advance. I got like you know some pre-aggreement from some of the guys. So there's yeah a lot of alpha from kind of being involved to that level. Um yeah I think like just yeah the more you can do of that type of thing will probably help. other advice that like I didn't really know is from like talking to other guys um who have done cohort uh maybe it is not that you get onto a client team like immediately it could be that um it could be like a year later uh this is and I've like heard this working out from like some let's say guys like on Nimbus I think

one dude did um EPBS for Nimbus like two years ago and uh he just like stayed like in communication with the Nimbus guys you know still did open source for him I think he like tried to meet up with them at other conferences is and then when EPBS became the headliner, he got on as a core dev over there. So, uh you just don't know like where the serendipity is going to lie with having done the EPF program and like when or how things might work out. You just want to like increase your chances as much as you possibly can throughout the cohort. Uh I think that would probably be advice I would give to myself uh earlier on. I guess >> it was a lot of mix of advice, man. Like many different things actually. Thank

you. I think it's really great. I think you also like sort of recapped a bunch of stuff that we recommend earlier uh but like much more specific examples. So that's that's really great. I appreciate that like yeah uh you have this this view and guys like please uh now it's your time like uh uh go ahead and ask your questions. I mean I I can keep chatting with Shane. we can uh we are old buddies all day but like uh I would like you to meet him as well. So please if you have any insights into you know what is it like going through the cohort or his work right now if you have maybe similar project going on uh tech so whether it's technical question or or anything else feel free to raise your hand or write in the chat if you cannot

if you cannot uh uh use your mic and Marco was first go ahead >> uh hey guys so Shane I wanted to ask you about the PRs that you mentioned because you mentioned like making a multiple of those during the report. Uh were there were they like something related to the PBS or it was just like generalized contribution whatever comes up? >> Yeah, good question. So um I think what you're asking really is like should you be making contributions to the consens say the client team that you are interested in potentially outside of your core project.

>> Yeah. And the answer is it depends upon the size of your core project. If you pick something that's like a massive undertaking like EPBS, there's no way in hell I would have had any time to like focus on anything besides uh EPBS PRs. But if you pick something that like you think you could maybe do in like a couple of months, uh then you're going to have a lot of free time during the cohort to like yes, just like hammer more PRs. You just go of course into like their issues tab and since the team knows you, you're much more likely to like be the one who gets the GitHub issue because of course is super competitive to like get to be able to do free work for these guys, you know, which you know I've done like in the certificate. I mean I remember for ref

like I had a bot going to be able to like let me raise my hand first to be able to get like a open issue, right? Um but that gets like easier once you get more familiar with the team. Um but yeah, it's answer it really just depends upon the size of your project. If you're working on something massive, uh, then you don't need to do like extra like PRs if you don't have the time because you're so focused. But also depends upon your project. Like if you pick a project that's very, let's say, experimental and um it's not like an EIP for example that's slated to go to production anytime soon, then like you're basically working on stuff that is not um going to be merged to their main codebase anytime soon. In that scenario, I would probably

recommend doing some like PRs on the side. That way, you're like engaging a bit more with the team and like doing some like actual uh let's say code that's going to make it into production eventually. Uh I think that's like how I would approach it because you're just trying to gain more visibility, right? Like more devs on their team will review your stuff. But if you're working on something again very experimental like let's say ZK stuff uh then it may be that like no guys really get to see it too often except for like your mentor and yeah I think that would be my advice depends on it depends is the answer.

>> Thank you very much. That's that's pretty useful. So you do you also think that like building a piece of the architecture that is supposed to be used soon is like better than making some sort of a as you said like experimental hypothetical project that's like god knows like if it will ever enter the codebase and such. >> Yeah, good question. I think it depends a lot on what you're trying to get let's say out of the cohort where you're at in terms of your like um professional career. Um because like lots like whenever I was in the core like lots of guys were let's say like still in college or like grad school and I think like for them it makes a lot of sense to let's say work on something very

experimental uh because they even have a lot more time before they even graduate. So they're not even necessarily looking for like a full-time job like immediately after cohort. Um if you're trying to um let's say like land something sooner then I think like working on something relevant is good. Um because yeah, you get like more of a visibility with it. And the answer is really though, like you got to probably work on whatever you find actually interesting. Like if it came down to you see like three projects on the board and you're like very interested in one that's like pretty experimental experimental like uh ream stuff for example. Uh second one that would be like okay this is something the clides might actually implement. uh between

those two like you're going to work harder and more dedicated on the project that you're more interested in and in the end you'll have like mentor no matter what and they can champion you if they think you're smart and you're doing a good job. So like you don't need like all the PRs I just mentioned to the main codebase like as long as I can tell like oh you're you're doing interesting work. Uh this is useful like at least from like um getting data from like maybe we go in this direction in a couple years. I still think it's good. I wouldn't tell someone not to do that. Um yeah that also is I think you I think in the end like you kind of follow interest and it also comes down to like the code bases you're familiar with right like if

you're uh more like go oriented then you would pick something let's say like prism and then you' be looking through what are the projects available on prism and I would say yeah pick like whatever is maybe something that's more in your wheelhouse like you've done a lot of like database work and they have database project that would be good um at the same time maybe you're just like you want to learn something new and the cohort is a way to do that. So then you're like, "Oh, great. Um, I'm going to go use this opportunity to like get really good at CK and then because I know on the straw map that that's going to happen within the next like year or two." So you can position yourself that way. And the experimental stuff can lead you to a job later because if you think

about it like they are going to implement let's say most of the stuff that you guys are working on at some point in the future and you'll be like spending the time during this grant program becoming a subject matter expert in that particular space. Um and therefore like whenever they might need you like in a year or two from now to like you be that guy for their team because they'll remember you. Like I kind of gave the example of the guy who did EPBS like two years ago and then they remembered him because they stayed in touch and then they needed him then. So you don't you don't know like how it's going to go. That's why it's like probably the safest thing to pick whatever is more interesting uh to you I guess because yeah you'll do better at that.

>> That makes a lot of sense. Thank you very much. >> Yeah totally. Yeah, that's that's generally our advice just like you know think that you do it for yourself and you do it for Ethereum not like for a specific team or for like finding a job but uh I think that like um yeah Ethereum should be about like all the interesting opportunities that gets you excited right like what really drives you what gets you excited is where you have the the motivation which means just like the ability to do the job right to uh think creatively in that field right because that's where you feel feel comfortable where you feel excited Um, the question.

>> Yeah. Uh, cool. So, uh, I was interested by your, yeah, your points on opening Pors and, um, I I guess I was just curious like, you know, early on in the cohort, you're still sort of scoping projects and trying to understand them. Uh, like at what stage did you think was the right point to start opening like Pors? Because obviously you don't want to come in with something that's sort of like half thought out and like won't be received well. So like how did you strike that balance between like okay I'm going to start like opening people to discuss this but it actually has to be something that's like um well thought out like how do you sort of gauge that?

I'm curious. >> Yeah. Um so if you were to go to like the first project I was working on which was this late execution thing for ref. I'd already been like trying to tackle open GitHub issues on their repo from like since during the study group like the beginning of the study group. So I knocked out a bunch that way and then uh I whenever I got into a cohort then I committed to the delay execution project. I think like up until the um let's say like UCCC like presentations of the project at that point I was just I think I maybe made like a local draft of a PR to like start implementing the EIP. Um so I just spent a lot of time doing like research trying to understand what is delay execution and how would I

implement it in ref. Uh but then you know like at UCCC I go I I figure out oh I should pivot to Lighthouse then I have to spend all this time trying to like learn EPBS uh enough to like make a first PR make a plan because like in your um like project proposal you're kind of saying like a bit of a timeline like first month going to probably do this second month going to probably do that. So I'm like well normally it makes sense to build data structures first. So uh I figured out like what are the new data structures in EPBS and like what do I need to understand to like build these into Lighthouse uh and I wrote I would say like I write a like a post on it on HackMD um you know obviously like your weekly post uh but like also in that

weekly post I'm using as like basically my scratch pad of this is what um I plan to make a modification in my PR and also it would be like or a lot of times like this is the PR I made and this is why um to help remind myself here. So the answer I think is kind of like as soon as you feel comfortable to start uh making PRs, I would totally do it and you don't have to even make it necessarily to the like upstream repo like let's say uh Prism itself. You could uh make the draft PRs like in your local like your fork uh repo and then like start building on that to see if it makes sense because you know you don't want to make like huge 3,000 line PRs.

you're normally trying to build iteratively, which means you might want to be doing stack PRs. So you build like some data structure, then another one on top, another one on top, another one on top, and if you feel pretty good about the direction you're going, then maybe you'll like upstream the first one, for example, if you think the client team like is in a space to where they're like willing to accept it. Um, I mean it might be the entire cohort where they don't accept any of the PRs and then you just have like a bunch of draft like stacked PRs in your uh personal repo until they have the like bandwidth to start actually reviewing them. There's just no uh guarantees on their time and their energy. Uh, but I would say build sooner as long as you have like a plan you're pretty comfortable with and

understand. >> Okay. Yeah. No, that's pretty interesting in terms of like your your approach to like creating yours and um Yeah. I know that that is interesting. And for with ECC, were you uh pretty far into the cohort at that stage or like was that like early on for you? >> It was like when you guys pick your projects and you're going to like like present it to your peers. So maybe a month in I think >> uh yeah this is something that sort of changed like sorry uh you guys don't have a context on that but last year we basically finished the phase uh two of the cohort like this first month uh by meeting at etc some of the people or most half of the cohort but now the etc

had a different timing like there is no conference in summer. Yeah. Yeah. Yeah. So like the the situation changed a bit like I mean we did it actually just like one or two times and before it was like this. So the idea is that after the first um after first uh four or five weeks we start doing presentations where people already have prepared their product proposals. So that's exactly this first bunch of research after which you have like uh some real specs some drafts some proposal ready that you want to execute and that's what you present. uh so we will uh present it online and some folks last year had a chance to present in person as well. Um but like yeah that's exactly the sort of time when like by the end of the first month

having the draft having something to start working on and drafting also the PRs and working starting to basically execute exactly around the time. So you can see bits through the phases as we outline them like it's something that like generally works you know of course like it's very individual I think very many many things that block that Shane says are true but like uh also like you know can uh you can be a very different case depends on what your what's your project so uh but yeah is very very very much right uh you got it correctly I was worried you're going to say something like first week you just uh uh uh you see all but uh yeah that's great uh exactly No certain time to research.

>> Yeah, totally. Got to understand before you build. Uh especially depends upon the complexity of your project as well. Uh if it's a domain that you're very familiar with, you're of course going to spend like much more time like diving deep down the rabbit hole uh in advance to like get more familiar with it, which was the case uh for me. You know, I ended up switching to consensus layer and then I was like a whole new world. >> Yeah. >> Yeah. Fair. Cool. Yeah, it makes total sense. Um, yeah, thanks for answering my questions. >> Totally. >> Awesome. Uh, yeah, thank you for questions, guys. Do you have any more?

Feel free to come and chat with us with Shane. Uh, do you have any any hands to raise or any questions in the chat? Feel free to post something. I hope I we still have you here. >> Okay, Christian. Yeah. >> Hey, go ahead. I ask um you mentioned that progress beats perfection. So I guess towards the program you got stuck sometimes maybe and I was wondering how did you manage to get stuck through like maybe discussing to a mentor somehow or through other like strategies?

>> Yeah, good question. Um I would say like there are multiple times where the consensus spec would change related to EPBS and that would mean I would have to like a understand like what was the change and then how would I implement this change in lighthouse because you know it's a Python spec and then how to build like in Rust can be like very two different things and also like maybe it's like a cache value and you might think like oh do I still leave it in a cache or do I like need to um write like a completely different cache because the block and payload have been separated.

Now there's many like edge cases you think through and um sure I guess you could try to uh talk to your mentor. It just depends on like how available they are. Um mine in particular honestly like was not as available for like a good bit of the cohort. So I kind of just had to pick a direction and like roll with it. Um, and that was kind of scary, I guess, cuz you're of course not sure like, oh, like am I building it now in a way that they will actually like approve later?

Um, but it unblocked me from like moving forward with my implementation because you have a project proposal and again it's like it has a timeline and you're like okay I have like four phases and if I'm in phase two and then there's like some change to the consensus spec because there's changes all the time still me keep moving forward with my milestone to like get to like the third and fourth stages. So um that's essentially what I would do. I would still like build stuff. Um, and like it was kind of the example I gave earlier where uh I had to like modify the validator client for EPBS, but there was no connection yet for like the new endpoints uh from the beacon node. So then it becomes like oh this is like a beacon API problem. So I need to go and

make a PR to beacon API to like unblock myself so I can then build the endpoint based off my beacon API spec so I can then implement in the validator client like the new uh functions I need to. So that was a way to unbot myself um as like in particular. I could have just waited and hope that somebody else was gonna like implement the EPBS like beacon API spec because eventually someone has to you know but uh I just did it and I was like oh I mean that wasn't on my like project proposal plan you was like this might be a twoe effort to like like detail 10 new endpoints and understand the spec but it definitely seemed like a very valuable thing to do and necessary. So I'm happy I chose that direction. Those are the tough decisions

like do I keep going down and maybe make something hacky or do I do the proper fix of like making the the real spec itself um I think is like a pretty good example and you can kind of get let's say I don't know you're building a new feature onto the the client and you think of like ways it could be optimized and then you're like oh do I spend the next week or two thinking about like this optimization to let's say like again like caching something caching some value um or do I just like kind of build the more like bare bones version so I can like keep on moving forward? I think the answer is normally like keep moving forward because the client teams in the end are going to look and like think about ways also to like make

things more performant like later on. Um, and you can propose ideas like, "Oh, okay." Like, or you can ask your mentor at that point, but hey, should I like pivot and make this cash right now or should I keep on like going down to like keep on building what I'm committed to? And that'll help you kind of like gauge, but they don't always answer. And then you just have to pick. And in my opinion, it's like pick the things that will like unblock you as opposed to like the fun side project. Yeah, I guess. >> Okay. Yeah. Thanks. Chris has a another question. Go ahead.

>> Oh yeah, sorry. I was just going to ask um so my understanding is you had like a project picked originally and then you pivoted. Um I was just wondering like sort of um how you decided the it was time to pivot and um like how you found that change because that's obviously pretty difficult when you're like a good bit the way through the cohort. So um yeah, I'm just curious like what brought you to that point where you thought you needed to pivot? Was it like sort of a natural evolution of of sort of the work you'd done up until that point and you just saw EPBS being a really good uh opportunity to to try and lean in the direction of or just what what brought you to that decision?

>> Yeah. Um many factors and some of it was a lot of chance and luck um since I've been doing like uh the rest project for delayed execution. I mean like I was even in like a telegram group with like guys from so I'm getting like some engagement here. A couple guys from the EF were in it as well. I was like, "Oh man, what a like cool opportunity to like, you know, talk to people this way." But you could just the vibe from like the AC/DC calls and uh just across the board was like EPBS is going to win. So I was like uh like that's tough. But the trick is we didn't know if it was going to be the headliner for Glamsterdam. It could have been six sixsecond slots for example. And then the design space for like EBS versus delay execution would have stayed open

even longer. So there's all these hedges that you're not sure about. Like if they would have gone towards six seconds thoughts, then maybe I would have stayed with delay execution because it was just so open. Also, Lighthouse would have dep prioritized building EPBS if like six seconds thoughts would have won. So like they wouldn't have really cared about my work on EPBS anymore at that point anyway. So uh I basically figured I'm going to hedge I'm going to build like parts of delay execution. Um and then I'm also going to build like actually snow. I'm going to build parts of lay execution. I'm going to study EPBS as well. And then like luckily uh sooner than later they made the headliner commitment to EPBS for Amsterdam. And it was early enough early enough I think to

where I felt comfortable enough making the pivot. If they would have made that announcement like I even like two weeks later than they did, I probably would not have made the pivot because it would have felt too long. You can't like waste so much time in this very valuable opportunity you have of being in the EPF program just like waiting for all these like external decisions to be made. it just kind of luckily worked out to where they didn't like delay the decision anymore because they kept trying to delay the decision like ah we don't know we don't want to pick the headliner da da then one of the lighthouse guys actually was like okay like when you look at all the um like what people are preferring all the client teams want eps there's enough community support for it like can we decide on this AC/DC call

and then in the end they did make the decision uh but it could have gone over two weeks and I don't know if I could have waited that much longer so um yeah because again you want to be like making contributions building stuff But also, I didn't want to build like a completely dead project. So, >> yeah, >> there's like there's value in it, too, right? Like you I would have learned a lot. I would maybe built like more connections with Ref guys, but I don't think they would have reviewed my work because they would already known that like EPBS was going to be the headliner. So uh >> yeah, there's that. And like I knew that if uh EPBS did win then Lighthouse would care about it and the work that I did there would be reviewed and they would also um on some level like be in

communication with me to um you know get to know me a little bit better as we are trying to uh like push this over something closer to a finish line over time. So yeah it was it was hard super hard decision. I've had calls my friends about like oh what do I do? You know I'm like very nervous not sure. Um, I'm hedging. That's why I said I kind of like started doing both at the same time, which was not ideal, right? You want to be spending all your time on your grand project. And I hope none of you end up in a situation like I did because it's not perfect, right? Like you obviously rather just like pick your project and like kind of just roll with it. Uh, that is the best case scenario.

Um, but you know, oh well. >> Yeah. No, no, it's it's it's super interesting just because Yeah. like there's loads of interesting projects, but actually making a call on how to move forward is is pretty difficult. Um because as you said, like a lot of things are moving and changing all the time. Um so it's hard to sort of um I guess anticipate and marry like what you find interesting with what's going to be relevant. So um no, that's just super interesting example. So yeah, thanks for that. >> Yeah, and check the strawmap.org. You can kind of see like what's on the horizon that is kind of be able to tell you, oh, this is like an important project. And the fact that like all the projects that are on the board are like created by the client teams, right? Like if it says grand, it's like granddeed

wants this, right? If it says Prism, it's like Prism wants this. So there is value in these projects. The delayed execution one was like I like pre-negotiated this with the ref guys because like I was doing so much open source with them. So we're just like talking in Telegram. But like the best case is you already know that like if the project's on the board that like it's gonna be useful. So I I mean if you can I would recommend just picking project from the board. I went like off off of the board and this is what happened to me, you know. I mean, it worked out in the end, but there was like a lot of chance involved there. Probably should just pick the project from the from the project list, you know probably.

>> But, uh, anyway, yeah, that's my advice, I guess. Like the the project list is stuff that the client teams actually want. So, it's like, dude, you're already going to be like on some level good. They care. They put it on there for a reason. You know, Mario and like Josh, what do you guys want? This is what they want, you know? Yeah. >> Yeah, >> that makes total sense. Cool. Thanks for that. >> Yeah. >> Yeah. Thanks. Thanks, man. Um, yeah, please just do what excites you. Don't try to strategize too much. It's not good to stretch in Ethereum. EF, another great example I actually did earlier uh during a call uh before. So yeah, um uh uh we can follow the forecast of course for all the current stuff as well. Um Denin has a question.

Um yeah so you've touched on question a bit right but um mostly how do you manage to keep track of the simultaneous development across the whole domain right both as a core dev right um so as you know even within consensus and um execution there a lot of like domains within it and um there's a lot of like spec updates and all that and um even recently with um the builder separation and all that. How do you manage to keep up with the with the updates and um you know it's quite is a fastpaced um domain itself. So how do you manage to keep up with the update across all of these um domains itself?

>> Yeah, good question. Uh and this is a problem for like a lot of the core devs and also like people solve it in various ways. Different client teams do it differently. Uh for me personally like I use kind of like a R&D EPBF channel as like a source of screw and I basically spend all my time in there. I don't really like has to broadet and try to check out the other uh DD discord channels because then I would lose a lot of attention. Uh for example, I'm not thinking about Hecatar at all. I'm not thinking about like uh RE stuff at all.

I'm very much yo I spend my time in the EPBS channel. So laser focused on that. When I'm looking at like consensus spec PRs, I'm filtering for is this EPBS related or not, you know, uh very just like this is my thing that I'm cared about. You can't um there's not enough time in the day to like try to stay on top of all the things like if but you need enough context to understand if like let's say another EIP is going to impact the part of Ethereum that you care about and that you're focused on. So that's where like again like also listening on the AC/DC calls uh is interesting because they talk about stuff before they even maybe become a real EIP and you could think about like is this going to impact EPBS in my example but it could be anything um for

you. So yeah, I think just the best thing is to stay relatively narrow if you can after you've built enough context to know what is narrow for you. I think the what is it like the T-shaped thing where it's like you have a really narrow focus but then you have like a good breath of like knowledge of the other stuff. So like understand consensus layer well enough to understand like is it relevant to the part if there's a change in this part of the consensus layer is it relevant to like what I'm focused on which for me now is the validator client. Um, so yeah, I guess hopefully that answers your question, but I just wouldn't recommend spending like trying to know everything all at the same time because uh you might get there after a few years, but I don't know.

Yeah. >> Yeah, good. Thanks. >> Yeah, very well. Thank you. Yeah, we had a question uh also in the chat specifically about like getting into Rust and the consensus layer. how to actually start contributing properly instead of just continuously diving into specs. So yeah, what is your yeah more hands-on tips like how to start your contributions? >> Yeah. Um PRs uh I think is like the best simplest answer. I know it's hard because when you are trying to like grab an issue from a client team, there's so much competition normally for getting it and then uh if you do get it, that's

your opportunity to like practice Rust. But you should already have like some understanding of how Rust works by like playing with it and like let's say reading books about it. There's a good um Rust book called Rust in action that I really like uh because it's distributed systems plus Rust at the same time and you get to learn kind of like both concepts if you haven't done much much distributed systems work. Uh then of course there's like the rustling book that's uh available online but it's just like you know the most typical thing but yeah you should understand like how rust like kind of works so you can do it safely and then like you know while you're learning Russ you can be doing the PRs to like any client team that is Rust based like Grand Rouse um they have like Ethrax now um and yeah

I think that's as far as I can remember all the all the rest based Yeah. But anyway, yeah, I know it's I know it's hard to like just jump in that way, but I think PR is the best way to learn because you're practicing it. I mean, you can build your own little projects, but uh yeah, I think like that is also useful. Um if you're like trying to learn more async stuff, learn Tokyo. Like I'd say like async runtime. Tokyo is very very useful and important. um can't can't elaborate on that enough because most things that we're dealing with on the consensus layer is like async stuff, you know, messages coming like across a slot, right? You got to be able to handle them performantly. Um so yeah, hopefully that answers so respect, man. Yeah. Awesome. Uh Jeff

has a question. Yeah, go ahead. Uh I just have a question like it's a more more about personally. Uh I'm curious like which part of this job brings you joy or what excites you doing doing your job? >> Yeah. Um so I'm very missiondriven type of person. uh thing that drives me is called is it basically democratizing access to finance globally. I want anyone to be able to access financial instruments. I think Ethereum is probably the best place for that to happen. So I'm happy that I got into the Ethereum space. I think it's the chain

that has the best chance at it. Um and specifically within the like valator client work, it's a cool distributed system. Um I like doing Rust. I like that I get to like be thinking about the latest and greatest in Ethereum. How are like new hard forks going to impact me? There's like always some challenge. Uh I think that like I know people at Sigma Prime are all smart and interesting people. So it's cool to hang out with them. Um and yeah, I have, you know, DPF cohort to thank for this opportunity. >> Yeah, glad we got you the gig, man. Um >> cool. Um yeah I think that's a uh that's the main thing like I mean uh uh you put

it one way about like financial access right but like there are many I think many use cases to Ethereum and for everyone the uh the uh uh reason can be different but no matter uh what that specific is like it's always about the mission right like about being able to deliver this like large scale uh project empower in all kinds of ways people like that's like what keeps me going as well just like seeing uh seeing the opportunity and the impact. Yeah. >> Yeah. Because like you know the space is very volatile like people come and go and you know especially money comes and go in this environment. So like the core defs are here to stay. The core are here

for the long-term mission and for the vision of the technology and also that's just because we are nerds and just like love that play around with stuff and like figure out problems and solve them. Right. And there is a lot of problems to solve a lot of interesting ones. So >> that's what we are here for. Yeah. And I'm just you know doing the uh renting so somebody can come up with a question guys please raise your hands and uh so I don't have to fill the time in here. >> Yeah. If you guys can solve quantum uh that's probably a good project. Uh, okay. Let's let's go with Marco now and then we Yeah.

>> Uh, yeah. This one is like not specifically related to to what Shane did. Uh, but it's like uh should we include the external work that we do in inside of the weekly updates or no? Is that like a recommended thing to do if we of course can do it like without damaging the main project that we're doing? >> I mean like if you're working on something related, something theorem related or just like generally like growing in some areas like feel free to add like what you're working on. It's really up to you to uh what you want to show the world what sort of uh like uh progress you're making, what's your process, right? uh so it's it's really uh I guess generally like how much

relevant it is but also like you know how you can make it relevant how you sell it how you uh incorporated in your process that's that's the most important thing but I mean I understand many people here have uh uh you know other jobs or studies and so on so like it's not always a fit but uh you know feel free to like uh uh write anything that you find relevant that you believe that like the people reading the updates should be aware of and maybe like to reframe the question like towards the Shane a bit more like uh what what do you think like this benefit of the update is like now you know all these people I studied your updates they saw all that you did in cohort it's all out there I sent them to study your history maybe I mean I hope I hope some of them

did it but like yes so what do you take from that like like what do you recommend you had great updates so like this communication and updates and just like yeah >> yeah thanks um it helped me probably the most to say kind in align with whatever my like project uh like timeline was going to be. I kind of knew I had like let's say four months and I want to be able to like hit ter milestones along the way. The um hack and deep posts were a way for me to kind of like judge like oh how far along am I and prove out that I prove to myself that I understood the idea that I was trying to build. So, um, like example be if I'm working on

something like peer-to-peer like related, I would like spend time like looking at the consensus spec and then trying to write down on HackMD like what is the problem this is really trying to solve. Consensus spec will a lot of times describe like how to make a change but doesn't explain the why. Uh, so I would spend a lot of time deep diving and writing into my hackmd the why. Let's say they're making a fork choice related change. uh what a scenario is this like trying to resolve and I think and then I would use that to help impact the solution that actually would implement because uh it's never just like read consensus spec and then go and implement like in lighthouse you got to take a lot into account like what is the real problem they're trying to solve um what kind of like edge cases could be

introduced because consensus spec is like happy path-ish um and also like edge cases but like you can think of more right so you think about how you can design that out when you're making the PRs um So, and also I use as a way to like show like the PRs that I have done. Um, like at least to myself, I would find myself going and looking back at my HackMD post like later on to try to like remember some concept. Uh, and I think that was like particularly helpful so I don't have to like go and uh like try to find it from other like resources online. I've already like talked about it to myself and uh had a good like uh solution that way. So yeah, I I found a lot of value. I did I think I did like every week um and would not change that

aspect about the program. Yeah. >> Oh, it is great to hear. I mean that's uh that's a great advice to uh how to handle this process, how it can benefit you guys. That's that's very good. Yeah. Awesome. Yeah. Uh hope we have last couple of minutes. Anyone wants to uh ask some last question maybe or anyone has any thoughts? Okay, we have a question in the chat. Uh I think Tamjid is also from Cosmos and ask like what's the difference between the ecosystems working in one one ecosystem or another or maybe I would like also broaden it like uh I'm not sure if you had like some or other jobs corporate jobs or so before like you

know where do you how do you find this line of work special or like where do you see the difference between the different communities or different like you know kinds of ecosystems and uh I guess like you know fully open source work versus if you you know have something more more regular. Yeah. Yeah. Um I guess being broad uh before blockchain I was in traditional finance as a developer and that's where you know the core mission of like oh I see all these financial instruments that are like avail that you can get in the US like 401ks and all this stuff and I realized like they don't exist like anywhere else or at least in like a lot lots of not other places. And then uh when like looking I find crypto and I realized oh they built all these like interesting like financial instruments

that are like free to use by everyone. this is like really how things should be. So I then just started doing a bunch of open source like I picked Cosmos because I found a blockchain that was like a very finance focused one. Uh and they were called Injective and they're still alive doing well. Um and so yeah I did open source for them. I got onto their team similar to how it worked out like here with Ethereum. Um and there it's it's a smaller team like a chain a blockchain in Cosmos is more like a app chain. So it's we're like maybe a 40 50 people team. we're like the whole blockchain and you can we even built like our own apps as well. Whereas Ethereum is like uh so many client teams written in so many different languages communicating on these like um AC/DC

calls and a very decentralized like uh communication style and they have like the Ethereum Foundation kind of as like guides but also in the end like the client teams are um implementing per like a spec that they've all agreed upon whereas uh in Cosmos it's a smaller thing uh you know maybe 40 it could be five people running a chain there right and you look at Ethereum and there's like thousands. So, uh it's just a whole like different approach to something we call blockchain, I guess, uh is like a good answer. And yeah, happy to be uh over here. Yeah, this is fun. But yeah, I mean this is a different different uh way to play, I guess. And I like the generalized aspect of it. Uh kind of as Mario alluded to. Um sure, like I know I

mentioned finance is great and all that stuff, but like it should in my opinion be more general purpose like credible neutrality. the chain could have like less preference towards what is built on top because that's more empowering to the builders themselves. Like you kind of just want like uh Ethereum as an operating system as opposed to like a very like fine-tuned instrument to be used for financial gadgets. Uh so I kind of like pivot my mindset to more general purpose is kind of like a way that um is what I would like to be building towards. Yeah. >> Yeah. That's awesome. Thank you so much.

chain. Uh, it was great. I think it was a great vision to uh maybe like uh wrap up with. Um, unless we have any last minute questions. We have one minute to go. I give you guys 5 seconds to come up with something now. We've been here. I mean, I was great. Yeah. Thank I mean Shane, we covered I think we covered really everything like uh you really uh I think you are very experienced follow you give very strong advice. So I really appreciate that and I think we covered really like I had some some um things in mind uh that I wanted to cover make sure that the fellows learn from you but I think you just talk and cover everything from like yeah choosing the project and the updates and working with mentors I

think it's it's been really great. Yeah. >> No totally >> awesome. Yeah >> man it's been awesome. Yeah. Thank you for having me and like uh Mario's always good to see you. I hope to catch you and Josh hopefully at DevCon and all you guys I'll come sure to watch your final presentations. Um really excited for that over in Mumbai. Um but yeah, I'm really happy to be here >> and hope everything goes well for you. >> Best of luck to to all of you. >> Yeah, thanks. I think you already got people hyped about Mumbai when talking about that and meeting at Defcon. So like it's a you know it's still a lot of work before we get there but like I think yeah we have great kickoff here.

So, thank you so much for helping us with that, Shane. Yeah, I really appreciate it. And of course, >> yeah, really hope you have a great day today. >> Yep. You have to enjoy your days regardless. Cheers. >> Awesome. And yeah, see you somewhere next time. Great one, everyone. Yeah. Cheers. >> Cheers. >> We'll see you next week.