EPF Office Hours | Kolby

Yeah. Yeah. I mean, the first thing we learned about you, Colby, is that you reviewed a local McDonald's and you're on you should have just run a blog. So, uh even if it's not recorded here, we have some uh we have some uh database of your reviews, you should you should get that going. Anyway, uh so thanks for joining.

Yeah, thanks for being here. Uh Kobe here uh joined us today from all the way from Osaka from his bathtub. Um so awesome to have you here. Um and yeah

yeah yeah uh yeah so yeah um it's it's great to have Colby here because he's one of the the um earliest uh successful fellows from this program and uh has been doing a lot of interesting things in Ethereum since then. So, so yeah, thank you so much for being here again and I hope you guys uh prepared some interesting questions for him. But um uh after I will warm up with uh with the fast food questions. I will ask some more more on the topic to get started uh uh tell us about your your initial experience how you got to the the CEP originally what what you did before and how was the experience starting with the Ethereum for you?

Uh yeah, for sure. So, like when I was like uh younger, uh I always wanted to like make money. And it's like I I did a lot of doortodoor salesman type stuff when I was younger, whether that was like uh in boy scouts doing bottle drives, selling popcorn, uh mowing lawns, shoveling snow. And through that, I'm like, I don't want to do this my whole life. Uh, I really loved my Can you hear me?

Yes.

I just my Yeah. Yeah. Just my bandwidth is slow.

I really loved computers from a fairly young age. My first computer was uh like a blueberry like uh like basically like a an iMac blueberry like the CRT with like the translucent back. Uh so when I was around 10, I kind of triangulated in my mind that I wanted to do something with computer science. Uh I was getting pretty tired of like uh mowing lawns. So I started just googling online every day like how can I make money online and through that I was able to figure out that there was this thing called crypto.

Uh since I was like fairly young, I gravitated towards more so uh uh more so like smaller cap coins. And then through that I was basically just like telling them about like joining these small like Slack servers being like yo I'm interested in this. Uh, and then through that I was able to make like $5 mining in like my school's computer lab, selling that on like local Bitcoin and like other exchanges at the time which you could use. Uh, and then wasting my money on eBay. Uh, but other than that, through that I was able to just work my way through Shitcoins.

Eventually I got a job making like $10 USD an hour. That was a lot better than working like manual labor at like Canadian Tire, which is like kind of like this store in Canada what sells like like tools and like outdoor gear uh and also trees during the summer which like sucks but and then eventually uh after I worked for $10 an hour. I worked there for like a year and I was like pay me more money because I learned a lot more. This guy was like, "You'll never make more than $10 an hour." And I'm like, "Okay, goodbye."

I jumped around a bit. I eventually worked for someone uh who was paying me like $50 USD to work for him. I hated working for him though because uh the rate he was super unstable and also like the work was kind of boring as well. But one of the cool things I got to do while working for him was basically implementing Bitcoin's peer-to-peer stack because for some reason he wanted to like make a Twitter clone over like Bitcoin's peer-to-peer stack and some other guy started it. So, I basically implemented it in Dart because I was like, I don't want to implement this five times.

And the guy I was contracting for also sent me a link to SEAP. And at the time, I didn't really think I was going to go for it cuz I'm like, I'm stupid. Ethereum's like super cool. It's super big. I've only been in like smaller things.

Uh but then one day I went to school and I was sitting right next to this guy named Derek which was in the last cohort of the EPF and he was basically like telling me in social class like yo man um I'm applying to an internship at our local university and I was like [ __ ] you. Uh I'm applying to this opportunity I've heard of called SEP which is now the fellowship. I wrote like a one-page uh letter and I somehow got accepted uh through that. Uh originally at the time it was being run by someone named uh Piper Miriam and I guess he was also switching from working from like leading the Python team to working on uh basically a peer-to-peer network which which basically paralyzed all of Ethereum's block history and state across like many different nodes and that you could traverse verse the network and recreate any JSON RPC query uh that you could get from an execution full node or the JSON or like Infura using like their uh public JSON RPC. Uh so some like that.

