EPF6 Office Hours | Roberto

Okay, awesome. Very well. Uh, awesome. Thank you so much everyone for joining today. Um, welcome to another office hours with uh, uh, Ethereum researcher Roberto today.

Thank you so much for joining Roberto. Um, yeah, really glad to have you here. It's um, it's a special one. Uh, Roberto joining all the way from Australia. So, uh, we had to start a bit earlier.

We got a few more people. Um, but yeah, we have it recorded. We have some questions from people who couldn't make it. And before we get to those uh let's get started with with some sort of introduction with uh uh your background maybe I I introduced you already uh on your your work on the consensus but uh I would be curious more about your background like where you are coming from uh what did you do before you joined Ethereum and how did you join what brought you to the ecosystem uh how did you get started um working on Ethereum research?

Yeah. Yeah. It's a very good question. Uh so before joining say Ethereum I was working in quite a different industry. I was working in um embedded systems.

So embedded systems are like systems electronic systems where you have fur running inside the hardware. you can't touch the basically you can't access the the the software directly as on a computer like anything from coffee machines to biomedical devices and um so I worked on that in that industry for a long time um but then I was in a way um I started working for um like consulting companies were developing products for for clients and u and I was trying wanting to do more research compared to what they say the we we were allowed to do given the the the client's demand. Um and in the time I started but that was like 2017. Um I started getting interested into into blockchain. Um so a bit of a connection between what I'm doing now and what I was doing then is that in these embedded systems you have um you have a say in a way some case you have a distributed network is a bit of a different distributed network as components communicate not to say a long long range network but a close range one also another similar similarity is that because some of these devices devices uh mission mission critical devices you need you need to be sure that what you're doing is going to work or to minimize as much as you can the risk of bugs.

So a bit you know a bit of this background and uh uh what I saw was a lot of open problems in the blockchain world. uh that's what attracted me to move to get interested into blockchain first and then you know I I learned about Bitcoin at the time and then Ethereum and then um I found Ethereum as the um I said the most interesting uh blockchain to to to focus on. Um and then from there I started attending meetups in Sydney. There were there were meetups about you know people learning about Ethereum. I did uh I did a couple of presentations on uh cryptography trying to explain to some of people who are not technical how uh digital signatures work and then um and then somehow consensus contacted me from consensus uh which was great timing went through the interview process I joined the uh join consensus and um initially I was actually working as a developer for two three months uh but I was in a team that was working on uh on consensus protocols on implementing consensus protocols.

So I then started focusing more on the analysis of the consensus protocol itself at the time was that was the time where consortium blockchains were a thing. Um and so the consensus protocol I was working on wasn't for Ethereum mainet was for consumption blockchains. Uh but nevertheless uh from there on we work I started to specialize more on consensus protocols and also on formal verification of distributed systems and and then progressively uh we moved toward we moved uh towards working with Ethereum Foundation on um project on applying formal verification to the Bitcoin chain specification. uh which was done mainly by couple of my colleagues at the time uh John and Frank. But because of that then I started getting more and more uh interested and close to the actual work on the Ethereum protocol and from there I progressed into looking init initially work I looked on the DVT protocol which is the distributed validator technology protocol that allows an Ethereum validator to be um split into multiple nodes so that you have higher resiliency and then on the uh started working on the fast confirmation rule uh which is a rule that allows to determine with a very short time whether a block will be always canonical under some specific conditions and then what happened that yeah then I joined the theorem foundation where I've been working on I still working on this fast confirmation rule but also uh focused more and more on uh general concept of past finality for a so was a long answer to your your No, that's that's really great.

Uh that's that's a good answer and it's also very interesting. I mean, I didn't know about your background and uh it's really cool to um it's really cool to hear that uh you've actually joined like local meetups and all the way in Sydney like uh that's uh uh that speaks volumes about like the power of local communities. I I really appreciate that. Awesome. And um so so now um maybe to um uh to continue the story there was a question uh asked in the in the GitHub about um some of your um first steps as a researcher in a sense uh like uh what difficulties uh you um you joined when you were starting maybe what were some what were some uh cool problems that you tackled and uh um looking back at a time like what what is something that you wish you knew or maybe something that you had to overcome and and now now you're visit.

