AMA with Kolby | EPF5 Office Hours

recording is on that's great awesome yeah so let me welcome Colby here today uh at uh another office hours in the cohort 5 uh we have a another special guest uh Colby um yeah it's an honor to have you here you might know Colby as a contributor to portal Network to tr and uh uh other related software testing but uh Colby started his journey in cedap which is the predecessor to EPF was the first two cohorts were called cab before we wanted to Rebrand it so uh col is like the EPF OG here and I think the first uh uh the first uh guest that we have uh from cep here so uh yeah before we get to some you know the AMA with maybe some technical questions from the audience I uh I wanted to ask you kby about your background if you can uh tell us about your story about your journey how did you what did you do before ethereum and how uh yeah what was the journey through the CP for you and and so on yeah uh sure Mario so uh I guess it all started when I was a kid and aspirations so I really liked Math and Science class and my uh first computer was like a CRT uh Mac blueberry so it was insanely slow and garbage but it was definitely inspirational and what I wanted to do so like triangulating those three things together I knew I wanted to do computer science uh but my computer was kind of and I also wanted money because as a kid uh it's kind of hard to get it unless you're like hustling your neighbors which isn't always the funnest so uh I would often Google online like how to make money online and then I ended up finding about like internet money uh I would join I guess crypto communities as a kid and they would be like whoa that's super cool you're like what like 10 11 14 years old and you're like into the same thing as me what the heck and they would be super I guess like open to having me there and then over the years I tried to program more and more and eventually I was in this like one shitcoin community and I was like hey I'll implement this thing for for $600 it like it will help you in X Y and Z uh it ended up taking me 60 hours to implement that and I was so mad because I didn't think it would take me that much time uh but then I basically just worked at a place for a while uh left the place after I got like I thought I improved enough and I thought I couldn't really grow there anymore and then eventually the person I was Contracting for uh he was like oh this ethereum thing opened up called cedap and originally I wasn't even going to apply because I didn't really think I was going to be accepted uh but then I was in social class in grade 12 and one of my like really really good friends was like oh I'm gonna apply for a high school internship and I was like super competitive and I was like if you're gonna get like an internship I have to apply too uh I wrote like a one-page application to apply and I got accepted so that's kind of how I originally got to seed app uh I did it for the summer I thought I did a horrible job and then I was told like hey if you want you can like work on more projects here uh I was going into my first year of University so I was like seea and then went off to party two years later I came back uh I grinded over the summer uh I got a grant and then uh I was able to land a job uh on EF portal which is the ethereum foundation's uh I guess portal team so I guess that kind of leads me to where I am now and yeah yeah awesome uh yeah I love the story I remember actually I didn't realize that it was you at first but I remember when in the uh protocal support a few years ago Piper was telling us about cep but yeah there are some cool people there is this kid who made his own Bitcoin implementation when he was 18 or something like this and uh yeah much later I connected that it was he was was it was cool um yeah and so now like yeah going forward like uh why did you tell us more about uh your Port portal work like what did you uh what did you work on and uh how it evolved what do you work on right now uh so uh when I first started like I I guess it's my second time contributing to portal like I guess a year and a bit ago uh I started just trying to pick up random issues to try to catch up with the project because uh at that point uh the project had been like growing for like two years since I left uh and I guess like the first thing uh that was on my mind is like what is a priority for this project and how would I be able to identify one uh one thing is uh for like core developers and stuff like that you need to be very independently driven uh so it was like I basically had to throw myself into high water and be like hopefully I pick something right and eventually intuition built up over time uh and then my focus definitely for the first year was improving our like testing Frameworks so uh if you check ethereum hiive on GitHub uh there's a endtoend uh testing framework which used by consensus and execution clients uh but if you check it's also used by portal clients and and uh one of my first things was we had like 10 basic tests and I really like I basic I really built out those tests so for one we could write new tests easier but also just have more tests and then another thing that ended up from that was okay so I'm writing all these tests and then it's like oh uh there's a lot of things that are broken uh a lot of these could be like performance issues such as like Deadlocks memory leaks and fixing all those uh you end up getting a fairly good idea of what's in the code base just because it kind of forces you to read it all so going from there I I fixed a lot of bugs and like a lot of performance issues for like eight months and after that uh we have a data analytics platform for like the performance of our Network and after working on like fixing things for a while things started to surprisingly work um a lot of that was also going into like metrics as well and most that was focused on our first Network called our history network uh but then I moved on to working on our state Network where currently I'm building I guess you could say it's an execution client without using the execution client peer-to-peer Network it only uses a consensus layer client and and the reason why we want that is because so portal networks they store basically all the protocol data but how do you get the data into a portal Network well you need to bridge it into the network uh for state state is like this massive problem because to do state in approvable format at least today without veral uh it's around like 20 terabytes of storage so that's like a massive data set and then if you want like replication so like you're sure like it won't be like taken off the network that's like you want to like 5 to 10 x that so that's like 200 terabytes on a decentralized peer-to-peer Network and then it's like you also like every single Noe in the tree is also like just a content type on the network so you end up with like millions and millions of I guess like keys on the key space of our Network where uh portal is basically like a decentralized hash table and what that means is like so you have like your dictionary in Python where you can put a key in a value imagine if that was on multiple different computers and you could look like which computer had the key in log in time that's basically the that's basically the idea of portal but then it also integrates things such as uh having a robust proving mechanism and one of the reasons you want this is because if you don't have a robust proving mechanism like there's another Network called ipfs and the issue with ipfs is it's for one it's not optimized for this case but also you always need to republish the same data every day or or some period of time because because un there's unlimited valid data potentially on the network uh older data is flushed off as newer data is added um so anyways uh Mario you can uh you can uh bring me in now uh thanks Kobe um Kya was asking about the int and I think you've already like explained a lot about portal but uh yeah maybe maybe like also going forward because uh may people might not realize how important portal might become of the four fours and uh and so on so yeah what is your vision for the portal how you see the road map how feasible it is like uh people you know people are hearing about it for like past two three years so uh yeah when is it happening and and what what is the vision yeah how it's going to look like uh for sure so uh the idea about portal is re uh it's like kind of like rewriting the foundation for how you participate in the ethereum protocol and how you access the data so uh at least in the current model without any upgrades currently you need to store around a terabyte of data to participate and a a terabyte of storage is quite substantial uh it if you want as many people to participate because it's a decentralized protocol have requiring a terabyte of storage is way too massive another issue that comes from this is currently clients sync from Genesis to latest well there is an optimization to basically fetch the latest States so they don't have to rebuild all that uh it still takes quite a long time uh and ideally if you wanted to use ethereum in a decentralized manner well it's not really practical to be running this heavy client all the time and doing devops for yourself uh so I think portal will allow execution clients to decide what data they want in kind of like because before they either they either stored all of it or you would rely on a centralized providers such as Nira but the idea with portal is you have you can if you want fast access to the data you can store it locally but if you want all access to all the data at all you can use portal uh so I think one use case would be execution clients and one of the use cases for 44s for execution clients was you could basically drop like a tenth of like 90% or 70% of all the data store because honestly a lot of the older history isn't really needed anymore and then you could rely on Portal so that you don't lose any Json RPC functionality for older blocks so kind of as in like a substitute for that uh another use case I see is because portal will basically be like a decentralized uh Json RPC provider instead of using something like a centralized provider uh for a mobile wallet like currently in F is used often you can use you can just run a portal client on your wallet in the background so the user doesn't even know a portal client's running it just acts as an Json RPC provider as like as if they were running their own execution client and giving you access or if they were using in fear in the background so I think that's really powerful because uh currently it's really hard to not use a centralized provider such as inferia because devops is hard uh but with portal one of the hopes is that access to ethereum in at least a majority of cases becomes a lot more decentralized uh maybe for every case uh portal won't be ideal but uh I would assume most of them would work with portal awesome uh thank you so much Kobe and uh we already have some questions uh going in uh how much storage each portrait client would need uh so that would be configurable uh defaults would likely be 1 Gigabyte because that is like very minimal uh but uh users can contribute how much storage they want to it uh the incentive model around portal is having access to all of ethereum's protocol data through a Json RPC in a very light manner uh provides a lot of value so often most apps you might install locally uh take up around a gigabyte anyways uh but that's totally configurable like if you want to use less than that so uh I think the uh incentive model is utility and uh what you can basically use portal for which is basically replacing many use cases you need to run an execution client before yeah so like also but in general looking in the network like I would highlight that you know the there will be I think there will be this torrent Dynamics where you have some seeders and leechers you have some people using the light Clans and just browsing the data and storing very little and then I I will connect a client to my archive note where I will be seing the network and I don't care how much data it will need right so I think like also this sort of altruism will be important there like uh yeah and with people using it folks do we have any questions for Colby like feel free to raise your hands uh by the way we have people who are implementing their own uh portal Network in Java so uh I think there are uh more people interested so yeah um the p uh client is it the same as lip peerto peer and is it natively available with El client implementation um well that's uh Li peerto peer is a consensus layer uh uh Library um but uh the so portal is using Dev peer-to-peer with like different overlay networks right do you want to dive into that uh so portal uh so the consensus later and and soon the execution layer use a protocol called The Discovery V5 protocol uh unlike unlike I guess Li P toer just V5 this is a protocol built on UDP which often uh UDP is isn't often attributed with having the best data transfer characteristics uh but portals built on as a subprotocol of Discovery V5 uh to the question of will this be natively available in execution clients and for some of the biggest execution clients it will be uh for example nethermind and nethermind and bezus uh two I think it's the second and third biggest execution clients are currently are actively either plan to build a portal client or have even started working on it uh for example uh yesterday I have gotten a few messages from nether mes team in our Discord about like us using Hive for example so uh they're starting to build a client uh in terms of Aragon uh Aragon's likely to pick the uh torrent solution for 44s um and then I believe gu is going to follow some path the other clients use uh I believe they're likely to follow like use portal because like portal is awesome uh but it depends what use case they on uh torrenting can definitely be better for if you just want to like download all the data uh but if you don't need all the data locally but you still want that access I think Portal's a great solution uh so uh in other words we don't use live to P we're built off UDP off Discovery V5 which is the which is how consensus nodes finds other nodes on the network as a subprotocol of that yeah thank you another question is about incentivization for running a portal client and we we mentioned it briefly before about people using ether being electris we talk more about that uh yeah for sure so uh early on in the project we were looking whether a monetary incentive model would be the right play we decided against that because often decentralized monetary models often hurt the protocol and what I mean by that is often uh often there's a lot of overhead in checking if there's actually like if you're actually providing the data or not uh and that is uh that would make the pro that would make the protocol a lot less usable but as well it would kind of caus uh race to the bottom uh can you Pro like if you provide all this data you'll be paid X much but you only need to uh reply within like 5 seconds so if you could like have all this data and you only need to provide in x amount of time uh how can you game the system and I think by not doing a monetary system and more building towards like how can we build the most efficient client possible so that it's basically like you add this to your execution client or you have this in your app and you don't even know what's running in the first place uh I think there's massive advantages there and then if well if ethereum is This Global Currency and we have the utility of basically like everybody who's actually using ethereum because portal would have quote unquote instant sync times uh I think I think the utility is U much higher than the cost uh which is most like like your biggest cost will likely be storage speed or not storage speed storage capacity like how much storage the portal client uses and as I said before that's configurable so maybe some people will be leeches but our belief is that uh like a gigabyte of storage is so small nowadays uh nobody would even notice that uh so in short we don't have a monetary incentive model uh instead we have a like a use like uh usability incentive mod in that we believe our protocol is useful and if it's not useful it shouldn't exist in the first place yeah like the incentivization model is that you want to access the history right it would happen in eum because we plan to support the full Json RPC so yeah um so yeah another question coming in in the longer run would the El and the CL forward specific requested port in order to reduce load uh so that's an interesting note uh there's been talk of uh so in a post verical work world will when you have uh stateless execution clients and you are also using a stateless consensus client uh how do you send a send a trans action to the network and one of the early ideas of this is well you're going to need a new network what isn't Dev P2P uh because because uh because uh a stateless execution client using veral could just get the block directly from the consensus layer so the idea is what if we had a a transaction gossip Network or a portal Network which was I guess a replacement Network to P2P for uh sending around uh transactions so uh I do think for like a transaction re relaying a portal will be basically serve a very important use case for stateless clients uh and then and then if we if we conserve that for stateless clients we then do execution clients maybe they can just use that as well and then with veral maybe the execution layer doesn't even need its own uh peer-to-peer protocol at all and it could just rely because if it has e for 44s and E4 fors is like well you only store the last one year to six months worth of blocks uh you can access the last six month month months worth of blocks from uh what's it called the consensus L I'm going to grab water quick but with that you can potentially kill the EXE Lay's a peer-to-peer protocol well you still need a gossip you still need to gossip transactions right you need to build the men pool so uh although like you don't you don't fish the blogs but you still need peerto peer yeah yeah you still need peerto peer but there's ways to do that without basically building like a Glide of a client and we're hoping building like if if the execution layers this big pyramid we're hoping to make smaller pyramids what form the big pyramid alog together but you can participate in the ones you want uh so it's a reduced cost for what you actually want to participate in but you can still participate in it all still lighter but yeah because you wouldn't need to store all the data awesome uh K do you have a question yeah I just quickly looked through the docs and I've seen that uh there are different uh clients for portal Network right WR in different languages uh what are you working on specifically and do do this clients like compatible with the for example consensus clients like this is it the same like you can combine any any client with consensus client the same as execution clients uh yeah for sure so uh So currently uh I work on uh Trin the rust portal client uh which is uh built by uh EF portal uh team at the ethereum foundation um I'm not sure if you were asking me to list all the clients so uh I won't necessarily do that uh but yeah so in order to approve latest data of course you're going to need access to a consensus client uh whether this is uh whether this is uh a full consensus client or a consensus like client to get uh historical summaries which is basically just like a list of block headers uh which are considered valid in the chain uh so if portal was to be used in an execution client it would need basically access to this consensus layer data uh if you're just going to be running a portal node alone uh we have something called the portal Beacon Network which is just like an uh a consensus leline implementation we have done uh but yeah so a portal will need access from the consensus layer the same way the execution layer uh needs it as well and there's various ways to get that and that is up to the developers I guess needs on which way they fetch that data from the consensus L yeah I thanks yeah I mean it's it's great to see that portal is all so diverse like like implementing uh uh portal in various clients so uh it benefits from the same diversity as as the ethereum mayet um yeah people can work on it in different languages uh but there's a question from Melton like which client is more advanced in the implementation of each sub protocol and it's that's a good question like what is the current state like which uh which implementations are are the furthest actually because yeah uh when I want to try portal I'm also not sure which one is the most stable to use and yeah uh so since our team is like I guess the main team we have the most resources so I would say uh Trin the rust client is the most far off client like not to break we just have more resources and more people because like no bias it's like the team well our our team's like the main team and then it like for like for example like fluffy by Nimbus uh funding comes from our team right so um I would say our team is the strongest but we also divide our responsibility for example one of our members is building uh our like statistics platform GLaDOS uh our team also focuses on writing tests and I'm also building like an execution client basically right now without dead P top to gossip like all the data with only a consensus client and a portal client and my b basically uh an execution client with no peer-to-peer so uh I would say uh like our client definitely has the most resources which gives us an advantage but uh we also build a lot of tooling for other clients because of that yeah yeah very well um thanks Kobe uh uh yeah we have a hands up from Derek you want to ask a question yeah for sure so um I a question like in in your work um how much do you specifically focus on like the actual like usability of the clients and like do you see portal as being the the primary way to bridge the gap between more experienced users and that of like just beginning users to I guess make portal and just ethereum in general more available to everyone uh yeah for sure so uh I think one of the greatest barriers to ethereum is knowledge to participate and what I mean by that is uh so in ethereum we kind of have this decentralized ethos in that like okay well we kind of want to get away from centralized entities uh like Banks because uh Banks don't have our interest so we trust this basically like this decentralized trustless peer-to-peer cloud and uh a lot of people uh access ethereum through a centralized manner and the reason they do this is because that has the lowest requirements of knowledge uh a lot lower than if you wanted to like if you wanted to run like your own execution client to access ethereum yourself which is a lot of work and I think that's unaccessible so I think portal the I think portal should be this thing that uh like applications such as wallets and higher level applications use and the users never know about uh one thing I would think portal is a success if it's used by tons of people but nobody knows what portal is uh because the moment you need to know what portal is it's a requirement of knowledge which is too high for like 99% of the population people just want to be able to send money and be like oh it's done in the right way in a secure way and I can trust it and I think with portal for the first time you're going to be able to have that and I think it's very powerful so yeah uh embedding portal uh I think will be like a major use case and just like hi developers hiding it away but getting the benefits for their users I think will be massive uh yeah thanks kobby I'm sure Derek wanted to respond but yeah uh like ideally I want to have just a flag I don't know dash dash board uh in in any client and uh be able to serve or or retrieve data um yeah there was a question from Melton uh if you can get deeper on the bridge notes if you can maybe talk more about that uh yeah for sure so uh a bridge node is a node what Bridges data from either con the consensus layer or execution layer into the portal Network so since the since all the nodes in the portal Network are just nodes that store arbitrary data according to how close they are to its uh ID um they have no way of fetching it themselves so what happens is you have like a source of data and you have a portal Noe and then you have a bridge in the middle what takes this data and sends it into the network uh one of the goals of a bridge is you shouldn't necessarily be able to identify it from any other node un unless you did some like Eclipse attack to to identify the bridge node uh which uh Eclipse attacks are basically where like you try to smother a node uh so it's like the only node that node talks to is you and you have like multiple identities uh but in the case of our state bridge we want to I guess remove the we just want to build an execution client because uh we need fine grain access to the state to do it efficiently because uh and especially most clients like G no G archival actually does it but newer clients like ref don't store the don't store proofs for every single state in the chain uh an archival re node Only stores like the proofs for the latest block and then it just stores all the accounts for all previous blocks so in order to have access to all the proofs for all time we're just writing a client to execute it our ourselves and we get some benefits like not relying on traditional execute execution clients directly which uh one thing is uh when you have to like basically request like terabytes of data from an execution client a reliability between the J and RBC come starts to become a little bit of a concern uh so uh in short bridge is just something that takes data from like an execution or consensus client and it like offers it to portal nodes through a node thank you Kobe uh we have some hands up uh buma you have a question yeah I have two question good afternoon good evening rather um the first one is about Network efficiency like what are the potential improvements or challenges in network efficiency and latency introduced by portal Network approach to data sharing uh so I think uh one challenge we currently have is so earlier I I briefly mentioned that uh it's hard to send data reliability uh reliably on UDP uh which is what dis V5 and portals built on disc V5 so what we use is something called microt transport protocol or UDP it's a protocol built by bitor to get over some of the issues with uh using all the bandwidth on the network uh we used it because it's basically you can build uh microtransport protocol as a replacement for TCP on UDP uh one of the issues that we have it with with it now is we're sending all these uh requests over talk requests which talk request is a message type by Discovery V5 and the issue with that is for packet we send it sends a response packet back so if we're sending like uh 10,000 packets in total we're actually sending 20,000 packets so one of the proposals to decrease that I guess uh performance inefficiency is by building uh microtransport protocol into the base uh dis V5 uh spec and uh currently that's in I guess various forms of talks with the main developer uh from gu I think his name is Felix he also implemented Hive so Felix on GE he implemented both Hive and end and uh testing framework and also Discovery V5 uh the main Discovery uh framework in um ethereum okay um the second one is on resource consumption like how does the new mechanism affect like um di space require M and maybe compositional overhead for different types of not especially in comparison to the current state of ethereum notes and traditional light client models uh so for I I uh for like client models currently there's only really uh consensus like clients there's no really such thing as execution like clients uh so uh to distinguish that I think we're building some new and the reason it's new is because it's really hard uh in the case of storage requirements where an execution client stores all the data uh in Portal all the data is divided up uh one efficiency we could get on top of that is by uh compressing our data because currently when we store data on Portal nodes at least in our implementation we don't compress it so doing various uh compression techniques could reduce uh storage even further further but yeah sorry sorry um one last question this is personal um at someone who is interested in distributed system security and Engineering how does like would this be like a good um approach to my career I don't know if you understand what I'm saying uh a good approach to what um I'm so much interested in distributed systems and um distributor system in generally so I'm looking for like the best um how I put it um when it comes of ethereum the best possible approach like aspect of ethereum that will help me to look further into distributed systems oh uh I guess I don't think you could go wrong by investigating uh any client uh on the terms of like I guess Network security I don't think portal is at least optimizing for that case yet we're currently as Mario said uh when is Portal even going to come out so we're trying to get it out uh the hope is that we have like Bas the full history by like around the end of the year and then we have like State coming up with by like January so like latest day in January and then by like maybe mid or later in the year we have like full access to the the state so I think portal currently doesn't have like every SEC uh security vulnerability down uh I think the consensus layer would be very interesting uh if you wanted to look into I guess uh distributed network security more because uh that's one of their main focuses of that network uh at least uh that's what I would look into hopefully I answered your question okay thank you Kobe uh we still have a hands up from Derek yeah for sure so I guess my other question was um like through throughout I guess development personally uh and then also just uh developing a client in general like what are some of the like main roadblocks or challenges that you might come across um and like what what's one thing I pick the most difficult thing I suppose as well would be an interesting question uh for sure uh I think one of the most challenging things is uh compatibility with other clients uh for one is uh UTP microtransport protocol uh over the past we have had problems uh perfectly uh getting like clients what inro properly in certain uh rare edge cases I think that is uh I think definitely one of the hardest parts about building a client would be uh like finding that you implemented a dead Locker memory leak but I think if you have any takeaway from what I said uh I think it is focus because it's really easy to build up build out and refine a ton of functionality uh write abstractions what don't get you closer to uh I guess shipping your product or shipping your client I think focusing in on what are the priorities and finding a balance of I guess maintainable code but actually getting code out there uh is very valuable because if you have users you can you can always make your code better uh but if you never ship your product it's kind of worthless and one of the problems that at least I noticed when coming back to portal when I did was just like the lack of focus in the project uh which sometimes it's hard like you're working on a project for 2 to 3 years uh you're like is this ever going to be like done uh like you have no idea why it's not working or not uh obviously writing tests and working on like statistics really helps with like finding those bugs but building a client over a long period of time uh I think the focus should be like getting something that works out there and then refining it from there because then you just avoid a lot of the cases of like I've been working on this for three years maybe you could have been working on this for two years and had something shipped and I think then if you have something out it's a lot easier to see like if people actually want your product or not or what benefits people want you to build out more uh getting information from like a user I think has a lot of value uh but if your if your product hasn't really shipped yet I don't think you can really get that so uh I guess I'm just going back to focus okay I see thank you I guess I had another more not a speculative question but I was curious about um what if you think uh Port will be ready for like demonstration or at least uh roof of concept demonstration and the next hard Fork uh I I believe the next hard Fork would be uh later into 2025 maybe mid 2025 maybe it will be earlier maybe it will be later but it seems like it's extraordinary big in terms of hard Fork so uh like we definitely want to have I guess full history by the end of the year uh which that means our portal Beacon Network which would also be deployed uh for State uh that purely that's purely on my shoulders because uh that's determined by how fast I'm able to execute blocks uh currently I have executed past the merge which is really nice nice and I'm stuck a little later after that which I should be fixing this weekend uh but once I'm able to execute to latest uh we should have latest date on the network and then from there we'll be backfilling so once we have our three main networks up we'll be able to support like 90 99 or 95% of um Json RPC functionality uh and then we'll go from there adding networks such as is a transaction index Network and stuff like that so okay sounds good I guess I thought one more question sorry um we in develop I guess because me and melson are developing our a portal client would you suggest that it's best to just um take the history history Network just fully flesh it out and then just have that completely ready or as opposed to have that mainly working then kind of SE seep into like State and Beacon chain and whatnot uh yeah uh I would fully focus on history because for one I believe that's like uh bz's initial use case but also I think it's the most mature so if you guys can like send and receive data on history I think that's super valuable because like uh that's what everybody's talking about right now so just being able to like the the faster you can I guess send and receive those content types uh and have history up and running I think that's like really powerful and I I think like well once that's done uh well you guys probably won't need to build like build an execution client yourself like I'm doing to like build a portal bridge for that data uh so once you have history done building state would be a lot easier because most of the work of state is only adding new content types and uh validation uh patterns so like once you have like the main framework uh it's a lot easier to implement other networks awesome thank you no problem awesome uh thank you so much um and uh if we don't have any questions right now I there was one before from Elon which is interesting what are the main challenges your team is going through nowadays so yeah what what challenges is Portal facing these days and uh nowadays it's a lot better than a few months ago where it was like fixing tons and tons of bugs and being like damn this is depressing I don't know why anything why nothing's working uh so now that things actually work uh I would say the main roblocks and challenges uh are mainly just like building the infrastructure to support portal uh I uh mentioned it a lot but me building an execution client to uh Gossip all the state uh I think that is our current like biggest roadblock because after that is done assuming we have like a fleet or like we build an efficient client the the more efficient and assuming we horizontally scale uh State Bridges the faster we'll have like all state done and I think I I think that's like the biggest road walker challenge because uh when people think of ethereum people think of the state this decentralized world computer uh well not the fastest computer uh uh like you get the drift so by portal having State you have like access to what makes ethereum actually interesting at all and I think like the challenge is getting there because once you have a functioning State Network everything else is way easier because it's like okay well if the state is a THX the size of any network history you only need to you s like 10x the 10 X less data and you also have like 100 to a,x less content types so like yeah just like getting State deployed and done after that's like everything easy because like state is just so massive so I think state is our greatest roadblock and I'm hoping to get it done I want to be deployed but yeah nice yeah uh yeah I I like what you said d that the state is the biggest problem um Kya yeah so uh yeah I I guess you must follow um ethereum hard Forks uh do you have your own hard Forks or or not just updates uh yeah so uh currently portal is very early on so we don't since we have like nobody using us we're very flexible in that we don't need our hard Forks uh a few months ago when I was in Prague uh I was talking to the author of ep1 and the reason why he made ep1 was because he was so annoyed with uh uh gu and parody which used to make open ethereum and I forget what else they're called uh which were the two big uh execution clients at the time which before proof of stake execution clients were the only clients and then there was also uh ethereum JS so uh I foret his name but the author of ep1 was also like the team lead of ethereum JS and he was so annoyed because he would implement this Improvement gu did and then he would realize that like open ethereum did it so I think a lot of that formalization came from like this place where like random things were happening all the time uh currently since portal has no users and as Mario keeps complaining when are you guys going to launch uh since we haven't launched sh we're very flexible uh but once we get like more stable and we actually have users I would see like an e process or an improvement proposal process to I guess be ingrained in a portal as well but in terms of uh like normal Eeps uh we do need to support ones what are related to the uh execution and consensus client in terms of consensus types and execution layer types because we support that data so uh in the next hard for yeah yeah sorry so your team builds both the protocol itself and the climent yeah well I mean all the teams can propose changes to the client are I meant to the protocol but yeah we're building we're kind of like uh research and uh Implement like an R&D team uh where something like G is well they do do R&D there's actually just like EF research what does a lot of R&D instead of like just like just only gu doing it or something yeah yeah awesome um thank you Kobe uh yeah I don't keep complaining I'm just like I remember two years ago running portal client and it worked so I wonder like you know what's been happening since then no no no don't worry I'm complaining too I complain all the time I'm like good come on guys we need to focus nice nice uh buma has another question okay um it's sorry it's about um challenges of cross chain inability and data consistency with E when ethereum interacts with um other blockchain network are there any specific strategies or protocol within PTO Network designed to facilitate um this inter sorry inability uh So currently the focus uh portal is only on uh layer one ethereum and the reason for this is to build a decentralized model such as this you need I guess a critical mass of users to support the network uh if you want to basically like store all the history in a distributed manner well then you need replications but you also need to have more decentralized storage capacity than the network requires uh so if death requires like 20 terabytes to do an archival node which stores all the proofs of the state and stores all the blocks portal would probably need 100 terabytes of distributed storage so since this is a massive problem uh our project is only focused on L1 ethereum and the reason for that is just uh that's where the users are so in order to like have this sustainable model uh that would be the goal portals are extendable so if like third party change chains wanted to build off like portal they could add their own portal protocols uh we're a very extendable uh format but our focus at the ethereum foundation is uh ethereum okay thank you thank you guys okay last five minutes do we have any any last questions from guys something to something to RP it up um okay portal later 2 is an interesting question yeah any any thoughts about that uh currently we have no focuses on doing L2 uh shipping L1 and then maybe after a year or two seeing how l2s expand one big question is uh the access patterns for l2s uh what data are people actually interested in and if uh earlier I talked about incentive models and basically it's like the sping Act of resource requirements but also utility uh is portal in the context of an L2 does it have enough utility to justify storing all that data uh that's an open question and yeah yeah I find it interesting uh because like to answer your question like you know uh the blobs are fmal so now the clients need to hold their own history so have an alternative um access to a layer to history would be interesting as well but I think it's not up to you guys I think it's something that the layer to teams should recognize and contribute to you to your efforts and for kid and so on yeah yeah if they wanted it they could build a portal L2 Network or something and yeah or a portal blob Network 100% okay awesome um okay before we up last few minutes I want to ask you whether you have some general advice for the fells like you've been through this experience so maybe something that you know you wishing you a few years ago or uh just some yeah some advice for the for the fellows going forward working on the core protocol and yeah uh for sure uh I mean advice I think is very important is always follow what you're passionate about uh stuff like money always goes but uh I guess enjoying your work is a lot more can be a lot more important uh another note to that is knowing your worth and whether like I don't know where you guys are going to work but whatever job you end up in uh knowing when it's your time to like if if you should stay on that project or not uh never feel trapped in a project and I think working hard in terms of uh if you get ahead of other people in terms of like maybe ability or wor work ethic uh I think that goes a really long way in that like if you're very new to something it can seem very very hard and daunting but if you like work really hard to like catch up and maybe exceed the people around you I think it creates a very flexible environment where you can explore your interest is and also not feel like trapped into like one area of research which I think is very fascinating uh I know various like for example uh core developers who have even jumped teams like I believe uh I forget his name but the the guy who wears the lion hat like he used to be on load star but now he's on a lion Deon yeah d l so I think having the flexibility to like uh be like open to where you work in the space uh I think is very important for like self-fulfillment and Longevity and I think longevity and enjoyment in your work and knowing you're worth or not feeling trapped I think that's one of the most valuable things that a person can be aware of because uh life is only so short and you should be able to enjoy it with freedom and if you guys know anything about Mario this guy loves freedom and man loves Freedom what can I say so yeah yeah thanks C it was really really nice uh nice way to to end uh wrap this up to end this and yeah yeah I do love freedom and that's why work in ethereum uh and uh I really I really like how you bridge that awesome yeah thank you very much kobby it was amazing uh the whole thing it's been an hour it's went pretty fast uh but we are already full hours so we got a repat up here and uh yeah again it was amazing thank you so much man I really appreciate it I believe yeah thank thank you so much I believe people learned a lot and get inspired so yeah um very well awesome um Colby is available on Discord people can ping you I hope if maybe they have some more questions or anything so yeah we're in touch and I hope to see you in Devcon uh we will have uh the cohort there so people can actually meet you in person yeah that'll be a lot of fun awesome thank you so much uh yeah thanks everyone