Uh and then I guess that's kind of how I got into SEAP. Uh I did that for the summer. At the end of that summer, I was graduating high school. I was like, "Uh, [ __ ] this [ __ ] I'm gonna party." Uh, I joined a frat for a term in university.

In Canada, they're a lot more relaxed than the states. Uh, but after a month of doing that, I basically got like extremely bored with partying cuz I was drinking two times a week and I was like, I'm doing nothing with my life. Uh, every time I went drinking, I started just like pacing around cuz I was like so bored and I eventually just quit that uh, winter term. And then my second year university, I just took like a ton of heavy courses. And then by the end of that year, I was like, I really enjoyed what I did in SEAP.

I was kind of embarrassed at the time because I was like, the work I did was garbage. uh but I contri I started contributing again to the project I worked on in the past and I tried to contribute as much as I could. Uh I was lucky that the merge just happened. So the EF was running like a protocol summer grants. So uh Piper who ran seed but was also running the team was contributing to two years ago.

He's like, "Uh, if you want the EF is basically letting efers give out money." I was like, "Awesome. I'd love to not be homeless." Uh, I grinded this summer on like building basically like interrupt tests because there's going to be multiple implementations of this like peer-to-peer network uh distributed storage solution. Uh, and then at the end of the summer, I was like, "Please give me a job."

And then I got a job at the EF, which was super cool. uh I worked there for two years and then priorities changed but also uh 6 months before I also started uh looking into something called the beam chain now called the link chain and the idea of this was like okay we're kind of on the cusp of like quantum computers uh if we want to take security seriously we should probably do this uh but since we're reaching this quantum state, we could probably jump ahead of of like the current like consensus chain in the same way that like we jump to proof of stake. What if we jump to this basically like optimal quantum solution? And I thought that was really interesting during uh DevCon uh DevCon last year. And I just told Justin Drake that I would like to start a team called Dream.

And um I guess I've been contributing to a team called Dream for almost a year now.

Yeah.

So I think

Yeah, that was all of the history. Colby, thank you so much. uh you you uh I think I never got such an answer to this this question going all the way back to your first summer jobs to to the current current part of the Ethereum. That's great. That's great.

Thank you so much. And I think it's very inspiring like from shoveling snow and Canadian Tire all the way to RE. Uh that's very cool. Yeah. Um okay.

Um so um like maybe maybe to elaborate more on your um on your current work like how do you feel like also switching from portal to uh to REM uh like how do you how do you feel uh that the work changed like what uh uh how do you see the future of the protocol like what uh what motivates you what you find interesting about the about the current job and how do you how do you find it different to working on portal like how is it like for you to to switch like this Uh so uh portal especially when I joined was a somewhat of an a very early like R&D project where it was like we're not really sure if this was possible. Uh there was a lot of confusion on like how you should bootstrap a project like this and there was different levels of basically uh like different like different people had different ideas of what stages the project was really on. So when I originally like started like heavily contributing to portal two years ago, I'd say it was like fairly cloudy and then like as I joined like over the last two years I think things got a lot clearer. Uh and through that I was able to learn a lot. I think uh this time with something like the lean chain uh being ran by like a ton of people at the EF but also like other teams.

For example, I'm contributing to a team called re with like uh quite a few other members. Uh but there's also a team called Ze who which is being spearheaded by uh Gender and also Gnome which Gender was like a big player on Ethereum ofJS before that team was cut. Uh but he also started contributing to Ze like at DevCon last year and then uh Gnome uh leads the stateless team. So I think like with like the EF support and I think like with all the experience on like the on like the few starter teams I think the whole like lean movement has been going a lot faster but also like on a way better track uh which I'm super bullish on uh and I'm extremely excited for. So, I think like overall like going from Portal to Lean, I think like I grew a lot at my time at Portal, but like I feel like it's just a lot better space and there's like a lot more experience going into this, which is really helping things go forward.