Good. Yeah. Um I say one probably in the field space the first problem uh I focused on was on um analyzing this consensus protocol that is called IDFT for protocol. Um and challenges were a bit uh was on actually analyzing the protocol as there was no specification. Um the challenge was on uh in a way convincing the company that was something worth working on.

Um and also in a way communicating outwards about the results of of of the work. So um so I don't have like I um what I was what I was doing before there wasn't much was in the previous industry everything was closed source. There is no open source there like all the work I was doing there was no need to um to to to uh in a way to communicate your work outputs. But in in this case I found that was one of one of the challenges actually communicate why that was a problem getting they say the consumption blockchain community at the time was that enterprise Ethereum alliance to actually to recognize that they say the value of the of the research. So let's say that that was definitely uh that was a challenge that if I in a way to go back now I would approach it the communication in a different way.

I think I think like communication is uh key in a way like you know in research you try to solve hard problems but then like if you can't communicate them effectively and especially give them a motivation that is clear to people then it might not be you may have a you may have great ideas but they are not impactful so probably that's one thing another thing was about um so the time I I I started a team a research team and uh there was definitely a lot of learning um just in in in the leading in leading a a research team so that they that has been a a lot of learning there yeah let's Thank you, Roberto. And uh I would fast forward to the to the present now. Um about your current research, what are you working on these days? Um uh I know I mean you've been mentoring in EPF as well uh to on the fast confirmation rule. Um and I'm wondering what what that experience is like.

So yeah, what what are you excited about these days? What are you working on? uh whether you're dedicating yourself to

good good so these days as I kind of briefly mentioned before my main focus the focus of my team is on the overall topic of fast finality um and so there are two streams of work one is uh this past confirmation rule which we might be renaming though um just just a spoiler uh but for now that's we haven't reached full consensus on the new name. Um anyway it's a it's um a way but by by counting at the stations that so okay I might just give a bit of more background on this. So what happened that we when we had proof of work back in the days we had a way to determine with some probability whether a block was likely to be always part of the chain but um and that was chain depth at the time. However, when we then transition transition to proof of stake with Ethereum chain depth alone doesn't mean much. what matters are the the weight that each block has in terms of weight of the at the stations that uh that vote on each block.

Uh but many services nowadays they still use you know a depth of block to give a sort of idea of how stable a a transaction is in the chain. Uh but with this rule we are actually counting at the stations. Um and with with some specific rules we are able to determine that a block that is not final yet. Uh as long as they say the network is fast enough or like you uh messages are delivered uh within a slot between two honest nodes. Uh the block will always be part of the of the canonical chain.

And this is the project that on which I've been mentoring an Ethereum protocol fellow um on this uh and the project is actually going pretty well I think um it's starting to get some uh some initial measurements of on the performance of of of the rule. Uh so that's that's very exciting actually as uh this is actually the first proof of concept that implements the rule in its entirety. There are other proof of concept but they implement only part of the rules. So actually in my opinion that has been fantastic uh uh and the the other topic I'm working on is fast finality as in uh in a way sync what in a way used to be called synality um so getting thinking of ways to get a protocol that is aligned with Ethereum's values and Ethereum's uh core properties that can give us not only finality actual finality. So what I mean is by this is economic finality in a very short time but also prevent uh some of the problems that you have with the current protocol.

The main pro problem is that um in the current protocol even if the network is good and you are honest and you propose a block you have no there is not you don't have a theoretical guarantee that your block is not going to be real out. It's not in some it's difficult to reorgate out but it's not impossible. Uh and so we want with this new protocol we also want this uh property of real resilience of the protocol. So if you're honest, you propose a block uh you know that your block will be part of the canonical chain. These are really the two perhaps another another side area is about formal verification.

So this is not something I'm currently working on directly but um I will start collaborating on with some external parties on formally verifying this fast confirmation rule and also I want to try to get the lean consensus specifications in a shape so that it's then easy to apply formal verification to them as The current is Bitcoin chain specifications are written in a way that makes them hard to be then transpiled to form a verification language and uh there are tricks we can apply so that we can still write specifications in Python. Uh but they are easy to then be transpired to some formal verification language and that that makes easy easier for formal verification methods to be applied. But in my view one of one of the value is that we can attract then formal verification experts uh if we make them easy to be translated to a formal verification language. So we can hopefully have more and more let's say external external uh parties collaborating on in increasing the security of the protocol.