Yeah. Awesome. Thank you so much, Kobe. Um yeah, it's very interesting and I I have to say I very much respect I I find it also like very uh very inspiring and helpful for people here like the sort of open mind adaptability that you have just like being able to work on also like I mean you started the portal which was uh the research prototyping and uh beam at a time was the same thing and uh and you you were able to just jump into both. So, so that's something that's uh that's really great in the everchanging protocol.

I think it's a good lesson for the fellows here. And um yeah, uh I mean the uh uh the lean right now is also uh sort of uh very much in in progress and a lot of we have bunch of people here uh contributing to to some of the clients also to reim um uh folks let me let me open open it to the audience as well. It's been 20 minutes already. Do you have any questions? Uh before we continue, please feel free to raise your hand.

We didn't have any in GitHub. I think check. Um I wanted to give opportunity to the audience here. Um also wanted to invite you to ask about uh uh re remain and uh rust and portal um all kinds of stuff uh Kobe is experienced in Okay. So what what I'm cur Okay, go ahead.

Yeah, thanks a lot. I'm also interested in link uh consensus protocol. It looks like the pillow of the L is like more it involves like cryptographic form of verification and P2P network but I only know some parts of them. uh would you like to uh discuss more like uh the what's the progress now and uh what's uh like what's a what's a uh biggest challenge now because I I noticed like in crypto part there is like research on where GTR and all this stuff something like that uh it sounds very interesting. Yeah.

Uh yeah. So I guess overall there's kind of like uh a distribution of work. So on client teams uh we're mostly interested on like uh building the clients themselves uh taking primitives such as like SSC P2P and making something that works. uh if you're interested in cryptography that's mostly being handled by researchers at the EF. Uh so I think if you are I believe there's um in the EF discord I believe there's like a lean crypto channel and if you ask a question there I think one of the researchers who are like building the basically like the reference libraries that the clients are going to use.

Uh I believe it was with it started with like E8 wait E4844s uh like the researchers at the EF would implement a library a cryptographic library then clients would use it. uh a similar model is going to be used on lean for uh I believe most if not all like cry cryptographic libraries and functions. Uh yeah, thanks. uh actually we had some discussion before with researchers there and uh uh I also joined like Z proof's uh meeting and uh I'm wondering like from the client side from the development side uh what's a progress now and uh also actually I I don't know because it looks like quite a new thing for me until so Yeah. So from our side it's mostly just uh using the libraries offered from like the EF research team.

Uh but also like integrating that giving feedback whenever there's like rough uh edges and using it. Uh in terms of like actually getting something tested, uh the the DevNet Zero is planning to be done in October 5th to 7. Uh and I'm sure there's going to be quite a few blog posts uh posted by various teams then. Uh and then there's also g we're targeting uh basically around like November or dev dev connect uh for our DevNet v1. Okay, thank you.

Uh we have another question.

Yeah. a hack I'll be thanks for this um I was wondering like um I don't know like the whole road map but um to the thing that I'm concerned for example my question is the following like uh so many ZKVMs are created by companies which is not like EF so they they provide the environment and then we can uh run inside and this kind of stuff but they seem to be at the very first steps of their progress and I haven't seen any of them like meet the criteria for example that Justin has Is it possible that you know a miscommunication with them or something like that delays the whole road map and things get out of hand because the road map is like five years uh long about lean I'm talking I think the road map is optimistic but I believe that wherever I think a a certain thing with uh any five five year or four year term project is you never know where it's going to head uh and if thing if expectations do change um there's likely to be like I would say is somewhat unclear is like are we going to have a fork to lean or like how is this integration or transition going to look happens. Uh we'll probably be shipping something that conforms. So one of the reason why we're having like rapid uh dev nets is so we can give feedback to the researchers on where things are actually at and what we can actually ship. Uh so I think with with these devets uh hopefully my uh hopefully you guys can still hear me.

Uh with these Zevn nets, we should be able to give the researchers better and quicker feedback to be able to iterate uh faster and through that we should have like answers of if something would be blocking us quicker and it shouldn't really block us because we should already be aware of the current circumstances.

Yeah. Thanks. And uh one more like more specific question about like some uh resources or references about Rust. So I'm quite new to it. Um I know the official book and all that and I'm learning a lot from the code of others.

But if you can share any other resources or ideas or like specific things which are necessary for example in rim or like this kind of development I would be very happy to to hear that.

Yeah for sure. Uh, I'll link uh the the lean Ethereum repo in the uh Discord server uh here which uh so in the in the lean Ethereum uh GitHub organization we basically have like the lean specs our project management repo uh where like meeting notes and agenda items are displayed. So if you want to read into like uh Re's codebase and the specs for what we're implementing, uh reading the uh github.com leanthereum/leansspec uh would be a great place to start. Uh or reading like researchers blogs.

I know uh some people at RE um make blog posts and I'm sure if you ask in the Zam Telegram, if you don't have that, you could always DM me. I'm sure they make blog posts as well which you can keep up with each individual team.

Thank you guys. Awesome. Yeah. Do we have some more questions? Please keep it keep it coming.

Um yeah, good discussion. Um I didn't have any in the issue but please ask live and with Colby.

So you you uh mentioned that you think the lean road map is ambitious. What do what do you think is a realistic timeline for the implementation and change over to this new system? Uh I think four to five years is a realistic timeline. Uh mostly what I mean by ambit ambitious is uh oftent times when you're building something in a four or five year time scale uh it's really hard to predict the final outcome. I'm sure we're going to have a postquantum solution in four or five years.

Uh but will we reach all our goals? Uh will we need to make certain trade-offs to make it possible? Uh something basically along those lines. So I think like uh I think being very like aspirational and aiming for something high is really important. Uh if you want to basically build a team behind any movement or build anything great, uh will we meet all our goals?

Well, maybe we might succeed certain goals majorly and maybe we might need to do certain trade-offs in certain places and there's always unknowns. For example, uh early on in like lean like research and development, uh the choice was done to go with like hashbased cryptography. Uh but there was always an option to go with lattisbased cryptography. Uh but I'm not sure if you guys have like seen posts recently, but there's been a few discussions that there's possible attacks against lastbased cryptography uh where there's great confidence in hashbased cryptography because we've been using it for decades. So, uh I think like if we like if we made a choice in the wrong direction and there could have been like I guess attacks against a choice we made that could set us back potentially.

And I think an example of this today is Poseidon 2. Uh to my knowledge uh Justin Drake has been running like a bunch of contests uh through I think it is like ETH proofs or like the E proofs direction on like is Poseidon a trustworthy cryptography algorithm and I guess we'll see with time but if it is I think that will accelerate our progress but if it's found in like 3 years it isn't that could greatly delay So, uh, ambitious is a project being ambitious is almost like a moving target of sorts where it's like you don't know what will hit you off course or will boost you in that time frame which could greatly change your scope.

Uh, I think I can add something about the attack on the on the latis. It's not only on the latis, it's on the uh learning with arrow. So also uh FG will be highly uh like uh suspicious now for most uh fast uh or efficient uh uh schemes now uh uh it's also not only the discussion I mean they released some already some papers like draft of the papers on archive now um if you are interested You can take a look and the author I think from uh the I know the author like he's also a Chinese so it looks like amazing attack so but I'm not sure what's uh what's going on now. Yeah,

cool. Um and it's interesting crypto news. Thank you guys. Um, feel free to keep raising your hands if you have any thoughts, questions. Um, okay, Shane, go ahead.

Yeah, once uh lean's all set and we want to implement on the different CL clients, do you think it'll be more of like a huge fork that each basically a new branch that like all the teams will build on or you think they'll have to like rewrite each client from scratch? Curious. Uh I think it mostly depends like how clients were built. Uh if I know like coming from more of a rust background normally we build things in crates. Uh so our codebase is quite modular and I think like something like lighthouse should be able to adopt something like this fairly easily.