Okay. Awesome. Thanks for Roberto very elaborate answers. Um, yeah, it's it's really cool. Also, we touched on the formal verification.

That's another topic. Uh, and we already have some questions from the audience. So, let's let's uh get on with that. Uh, June, go ahead. Yeah.

Uh, yeah. So, Roberto, thanks for your time. My name is Jun and I'm wondering about the the last sentences you mentioned just a minute ago. So you meant that so we are now specking lean consensus right now but uh could you elaborate more on um the specification that is uh easy to verify formally? So is it like writing the spec into the lean programming language or something like that or is there any uh method to use that?

Thank you for the for the question. It's very very good question. Um it's it's more about writing so that the specs will be written in Python is to write is in a way to constrain the set of Python that we're going to use and um in terms of features of Python in a way that then it's easy to write a mechanized tool that can translate this code into a different language that can be lean, can be daphne, can be Isabel, can be Uh there's actually also an idea specific to lean. Perhaps you could even have an embedding of this subset of Python into lean. So again specs are written in Python and then either they are transpired into a formal verification language or you can have an embedding of the subset used into that does this answer the question?

Uh yeah so so actually I'm learning the programming reasoning these days. So I'm starting starting a tutorial of lean language or uh I'm planning to learn Daphne in a few weeks few weeks later. So uh I have some handy experiences on uh Ethereum consensus and also I'm actively engaging in lin consensus specification right now. So uh I wonder that is there any resources for me to uh start those formal ver verifications uh in in the context of this Ethereum. So is there any sources that I can refer to?

You mean like resources to like like to apply for verification to distri distributed protocols in general or specific to link consensus? Uh so both of them will be fine. So uh I I also wonder about the form of verification for the distributed distribution distributed system. So is it uh the so I guess there's a lot of difference between just verifying a single program versus a distributed system. So uh yeah that was that that was one of my follow-up question but you can just uh gather those questions.

Yep.

Good cool good. Uh well in terms of like forifying formally verifying inspect I think it's probably a bit earlier. uh like in a way if you are learning I think it could be cool to try with something like more probably simpler a bit more abstract. Um so the way my the the tool I've used the most is actually Daphne and um in Daphne there are different tutorials by uh the author Leno who on actually using Daphne to formally verify this the system. So uh yeah like you more be more than happy to share links um to to to these tutorials.

In terms of fle I'm not like a I'm not I'm like I'm aware of a framework called bale b e i l n to um is used this written in working in lean that is used to uh formally distributed systems but I'm not that familiar with actual projects in lean. I'm more familiar with with projects in Daphne. Actually, we did I did work on a formal verification of uh a couple of distributed systems in Daphne. So, that one I'm very familiar with in lean less. So,

thanks for answering. So, I I should learn Daphne in this semester. Thanks.

No worries. So, yeah, send Mario the link. So yeah, in a way I'll find I'll find a way to send send you the links.

Awesome. Please do. Uh we also have the in R&D discord there is the protocol fellowship channel where you can uh meet all the fellow. Okay. uh feel free to also just pass it through me and yeah that's awesome also very excited to hear that I think that we learned a lot from the beacon chain development or specs writing and now going into the lean uh we we know much more like preparing for the formal verification and future proofing the protocol it's really great to hear I remember random verification having this like long uh paper on the beacon chain specs and it's been um it's been tough to deal with Um also

yeah one of the challenges is like um like if if you need to do this translation manually then you do a translation for a given the given version and you formally verify it and now

the specs change and there is always this. So if you have some some way to make it mechanized they bit more we make the process easier. You don't make it like uh completely automated but you have some hope to make it a bit easier.

Okay. Uh we have another question from Nando. Let's uh let's continue with that.

Hi.

Hello.

Hi.

Hello. Robert, uh, when I joined the fellowship, I read the the project wish list and I saw the implement the fast confirmation rule and I thought that it was one of the most interesting projects because I think that finalizing determining the finalization of the chain one to slot is like a very step forward in the Ethereum and but at that time it was very recent the Hleski incident with with Pectra upgrade and I was wondering uh how the fast confirmation rule would have handled that situation. Yeah, that's a very good question actually. Um so I'm not let's say I mean I'm not 100% familiar with the exact uh with in with the sequence of events with that happen with Olinski. Um like if if there like if uh if there were actual votes that that that were cast for a block at the at the time um then the first confirmation rule would have determined that that that you know block is safe and perhaps it's not because then you have let's say