Uh the idea of lean would be we take existing resources that we do have stable. So for example the P2P stack most clients have I believe they should be able to reuse most of the code with minor changes or improvements in various places. Uh so I don't think lean in its current state would be a heavy lift. uh it's more so it's like uh what primitives are you using for private keys uh what primitives are you using for XYZ and I think overall I don't think it will be that hard of a lift I think most of the complexity comes around like implementing good peer-to-peer code which hopefully we can reuse a lot of that uh but also since we're since the current idea is using some with like 3 SF. Uh in the bad case of that where it's like you have like a forking network, being able to recover a network like that is extremely hard and I think that's the hardest part of building a client.

Any team can throw together a prototype in probably a week. Uh but can they have a client what's resistance resistant against an actual attack on the network? uh it can actually recover from bad situations. I think those are like the actual challenges of building a client which even a lot of the clients today are struggling with and that's not to blame them. It's just an extremely hard problem.

Uh and uh with things like privacy or security uh it's often hard to conceptualize putting effort into something unless it's like urgently in your way. And unfortunately it's like having a hard problem but the hard problem is also like a very rare case. Uh it just creates I guess really the worst cases are extremely bad. So hopefully over the next 5 years clients just get like better and better like reorg logic uh and recovering from that and I think in that case uh we'll have even better clients when lean comes uh and the actual differences added from lean uh I don't think we'll make that I don't think they comprise the important parts of an actual like consensus client if that makes sense or it doesn't compose the complex parts uh which like help you sleep at night. I think that's a good way to put it.

Yeah, you can imagine the clowns to be in a much different world in five years. Even predict I hope Okay, awesome. Thank you, Shane. Thank you, Kobe. Um, keep it coming if you're there are more questions.

Um I'm also curious about the lean chain specifically like how do you see we already discussed it a bit like the road map and the future like what I'm curious about because during beacon chain development sort of a mistake I felt that we did was like I want to say starting to s like a lot of prototyping that happened a lot of initial development was kind of wasted like started implementing uh beacon chain like 2018 19 and the specs changed a lot during the times So the initial code also it was like became more of a spaghetti right like just rewriting a lot of stuff and a lot of the usual work was wasted and now we have so many clients on lean that are started reimplementing decay stuff basically and without the proper spec. So like how do we mitigate this now? Like how uh how do we manage the the uh prototyping now so that we don't waste work so that uh uh we um we work efficiently? Um yeah did we learn from the experience? I think yeah I think the whole concept of wasting work might be a misnomer.

Uh as in like if everybody knew exactly what was going to be the final outcome. Uh I think that that would be a very unrealistic world. Uh so I think overall I think a lot of the experiences learned aren't wasted. I think a lot of people on the pre-existing beacon teams are still there. Uh I think we do have some of that experience through people like Gender uh who worked on EthereumJS but also on Loadar.

uh and I do think we also get assistance from uh while a lot of beacon teams are focused on the beacon chain and not so so much the lean chain currently uh they do often provide feedback when needed and I think that uh expertise of critical people uh really comes into hand uh I don't think like any I I don't think most of the work for example like prism did was necess necessarily wasted. I think a lot of lessons were learned at the time. I'm sure a lot of the lessons learned will be like forgotten to a degree. Uh but I hope through mechanisms for example like the protocol guild uh experiences like that are retained and I think only by people like working in the past bringing that up uh would be able to resolve a situation like that. But I think like if code is rewritten, I think it will mostly be fine.

Uh I'm not sure so much about other languages, but especially in our case in Rust, I don't think like if we had to write any rewrite any code, it would really be in vain unless it was the P2P code. Uh but at the same time I think like the P2P code is like fairly stable and at this point since we have like a lot of like actual tooling built up like uh SSC li P2P I think like the actual code being re like that would need to be rewritten wouldn't be for waste like uh one thing that might be rewritten is like uh certain cryptography libraries is uh but in for my current understanding I don't see how like yeah I honestly see like the complexities of like building a good client I think that is like where all the value is so if we need to rewrite something in specs this time I don't think it would be as painful as like changing the specs for like P2P which would be the most painful thing on earth to redo But since that is like actually stable, I think like we are carrying forward the valuable things that was learned from during the beacon chain. So I think we're good in that regard.

Okay, that's awesome. And that's really great to hear. Thank you so much, Kobe. Yeah. Yeah.

And I hope the lip peerto-peer doesn't change. Yeah. Cool. Thank you so much. Um Okay, guys.

uh please keep asking as well uh use the opportunity to chat about the the alen or re or rust or portal maybe we didn't have much portal discussion and I have some questions but want to give you a chance first

so we have I I need to raise my hand but can I can I go ahead

you go ahead

okay uh you've you've worked across a lot of teams over the past couple years. Uh you yourself are building a team for the lean chain uh for the ream client. Uh so I have two questions. Uh what do you think makes a great team? Uh given given our ecosystem uh it may be different for different ecosystems.

What what do you think makes a great team in this ecosystem? And what do you look for in an individual contributor for them to uh for them to be like like perfect for what's a what's an ideal individual contributor?

Uh I think that's a good question. I think like if you're in the EPF and you made it here, you probably have like a lot of those values already or if you've read through the EPF documentation. Uh but I think overall like one of the great uh values for like someone in the Ethereum ecosystem is if they're like independently driven. Uh especially when it's like oftent times on teams there'll be like many people working on very distinct things. Uh being able to figure out what you're going to work on and the actual priorities I think is really important.

being able to speak up uh when you think things aren't going in the right direction. Uh I think something like that can save a lot of time. Uh I think communicational skills are really important. Of course, being in like software and like computer science backgrounds, which I'm sure most of us are. I know we're not known for communication as much as something like business majors, but the value of communication is extremely high.

Uh, and let's see, uh, someone I would want to work on me, uh, work with me on a team would basically be like they're very motivated for like the actual problems we're solving. Uh because working on a team with like if you're working on a team and the people you're working with would don't want to be there, that's not a fun situation for anyone. Uh not needing to micromanage people, but for the people you're working with to basically be like uh solving problems without you needing to ask, I think that really multiplies effort in a really great way. Uh if you need to ask questions that's not a problem but it's like of course you should have done some research on your own and kind of like understand the space a bit. Uh cuz once you like of course when you're initially learning a codebase that could be quite challenging.

You might need to do smaller issues and work your way up. Uh but once you understand the scope of a codebase uh you should be able to like navigate that correctly. Uh learning skills like that is often not taught in something like university. Uh it's often something learned in doing like either contributing to an open source project or building your own project where you're always like iterating trying to make a better product. Uh, a good example of this could often be a website.

Uh, but in other cases, other cases I've seen, uh, it could be any project you're interested in making better, whether that's optimizing something for more users, increasing the UX of a product. Uh and then uh the other thing I think is like the vibe a team has. I think like one thing is is it's like the people around you liking you but also you liking them. Uh having people you'd want to work with, want to talk to, want to show up to. Uh I think that's extremely important on any team uh or just like innate kind of to human nature.

And I think I answered the second question, but what was the first question again? Give me one second. Uh yeah. So so the first question was uh what do you think makes a great team uh in this ecosystem? Like what's a good what's a good client team?

I mean I guess it could be a set of individual contributors as you as you mentioned but uh if you have any Yeah. If you have any insight on that.

Yeah. Yeah. Yeah. I think it would basically just be a set of contributors who are highly uh independent. Uh they're self-motivated.

When they see a problem, they'll basically like bring it up. Uh they'll organize groups of people from other groups to basically be able to solve those problems. Uh and yeah, I think that's what an ideal team is. Any awesome. Okay, thank you guys.

Um, any more to questions? Um, those are those are good questions. Nice reflection. Uh, Kobe, uh, Pa has a question.

Hi Kobe. My question was just to get a little bit more perspective on your experience with um your work with Trin and everything and why that ultimately didn't pan out and any lessons you think you guys will be able to take from that for lean and also just like more perspective on what happened because I feel like I was following it a decent amount and then everything just seemed to disappear overnight.