problems potentially with the network. So it's it's a bit let's say I don't have a clear answer because I don't know enough of the details of how the Oleski incident evolved but like I'm more than happy to take this offline and uh if you're interested I can can look into it.

Thank you.

Very well. And um okay, Demetrius has another question.

Yes. Hi Roberto. Um um yeah, I became familiar with your work like a few days ago. So I'm not very very familiar with it. So I'm interested in the uh three slot finality protocol and so I tried to read a bit of the paper and I have this question.

So in introduction there is it is mentioned that you know a protocol that is dynamically available cannot also be safe. So we have to use this eb and flow family of protocols. Um I was wondering like uh did you use this family of protocols because they are the only the the only ones that are known? Are there any alternatives? Is research currently going?

I mean how did you reach the u the decision that uh 3SF will be the protocol to go? Um and the second question is about something else that is mentioned in this introduction um in the introduction of the 3SF paper which is about um RLMD ghost and the way that you mention it's probabilistically safe compared to instead of deterministically safe. How do you make this kind of computations? How do you reach the conclusions about this kind of safety like probabilistically safety or deterministic one? And what are the practical differences between these different uh these two different notions of safety?

Thank you. Thanks for the the great questions. Um so in terms of the first first question um the way the reason may reason we have chosen an eflow urban flow construction is because in a way we are not aware of other constructions at the moment where we can have um where we can couple a dynamic available protocol with a BFT protocol uh so that during period of synchrony uh we have the DA protocol is light and safe uh but then we have also the guarantees of the BFD protocol during periods of asynchronous like it's like we don't have a proof that this is the only way to achieve uh achieve the objective of having like of being able to um have a protocol that is in a way it gives you BFT properties during a synchrony and dynamic available protocol properties during synchrony but that's the one we know so but that that's really the answer on why we chosen the construction specifically why 3SF Um we wanted with the main drive around 3SF was to have only one voting phase per slot. So currently uh if you looked at the original single slot finality protocol it had three voting phases per slot and that means longest slots. So we wanted something that had only one protein face per slot because means faster slot which can be beneficial for defy applications or responsiveness of the system.

So that was the drive and we because of that in a way uh you always need the the three voting phases. It's that just one per slot rather than three in the same slots. So in a way we found uh this protocol to be a solutions to give us the property or some of the property we wanted. It doesn't mean it's the only protocol and in fact we are at the moment we are exploring a directions more in line with um one of Italics's latest post where he discuss the coupling in a way the DA protocol from the BFD protocol so that the dynamic protocol has smaller committees but in a way it proceeds on its own timeline and the BFT protocol uh proceeds on a different timeline and potentially has different bigger committee size so that you have a very fast and rankly available protocol and the BFT protocol can have larger valid data set so it will be a bit slower but we can accommodate relatively large validator set and because they're not coupled anymore which can have we can have short dynamic is lot for the dynamic protocol but still have relatively very large uh validator set for the BFT protocol to answer to the second question. Well, before I ask the second question, do you have any follow-up question actually on this?

Yes. So, I was not familiar with the vitalic proposal. Thank you very much. I I read the the blog post between on the comparison between SF and 3SF. No, SSF, sorry.

Um and there is a comment there about these three votes that the last vote I think it's an attestation could be handled outside the the slot duration in the single slot finality would like two votes in a slot uh make a difference and could uh make SSF viable again and a good alternative from 3SF like going from three to two votes

uh but the thing is that Those two votes are those that must be sequenced. The third one, you don't need when you do in the next slot, you don't need to wait for the last vote of the previous slot to complete. So like it can be in a way parallelized. And so the votes that actually create that that cause the slot to be longer are those two votes that we can't eliminate. So in a way no wouldn't change much because the problem with this with these two voting phase is that well where the second has to wait for enough time to make sure that the votes sent on the first one are received by all honest validators.

So because of this you you have a longer slot.

Thanks. Good. So the second question about the probabilistically deterministically it's um the reason why it's probabilistic is because okay so let me take a step back. We we have two safety uh rules in RLDD. One is probabilistic one probabilistic one is deterministic.

The probabilistic one is probabilistic because we um we rely on the fact that in say cup lot where cup you can decide with high probability you have at least one honest proposal and you have this property that if you're an honest proposer your block will always be part of the colonical chain and so the safety comes from the fact that if you go back at least kappa slot you know that in one one of one of the proposers of this law was honest and therefore the chain will always be part of the canonical chain. So this probability comes from the fact that it's a probabilistic argument because because that you have this random shuffling on who's going to be the proposer and because of this randomness you have a probabilistic argument on the probability that in a given number of slots you might you with high probability about you have at least one honest proposal. So that's where the proistic gument comes from and but they have also a say what we call in the paper fast confirmation rule it's not known rule it's called just fast confirmation which is not probabilistic it's deterministic but relies on this what we call full participation like let's say all at least twoird of the of the entire validator set to be online and honest to be able to to to use this confirmation rule that is deterministic. Whereas the one that use this prefix of the canonical chain where we use this gap parameter um this one does not rely on any level of participation in the network. Um is is this clear?

Yes, I got it. So the probability comes from the fact that you assume that uh with K probability picking from on the like validator sets for the last kappa blocks would have at least an honest validator which is not a very strong assumption. Okay, thank you.

Well, but like I wouldn't um it's not that it's not strong, it's probabilistic.

Sorry. I mean yes like assuming that would have a high probability like this event is highly likely to to to happen having a single

yeah so so because because it's a probability and the safety derives from that the safety is probabilistic

yes thank you thank you

okay thank you guys um yeah very well okay we got still 20 minutes to go we get uh bunch of great questions feel free to still raise your hand if you have uh any question. Um love to see more chat between you guys. Uh we also have some questions in the backlog. I can take those meanwhile. Okay, we have another one from Nando.

Go ahead.

Hi again. Well, can you talk a little bit more about your work in the distributed validator? Did you work on the formal verification?

Yeah. So we did work on uh we did work on writing a specification a very abstract specification using Duffne of the DBT protocol and formally verifying uh the safety basically what we showed was so we assume that there is an underlying consensus protocol that is correct we didn't specify the consensus protocol we specify the properties that you assume that this consens consensus protocol provides and then we show that under um assumption that at least twoird of the nodes in the DVT network are honest then it's impossible for the DVT uh validator to ever produce two test stations that are slashing

and we did that in

DN So you what you formally verified was the the Ethereum distributed validator specification that

was Yeah. was the specification written in DNE. Yeah.

Okay. So I I also work for Diva. I think we

we we talked to you like a few years ago in Poland.

Okay. Okay. Okay.

Yeah. So from our side we have a totally different specification for DVT. You know we did we did we do not concentrate the signing duties. We have a like a a consensus of who is going to aggregate the the the duties but after the the signing each participant signs the duty. So, but I I didn't have a look into the into your formal verification.

I'd love to to spend some time on that, but um do can you uh point me to to to that work?

Yeah, I can send the link in the discord. Uh but overall if you should be a repo on the Ethereum GitHub about the DBT protocol and there in the read me there should be a link to uh to this work but I I will also send a link.

Okay. Thank you.

In the discord.

Thank you.

Awesome. Yeah. very well. Um, feel free to keep raising your hands and I'll take the opportunity to ask one more question that Edina had in the comments uh which was interesting about uh about the future of your future maybe uh whether there is um uh whether your plan is to continue uh const research long term or maybe whether there are other fields within Ethereum more beyond that you would like to explore in the future whether there is something else that might interest you. Yeah.

Um, good question. Um, [Music] at the moment like in a in a way till we have fast finality on Ethereum which is not going to happen tomorrow. Uh, my plan is to continue to work on on this on on consensus protocols and specifically fast finality for Ethereum. uh so I don't think it's a pretty challenging uh project in itself. So I'm not thinking too much beyond that.

Uh in terms of areas of interest u there are other areas that that that catch my interest and in a way related to consensus though one is about incentives um specifically incentives um for consensus protocols. So I did the one let's say one line of work that I find um again interesting is this line of work called Basantine sorry of BIR Basantine lutistic rational consensus protocols where you assume like currently most of the literature and consensus protocol assume that actors are either honest or byent time uh whereas what happens in practice is that players are rational. So they they act in a way in a that's because they're rational, they don't want to be slashed. But of course, like we've seen with me or with timing games if players can get um an advantage without being slashed, they're not necessarily going to follow the protocol. they're going to follow the protocol protocol to the extent they're not not going to be punished and also one can say they're going to follow the protocol to the extent that they're not going to be punished more than what they gain by not following the protocol.