Uh yeah, for sure. Well, I think uh it to a certain extent it's accountability with the team itself and the leadership around that. Uh but it's also changing uh changing visions in terms of the EF's leadership and what the future of Ethereum should be. Uh so uh when I joined the Ethereum Foundation basically it was like almost a completely flat structure where there was like a bunch of teams and then there was leadership on top and then like a while later it's like uh teams were bunched into four groups and then uh before I got laid off the EF became a lot more hierarchical and uh from what I heard one of the reasons for that is it's uh having a more accountable structure. Uh I think uh partially on the team I worked on there was some accountability but it was also like in social situations it can sometimes be hard to like bring problems to light.

Uh especially depending on like who's whose boss. uh and talking to other team members, it can sometimes be hard to like keep people accountable depending on like where you are in the hierarchy. Uh and I think that happened a few times. Uh so I think we did miss uh I definitely think we did miss like deadlines of where like portal should have been. Uh, and yeah, I think better managing like uh priorities, but also like making sure like if somebody's working on something important and it's been like x amount of time, making sure to like check on that important thing instead of just being like, hey, that person's got it.

If it's been like 6 months, you should probably check in on them on where the progress is. but also identifying like what is important in a project. Uh, one thing about portal was the scope was very like vast in that it's like I guess you had the base layer which was the history network then you had the beacon network which would be able to prove the history network and then you had this like massive scope of the state network where it was like we had like before the project was shut down we had proving up to like 8,000 blocks before the head but I think we should have probably had that done a year before. Uh, and if there was just like better communication on what was happening with like the beacon network for example, I think we definitely could have got that proving done earlier. And then it's like, well, if we get the history network up, I think that would give a lot better feedback from users quicker.

So I think overall a lesson that could be learned is you should focus on getting a product out that works as soon as you possibly can. Uh you shouldn't try to build the full scope of a project but like an important part that works like probably the stack up. I think like having like the full history up and just like focusing on that as fast as possible getting that user feedback would be great. Uh I think another struggle with portal specifically was like uh like changing uh beliefs of what Ethereum should be over time. Portal was a very like uh decentralized I would say like cyber punkish uh kind of vision where it was like okay nobody's running full nodes because running full nodes suck.

What if we took out all the hard work of running a full node so people could have this like experience of using Infura? It would be slower because of of course it's slower. You're not talking to a centralized server. And then it's like could this slowness be justified? And I think a mix of like it being an ideological project, leadership changing in the vision, uh, accountability problems on the team.

I think if we like shipped a minimal product quicker, I think we'd be in a very different world. like if we made many different decisions but of course like over a one year two years x amount of years of the project various levels of like decisions were made so it's really hard to be like oh that one decision if we changed that that would have changed everything uh so I think if I could go back it would be on like even even if it's awkward situation even if you're like good friends with someone. It's like being accountable as a team. I think it's like it's not just responsible to the team, but it's respectful to everybody on the team because if people are going to be spending years of their life working on X Project, uh being accountable will save everybody time and like calling stuff out I think is like insanely important just because it's like I know I didn't call a lot of stuff out. I know talking to team members like they notice stuff they didn't call out and it's like it's like if people if you've been working with people for years it's like it feels awkward to be accountable but I think accountability is so important especially if you believe in a project and want it to ship.

So, I'm hopeful with the EF's new structure, even though it's more horizontal, which is like less like flat and like cyberpunkish, hopefully more things are shipped and the different vision of Ethereum, which is like different when I joined the EF, but like the vision now, I hope that at least they ship faster and like whatever they believe is right for the protocol get shipped. I think that's extremely important. So yeah, I think with like leadership, of course, it's like a hard decision to like cut teams, but I definitely think like I have great respect for the leaders who did that because it's like uh to a certain extent it's like what can you really do? And I think with like how long Portal was being developed for uh let's see cuz prototypes like when I got to Portal originally it was 2021 prototypes were being done in Python for I don't know a year or two before that. So what this was this project was being funded for at least four or like five or six years and for to not have like anything in production yet that's I think that's a major problem in itself and no matter what caused that problem uh that's a that's clearly a big problem and I'd say that's kind of why the project was cut.