So this is it is very related to consensus and probably there was something um that is not directly fast working on will be this topic but it's a very challenging topic. The challenges the challenges challenges in the modeling the system like modeling what is in in a way to reason about it you need to model what the uh the objective function which is the the value that a player gets by uh behaving in a given way and that's pretty charging but that probably would be the in way that they know the next thing or the next most interesting thing for me to work on.

Awesome. Yeah, thank you, Roberto. That's that's very interesting to hear. Um, awesome. Folks, do you have any more questions?

Feel free to ask Roberto. We have a couple more people here who haven't asked anything yet. So, uh, seize the opportunity. We have last 15 minutes to go. Um, I'm going to look these to all the questions.

Okay. Um, we get again. Go ahead.

Okay. So, I want to I'd love to get your opinion about the rainbow staking. So you you like the incentives stuff and so in Rainbow Sting with with a lot of new actors participating in in the in the consensus layer signing h well I I I don't totally get how how this role will play well sign duties because for example when They say that the light clients will be part of the staking. Light clients will be like turning on and off because they see a a a smartphone or a an IoT device as a light client. So well if you can explain your view on the rainbow staking incentives and how all these new roles will play into it.

Yeah, I I say I'm I'm happy to give you my thoughts, but then say I'm not uh I say this one my core areas so I can

Okay.

Uh I I I wouldn't take my my answer necessary as the right answer the answer from an expert. So uh well with no more dep uh it's it's it's about trying to yeah different to give different roles to different participants and for the roles to be in a way or you can think of it as modeling the incentives for the purpose that a specific player is playing. So you bec because there are there I say there are part of the protocols where perhaps you don't need that much u economic security uh then then it makes sense to differentiate like you consider aspects of the protocol based on the security or perhaps on what uh on what the part participants can gain by um behaving differently from what the honest behavior is supposed to be. So because like if you take inclusion list fossil or if you take say the feralization the fernization protocol one can argue there are different there are different reasons for the participants to me be to misbehave in in each of these two protocols. because of this the incentives that are supposed to uh to guide to to basically to to you can say to force those that thinks rationally to follow that the the protocol there to behave honestly not because they uh decide to behave honestly but because they behaving honestly is what is going to give them the most gain again because there are different potentially different uh different different uh values to gain by misbehaving then it makes sense then to have two different incentive systems.

Mhm.

But again like this is um I I I'm not let's say it's not my core focus. So I'm not the most the most expert on this. Okay, thank you. Thank you.

No worries.

Awesome. Okay, great chat, guys. Do we have any more questions from the audience? Still a couple more people who haven't asked anything. We got 10 minutes to go and uh before I ask some of my last questions to give you another opportunity, folks.

Anyone? Yeah, I wanted to before you wrap up, I wanted to ask about uh some sort of advice you might have for the fellows here. I mean you uh we have most of the fellows of course are working more on development than research. We have a couple of researchers here also in this call but generally whether research or development or also like you've been mentoring harsh so you um so you have an idea what uh what the folks are working on. So, uh, whether you have some some some advice in, uh, their Ethereum core research career, something that they should, uh, so maybe something that you wish you knew, uh, years ago that would make your life easier, uh, something that might, uh, help to help them to, uh, stay on the track.

Yeah. Yeah, that's a very, very good question. Probably not an easy answer, but um, I try my best. uh let's say that probably different layers of advice. One one would be that this work for me again um was to work on what I'm passionate about as if you work on something you're passionate about and you have the energy to overcome obstacles that will arise along the way.

Um so because you are passionate about it like you don't You don't stop at the first obstacle. You just you keep doing it because at least you're enjoying it. And even if things are not necessarily working out as you hope, uh you're enjoying it. So you have a strong motivation to keep going. And eventually you'll have things that don't go well and uh like having the the the persistence of keep going.

Now keep going doesn't mean like if if let's say a way or some an approach doesn't work doesn't mean continuing that approach. It means more like not giving up and finding another approach another angle to solve a problem or another angle to um to if you want like u to get in a specific in a specific position in your career if if that's what you want. So probably that will be uh that this worked for me. Um in terms of let's say more more practical advice um finding a way to um keep up to date with the with the development probably it's definitely very important to know where to uh to identify where one can add value. Now this is tricky to do because there is a lot of information out there.