Um, and hopefully in the future, you know, ZK solves all the problems in the world and we can have a cyberpunk future. Uh, but one can only hope. So I don't think that was a perfect answer because of course it's like a very complex space and it's like so many things went into how things turned out that it's like you can't just say this one thing I did it even though that's super like that's the easiest thing in the world to do. Of course, it kind of hurts my soul, but I'm also kind of jaded. So, I never work on a protocol like that again.

Unless, of course, there was tons of ZK magic involved, cuz then that'd make everything easy. But hopefully that answered a little bit. But of course using all the lessons I learned in any team in the future, I'd want to apply that to have a more successful team because of course like nobody feels good when like a a project was cut and a lot of resources were put into it. I I don't think leadership felt good with like having a ton of budget like that budget could be so productive, right? So for like portal received a decent amount of budget and yeah

thanks for the answer in

yeah awesome that's um tough reflection and a lot of lessons learned there from portal um and like I think it's it's a sort of a pattern in Ethereum like working on a research for many years and like having a hard time like uh getting it into production, you know, with like also EOF that is different story, different problems of course, but um but it's um it's not really unique. I think people need to be ready for also like this sort of disappointment if they want to stack in the ecosystem. But a lot of important lessons. Yeah, thank you so much, Kobe. Makes me makes me a bit sad now reflecting on everything.

Like I was honestly hoping that there will be some something we can salvage from the portal and the the current chaos about what to do about history expiry uh can be somehow somehow helped but um yeah. Yeah. Um cool. So we have lost the last few minutes. Uh so before we finish um I will just ask you one more quick thing.

Um what is uh what is your advice for the fellows here? you have your experience starting young uh going through all the processes in the core development. So what is some some advice that stuck to you or something that um you wish you knew uh when you were starting um how how do you how to survive in the in the core development? Yeah. Do you have any thoughts any advice?

Yeah. Uh I would say believe in yourself more than anything. Uh just because it's like if you don't believe in yourself, nobody will. Uh if you if you don't think you can do something or understand something, that's like the silliest thing you can think because it's not a matter of if you can do something you can. It's a matter of how much time it will take you to achieve.

And it might take you like a like 10 years to achieve and maybe you should pivot. But I I don't really think there's something as hardness more so of just how much time it will take to for you to achieve. Like everything is easy but everything takes a different amount of time to achieve and when you go through life sometimes like things will become easier to achieve and maybe it makes sense then u maybe you should pace your goals out so like they're somewhat achievable and then you like kind of level up in skill. Uh if you want to work on a team, you should contribute to a team. You should make an impact.

If you're making if you want to join a team, your goal should be able should be like performing as well as like the best guy on their team. Like that should be your goal of work. Like if you want a job somewhere, you should try to create as much value as you can. You should be creating as much value as somebody being paid to work on that project. And then if you ever want something, ask.

Because if you don't ask, people don't know how to help you. So it's better to ask and get told no. Then never ask because if you're just doing something and you don't ask, like people don't know what you're thinking. If you don't ask, you might never get what you want. But if you ask, you're going to get what you you're going to get more stuff in your life.

You're going to live a way better life if you always ask what you want than if you don't ask. So I say if you guys ever want something, just ask. The worst thing you get is no and some advice. But getting know and some advice is going to save you a lot of time and you know if you ask, you might just get it. That's my advice.

Yeah, that's awesome. Yeah, thank you so much, Kobe. I think that's uh that's really nice. Uh yeah, a lot of uh lot of um confidence boost there. Yeah, and it's something I also struggled with like sort of an imposter syndrome and like not not being able to ask.

That's great. Thanks so much, Colby. I think people really loved it. You get a lot of clapping here and uh it's also like right at a time to to wrap up the call. So, I think it was a perfect perfect way to finish.

Thank you so much again, Colby. Uh thanks for joining us today. Awesome.

Yeah. Thank you so much for inviting. Have a good one, guys.

Yeah. Yeah. Thank you so much and yeah, enjoy rest of Japan. Um, hope to see you at uh another of these uh meetings. Bye-bye everyone.

Thanks for joining us.

Thank you. Bye.

Thank you. Bye.