So you know clearly like you know there is ethersource there are the ACD calls. So um this probably like if there is a specific area that you're interested into I would probably try to just keep up with that area as there is a lot going on it might be hard to keep up with too many things. So just keep up with what you're with what you're passionate about. Um and then the last thing will be try to um yeah to communicate uh about what you're doing. So that as I said before like you if you have fantastic ideas but they're not communicated then uh you're probably missing an opportunity.

Very well. Thank you so much Roberto. Yeah that's awesome. I think that's uh uh that's very useful advice and uh thank you so much. Awesome.

Okay. Um another opportunity for one last question before we wrap up. I wanted to I wanted to um make sure that I have a space to ask for some important advice before we finish. But uh we have still a bit more room. So folks, if you have any more thoughts, anything you'd like to ask Roberto Okay, this is another one.

Okay, go ahead.

Yeah, just a follow up on your question, Mario. I mean, um, what I experienced so far in like in technical fields is that for people who are newcomers to the field, they will face at least a period of time where they have to get, uh, a lot of things learned until they become like good enough to get hired or and all that like to become experts on the topic. the a necessary I think element for this is to have enough funding or being able to survive to make this a job. I mean um what do you think about you know the market in Ethereum not in particular in the consensus or research but in the ecosystem as a whole like do you do you think that it's possible for this to happen or is it like a viable career option like starting from zero some like protocol fellowship and just just moving on did you so do you mean like how you make it financially viable is But in general or like is the ecosystem like to make this financially viable for everyone who wants to pursue this career or more specific? So I mean a lot of people like yourself you explained that were working in some other sector or company and then uh steadily you increase the amount of time that you spent in consensus getting more and more knowledge uh during that time until the point that you are like very useful and then you got get hired from Ethereum foundation or some kind of these teams.

Um but what happens if from day zero you have to get like a salary from this kind of like work or at least being able to survive Yeah, that's uh that's u fair that's a fair point. um like I don't have of the magic wand to you know to get the perfect solution it's more like a 21 I mean that one can try to get so in a way if you take my example like had a full-time job and I was then skiing up in blockchain and Ethereum at the same time like it's not easy Um so the solution is to have like a part-time job and you know which can give enough funds to uh to be able to you know to survive or you know better than survive and at the same time skill up in uh in Ethereum. There are also you know there are some uh I think grant opportunities or like I'm not too into uh let's say topic of uh let's say support in to the ecosystem but there are funding grants to for different projects one can try to apply to those yes but it's not easy I'm not saying it's easy it's like If you need funds and you want to uh scale up in blockchain, Ethereum, it it is challenging. There are ways and one of these is essentially trying to yeah either have a different source of income perhaps part-time ideally align with what you want to do perhaps not exactly what you want to do but at least that like like if you want to be a researcher and you get a a job as a developer is not that it's not exactly the same thing but can give you a skill that you can use as search. So if you can find an opportunity like that that that's great or see if you can find grants um in the ecosystem but yeah none of this is not like it's not easy it's not excessively easy yeah I mean we try to make it easier with EPF and we also have some um some follow-up grants for the fellows and uh and try to connect them with teams but it's always uh up to individual follows in the end like it's uh we can do only that much.

So um everything that Roberto says said still applies like it's uh it still requires some um uh some some self-directed approach and for some fellows uh it can take months or years to eventually get hired or or get some more sustainable funding but if people uh if people really uh work towards this and uh and do a good job like uh they uh they will definitely get uh get through. Uh we had like um some some junior people who were uh just starting and uh and in a year they got after after a year after after uh they started they got hired. So it took them a bit but eventually because of their motivation they managed. Yeah. And uh yeah we are at a full hour here.

So I think that's a that's a nice uh um nice point to to wrap this up on. Um yeah, thanks so much everyone. It was really great. Uh I believe that we learned a lot and also get inspired a bit. So thank you so much Roberto.

It was really great

and thank you for joining. Yeah. Awesome. And uh yeah, I'll see you fellows on Monday. Stand up.

Have a great rest of the day. And um yeah, thanks. Thanks. Thanks again everyone.

Thank you. Bye. Awesome. Bye. Bye.

Cheers.