EPF 7 AMA | Tamaghna

Transcript

Recording is on. >> Uh, welcome everybody to the second office hours AMA in the cohort 7 EPF. Today we are joined by Tamagna, a razor client who is a an alumni of EPF 6. So, another fellow who has already completed the the program and is continuing to contribute in a number of different ways across the ecosystem. Uh, maybe most notably currently as an intern at the Ethereum Foundation for the

steel team, the specs and testing team. So, yeah, thanks for joining us today Tamagna. We're going to have a rare occurrence here where I am going to host this call because Mario is in an airport. So, please bear with me as as we go through this. Yeah, so thanks for joining us. First question I wanted to ask you is just to give us a little bit more insight into your background and like what brought you to Ethereum, what got you into the fellowship, like what sort of things inspired you to to start contributing to to this open source project.

>> Oh, it's sure. For the introduction, hi, I'm Tamagna. I am currently in my fourth year of undergraduate computer science based out of Kolkata, India. So, how I got into Ethereum is a pretty fun thing like most good things in college it started with the hackathon. So, in my hackathon there were a few judges which coincidentally were also EPF alumni who were working at the Nimbus team. So, when I met them I talked to them like at that point, like, I was in such a place as an CS undergrad, like, I knew stuff, but I couldn't necessarily pinpoint what I'd be working on. So, I talked to them, and I felt like, "Hey,

this seems interesting. This is pretty fun to work at." And also, another thing that actually drew me was it was this kind of thing is moving pretty fast. Like, for cryptography research, etc., like, when I've seen it normal, like, it's it generally moves at a iceberg pace, but like, over here, the rapid iterations were something that I really liked. Like, uh something like I personally like is to move and break things fast and make them again. And like, however, all in a very concise way and without in a sloppy manner. Like, with AI, now that's also a very big problem. So, that is something that drew me close over here. And then, after that, I started looking into stuff. I was interested into the

architecture, how such a big system works in itself. Um so, that is in general what brought me. Uh then, I started uh trying to contribute. I started looking here and there, "Hey, this is there, this is there." I worked in a few, let's say, ZK jobs, etc. And then, I was like, "All right." Uh and then, like just like I said, my previous what alumni also gave me the EPF WG. I looked into it. I was like, "This is a very cool uh consolidation of the Ethereum protocol information." Um I went through that. I went I came to know about the program. I applied, and then I got selected. So, that is a brief intro to how I came

into being as a fellow. >> Awesome. Thanks, Saurabh. And yeah, so, want to see like how your project progressed through through EPF 6. Um you you uh were responsible for implementing uh some of the bits of Pure ETH in Nimbus um and yeah, now as as like an EF intern in the Steel team. Curious like uh if you want to give us a little bit more information into like what like specifically you're working on these days. I know you uh submitted the the project for having fellows work on pure ETH this time around. So, acting as a mentor for that in the Nimbus

uh client as well as like what's going on with the with the testing team. Like what sort of uh responsibilities are you taking on there? >> All right. Um uh I will start with my current work. So, right now as the testing team, I have been uh given the greatest opportunity to let's say coordinate the work around the SSZ engine API transformation. Like all of you have might I guess if you have gone through, you know what the engine API is. And also you know that it's currently in JSON and the what happens is JSON because it's a hex string and like it's very heavy. Like we would like to move it from let's say uh to a binary format. And the binary

format that is going to be used is SSZ because SSZ is something that is already native to the CL. Uh the EL will be introduced to it through this uh uh And other than that, I've been working on a few other areas, mainly um a few EI like one of my another role jobs is to prototype a few EIPs regarding blob scaling, post-quantum blobs. Like that's all that's all work in progress. Not very quite there yet because I've mostly been working on the engine API part. Um in the fellowship uh for pure ETH this time around, uh what we're looking for is

more implementations other than Nimbus. Let's say have uh Flexible Dotnet etc. Um Um it's um to have the tester on we would like to see implementations of both the SSZ execution block and also the frostless log index. I do not know the log index had a QR VIP which is basically an improvement of the 7745B proposal and so would like to see implementations coming up and guiding them. Also uh like I discussed there's also another project which is the SSZ query language

for the uh CL and uh yeah this is a bit of tricky part so like that's there so like maybe regarding this one we can have a chat in the DMs. Um so yeah so like my majorly forward where I see pure IP audit is important is two parts. Data availability basically when a data availability as per se not for the blocks but for the user side. Because how all of us interact with the blockchain is through the RPCs. But because the RPCs are generally just sending you anything like if you were again to just sending you junk and you wouldn't know if it's you or being poisoned. And the surprising part is this kind of attack recently

happened with the layer zero attack was basically an RPC poisoning attack. So the idea is to have transition the SSZ with the execution block structures into SSZ so that we can have the normal SSZ proofs which are rooted at the execution block so that the all of the RPCs have uh SSZ proof attached to it which you can verify in your browser and running a light client. Um so that's the basic idea of Oh Wait let me see. Yeah so that's the basic idea that would be happening.

Um other than that, uh also because it's also some kind of deck that I'd say because um SSZ was a invention that came out around each 2.0. So, the execution client was supposed to move to a unified encoding, but that is something that has not happened yet. And that is something I'd like to see because of both like I said, it's just like it's easier and also because of the RPC access and etc. So, that would be brief introductions to both sides.

>> Awesome. Thanks so much for that. Um yeah, let's uh have some questions from the from the uh audience here. Go ahead and raise your hands when you are ready to ask a question. Um otherwise, I have one more for you and that is um like touching both sides of like the implementation and now like the testing side of things, like how do you feel like you approach these things differently? Um like what sorts of considerations do you have to take when doing something that's uh you know, more on the implementing the feature side versus like uh testing and and trying to make sure that everything's

going to be safe and do what it's supposed to do. >> Um so, basically uh from what I see as a test like when working on the testing, it's very important to have a very descriptive testing and like let's say test everything that might occur, any kind of let's say attack vectors etc. All of these things need to be taken into account. Um let's say edge cases etc. So, it's more of a work that is very descriptive per se like you need to have a very good fuzzing, etc. These kind of things are something that I'd say on the testing side is very important. Uh however, on the client

side, which I think is more important is because writing, let's say test or Python is basically a generator, but writing a client is something that will be used in production. At the end of the day, tests are not something that are going to be used in production, but it's just going to be used to verify the production. So, writing production things, a lot of other things come into my float. I mean, code clarity, etc. should be there, but I'd say like coding patterns do change from languages to languages. Working with Nim, whoever wants to do it in Nimble, you'll the other things in Nimble, you'd see that working with Nim has its own caveats. This will be the same for,

let's say, writing in Go, some other stuff like how they like the code to be, maintainable code, etc. Also, speed matters when you're writing clients, etc. So, this is very important and in general, writing client code is uh per se uh a bit more hectic, I'd say, because you have to test it again, then you have to run uh you have to run simulations, etc. So, that's there. So, like I Yeah, that's that's what I'd say.

>> Yeah, great. Um yeah, let's hear some questions from the audience. Go ahead and raise your hand with with a question for Tamangna. Awesome. Sky, go ahead. >> Um hey, yeah, I have a quick question about the trustless lock and transaction index. Uh, seems like a couple of days after publish new AP with uh, presumably the better way to do it. It's A304. Uh, can you elaborate a bit? Uh, like I saw that 775 uh, 45B is on the project list and you suggested it there.

And I wanted to ask like what's the current state of arts with both of these? >> Um, for 7745B, there should be a get implementation from the author. From the newer one, the get author was working on it. There is apparently a branch but it's bit dirty. So, um, what I'd provide from my side is I tried to provide uh, Nimbus implementation per se for you to test it against because not sure how much the uh, it would be done in get. Uh, so that would be there.

Um, also something else that should be worked upon is let's say the process that's shipped on a devnet. On the user side, there should be let's say a small library that uses that and tries to verify all of the logs. So, that's what I'd say. Um, for the design per se like this has been going on for let's say a year. Like I have 7745 worked on it. Get implementation. This is this process is something that they're lacking. This needs more work. So, it has been a process and like this one is the most newest implementation. This one is also an implementation that say would be good with the ZKVM or let's say the history

proving part. But like yeah, so like that would be a more of a work and uh, throughout the cohort getting a implementation of uh, get a maybe if you can if a few more fellows work on it. A them up and then let's say having a few client side client doesn't use a side uh examples per se or like libraries to test it again. So like yeah, that that that would be a good explanation. Do you have any further questions regarding this?

>> No, actually yeah, I think that would be more than enough. Thank you for the heat on the library cuz I was also thinking about that how to make it accessible to uh to other teams. Yes, thank you very much. >> All right, who's next? Don't be shy. All right, well while we're waiting for people to conjure up some questions, here's one more for you. Um curious about your experience going from like working on a project during EPF to basically mentoring projects

one cohort later. Like what's that experience been like for you? What's it been like sort of integrating into the Nimbus team as an independent contributor and yeah, just talk about a little bit more about like the transition from EPF to independent contributor. >> Yeah, um so uh I'd like to start with the Nimbus team is pretty helpful. Uh then they Ethan, uh Thursa, uh Agni, they're pretty helpful people.

So let's say moving from the cohort, uh did meet with them in uh Buenos Aires. It was a great time uh roaming around with them. And after that, so what I did was I looked at the uh Yul uh implementation. I saw that they were lacking the Yul implementations. It's already a very thin team, so like what happened is they couldn't let's say they couldn't test their implementation for the RPC. The RPC was very bad. Like it was around out of 200, it was 20. So after the cohort, I started I grabbed that. I started working on that one by one knocking items out of the list. So right now it's still bad. It's like around 60 out of 200. And like they were

new RPC endpoints which were introduced, but like yeah. So it's better if we have the it's simulated V1 that would be increasing the test scores very well because 100 test scores were around for that. But like that is something another person was working on and how would the that guy is also working on the valid net. So like that's something he's pretty locked up with. So that would be done there. So that would be a moving from let's say EPF to an independent contributor.

In EPF, in this client team it's been pretty good. I'd say Ethan was the most helpful guy over there. Ethan would help me a lot because when I started it, right now I see the progressive container support in the SSL library still exists. But when when I started working on it, it wasn't it was just an idea. So when I started writing the progressive containers, there was a name in it. So what happened was I I used to get a lot of nimble problems because and then later with Ethan I diagnosed them. There were errors also because Nimbus uses something known as a Nimbus build system, which is pretty different

from the normal package manager which is nimble. So that was pretty hard. Like I had to get all of the sub vendors that inside the sub vendor directory I needed to move into the sub vendor directory. Inside that the name is inside that I needed to work and then because of this sub vendor thing was happening, if let's say I missed one or two steps, the name cache would get corrupted and everything would get to do from again after editing the sub vendors yet again etc. I fixed the first thing I did was this is too painful. I fixed this so I fixed that in SSZ the name SSZ implementation. Then the progresses were broken. I fixed that with help of Ethan of course and

we had a lot of time to say hey, this is broken Ethan. Can you have a look? All right sure. Then he was like yeah, this is fixed. Oh, this is also breaking. So like that was the thing that uh helped me a lot and then once let's say I moved from the SSZ things to Nimbus Ethan one, so the transition was very smooth because I was already habituated writing name and stuff. Um moving from a fellow to a mentor, it's it's really fun because uh just a few less last November I was amongst few people. I was uh presenting it in Buenos Aires. I worked over there and like I gathered a lot of important experience which I'll

carry forward even after let's say my climate Ethereum or even after Eth code desktop is done. It was very important for me to let's say have such great mentors. Um so and also like during my fellowship I did understand like hey, this is something a fellow might need during his internship because something so like that is also something I try to keep uh in mind while uh giving the project and like helping people out for the project mentoring them.

Uh and uh I like to thank Ethan himself because like he's the one who said to me hey, this time maybe you can take the lead on this one because you seem to you seem to have the more information regarding the EL, the different parts." So, like and also you you would be the one who'd be giving more time to the fellows on this project. Um so, thanks to him, like I can't stop thanking him enough. He he he's a very good friend now and yep. Uh so, that's this. So, like I talked to Ethan and I was like, "Hey, let's give it this time." And Ethan was like, "Sure, I I I pushed him." He was like, "Yeah, this would be great to have the project implementations."

And then we were like, "Who is going to let the PM answer to us? We helping them and whatever they need." And they were like, "Maybe you can do this stuff." And I was like, "He helped me become a mentor, too." Um yeah, so like mentoring hasn't yet started. Like a few of you have been reaching out in DMs and talking about stuff. And like I'll be happy to help you all out there. I do see a some of you guys here. So, yeah that's uh well, that's not small. So, like that would be a brief about everything. So, like it it's been pretty great moving from a mentor to a mentee to a mentor. So, >> Awesome. Yeah, we love to see the also like transitions from fellow to to

whatever happens afterwards and and really um it's super special when, you know, somebody comes back, especially so quickly, to to come and uh be a mentor for the next cohort of uh fellows. And additionally like you know, watching the relationship between you and Ethan uh bloom and just like how the closeness that you guys have have developed and the way that you work together is is also really um a special thing. So, um Yeah, making magic over here in EPF.

Who's got some questions for Tamagna? Maybe some of you that have been reaching out to him about working on the period project. We got Mohit. Go ahead. >> Hi. Can you describe a bit more about testing? Like testing requires you to look into a lot of directions at once. So, any tips about that? >> Uh regarding testing. Can you Can you just say once more? >> Yeah. >> Testing always. Um So, yeah. This is something that is true. Like testing does require you to look into a lot of directions per se.

So, something I like to do while doing this is like having a concrete list per se key and sub list to like, "Hey, get a tester head. Get this thing. Set slot, etc." These are the things I need to cover. Then inside these, these might be the things that need to go in. And then let's say in testing like generating test cases like this is something that you were I was talking today, right? Now all right, a few hours earlier this was something I was discussing with my mentor at in the year that the execution spec randomization is not something that is we'd like. So, we're also working on that even for the assistant engine API.

That is something he has asked me to work with on. So, it's an evolving process. I'd say selecting a point, knocking it one by one. Like also this is something I I personally agree. Like while working on a project, it should be the PRs themselves should be atomic. Why? Because it helps you in two things. You can in your mind space it's like, "Hey, these are the things I'm working on. So, maybe in this PR this is the stuff that gets fixed. This is the stuff that gets added." And also because it's easier for the reviewer to review. And so like atomicity does help me a lot in let's say keeping a distance of these are the things. This is the blast radius. For this exact bullet, this should be the

blast radius. So, that's what I'd say. That's good. >> All right, come on people. Don't be shy. Let's have some nice questions for for Tamagna. I'm sure Connell's probably got a question for you somewhere. Connell? >> Yeah, I have a I have a question.

>> Yeah, go ahead. >> Um yeah, I'm just curious like um how did you go about deciding which project to move ahead with? Um I'm between two projects at the moment and they're both pretty pretty intense. Um so, just curious how you sort of narrowed down what you were interested in and yeah, what edged it for you? And also, I'm curious to know like did you end up working on this your project with people or did you go solo and just build yourself? Um yeah, thanks. >> All right, so like project beyond Yeah, interesting. So, um the first thing that I'd say while selecting projects is understanding the scope per se because some things require more effort from the

client teams than others. Let's say uh EPBS if if nobody has if let's say last cohort EPBS or something like some of the clients have given. So, when we're working with EPBS, the thing is the client teams will also be working with them. So, will you be able to match their speed? Uh will you be able to help them properly? Uh and the thing is the closer let's say the feature is to getting to mainnet, the more the client teams to be engaged. Like even for fossil. Like for Fossil what I'd say is for any client team who is working on Fossil, they already have someone who is dedicated to look into those stuff. So, how would you be helping them?

Uh would they would you either be let's say because this is something that you would always need to take into consideration. You would need some time to get habituated with writing the programming language, the code base per se their coding styles. So, how fast can you How fast are the deadlines? Uh how fast can you let's say understand everything? How fast can you contribute in a meaningful manner that isn't blocking them? So, all of these things come into play and also something that I suggest upon a personal basis is that is always something I did is um some projects per se are more exploratory than others. So, the scope isn't

bo- bonded down per se. And this would actually help in um let's say uh you having a bit more freedom into look into stuff that you might like. And like what happened is during period I worked on the clients, I did also work on steel because in period we don't have tests in the steel. So, like that is something I worked upon with uh I couldn't complete it during the but like that is something I did work upon. So, having some sort of freedom and some sort of guidance is something very important. And on on another major point being is how much bandwidth of the client team itself has because they also have work. They have bogged down with work. They have deadlines on

their own. So, let's say how much will they be able to help you etc. etc. So, that is something important and what was the final part of the question? Can you just say again? >> Uh I I think you kind of answered most of it there when when you were when you're going through this. I guess the other thing was like, did you collaborate on your project or did you go solo? Like like ultimately, I just piggybacking off what you just said there. Those two projects I'm looking at, one is probably closer aligned with my interest and more relevant to what they're about to ship.

I may not. But the other project potentially has some more like learning potential. It would involve like more like sort of rust and execution client stuff, which I haven't gone super deep on before. So I'm having a hard time deciding what would be the better call. And also the the one I'm more interested in will probably be a solo build, which might might be better for projects. But yeah, very curious to hear like your thoughts on that and and if you collabed on on your project. >> Yeah, so yeah, I did like this is also something yeah, I was going to tell later. Uh The scope the scope of the project like like I said, when you start looking into the project, you'll understand how much work needs to be done. And uh like what I did was I took into account

that hey, I have three months to do coding and in that coding I need to have a finished demo at the end of the presentations. So what all can I deliver? And also like something you need to take into account might be um if anybody else wants to work upon them. If you do seem that hey, this is something that might be helpful to have someone else on. I did work with somebody. So during my cohort, I worked on the assistant execution blocks and beneath was another fellow who was working with me on the passwordless login decks. So that is how we did it.

We divided the work cleanly. So this is also something that would be important if you're working with a fellow. A clean division so like none of you block each other, but like instead you both are helping each other out towards the end goal. So that would be very important. Um It generally depends on the project scope per se. Some some projects have one people one person can pull it some might need two some might need more. So, it's it's more of a project project basis per se and like how much work you would need. So, yeah, I I on on the last like what should I like to buy? Say go on which one you're interested. That is something you'd like to work up on and like that is what I did. So, like

yeah and like also learning is very important. So, like all of us have always something more to learn. So, yeah. >> Yeah, yeah. No, that's great advice. Um I like your advice about the sort of how you distributed the work um when you're climbing. I think that's super important. Um yeah, it's just a tough call. I'm kind of very close to two. I think I'm might go for the one I'm more interested even if it's like maybe not like uh the one I would learn the most about necessarily, but might be the one that I'd have like the better sort of demo and deliverable at the end. So, that might be the cleaner one to go for. Um but yeah, thanks for your advice. It was super interesting, very helpful. So, thank you.

>> Sure. Thanks, Chris. Uh we have a question in the chat from Connell. Uh do you think that the direction of client development in the future will trend closer to something that resembles high-quality reference specs and formal verification rather than the security through redundancy that we have across the clients currently? >> Uh nice question. So, I said this is a bit controversial, but I do believe that high redundancy is something because here is what I believe personally like once you use AI AI and let's say formal verification, um

a single bug will be replicated all over. However, if you have six different people working on the feature in six different teams, there is a very small chance of this um let's say being the dominant every other place. And also the thing with formal verification which I have seen is as far as they like to say that it's mathematically correct, it generally has flaws. This is something I did see with SCR. So like once they were like, "Hey, SCR is probably verified. We can just ship it. Let's have a go like." And then so this is also something Ethan worked on. So Ethan used to complain a lot like, "Hey, there is this cases which you are missing. This is something you are missing." So having people working on it brings more eyes into it. And these kind of things

that people people or AI generally misses something you have a lot of eyes on and then you'd be something that if someone will be not everyone can give their 100% every day. When somebody is let's say giving their 80% they might come up with something like "Wait a minute, this doesn't seem right." So always that point is always there. Uh High quality spec reference is always better. So like however the spec is in generally written in such a manner that you understand the changes that are going to be done. You'd internally uh need to let's say implement uh

the caches, the data structures. How will you be handling let's say the chain that? How will you be handling the blocks, the block quarantine? How will what will be your algorithm for it be? What will be your algorithm for syncing? How strong do you want syncing to be? How uh let's say decentralization like decentralized checkpoint sync. Uh these are things like which comes once somebody has a very good understanding of the and deep understanding of what they're working on. So and so like once you move away like the spec is written in in a manner that needs implementation opens to people who are implementing it. So, like having only somebody who just looks at the specs and

just implements it, like code monkey type is not something that I personally recommend because I I do feel that the human touch rate is always important. Yes, of course. Like AI Like this is also something I believe personally. AI should be used as a tool and not as a replacement because humans are humans. They're whatever They have their cognitive ability will always be greater than any next words and token generator which AI basically is. The current elements are these auto regressive models. They are just look at the text corpus and generate the next words. So, like this will never have the capability itself to think for itself. So, that's something I would like to say.

Uh to add the point of the specificity that we've kind of get thrown around everywhere today, but it seems that it uh since I became quite successful even lean is having more client acquisition than we can right now not running house in on that. Like what you just said, like yeah, like this is also something very important. Like as much as uh formal verification is said, formal verification isn't that strength. Like if you have looked into mathematics, you would know like even in the mathematics logics, there are holes and like that is a very established uh thing. Like the very idea of the question that Turing answered was like mathematics by itself cannot always uh it's only bounded on like it cannot always answer every

question. So, like uh using final formal verification for something is not the answer for something, especially for high critical systems that Ethereum because like Ethereum is in itself a very secure system just because of the moving parts that that it has. So, like in such a system like this, just moving towards AI and formal verification and this place saying AI is okay. It's not the way to go is something I think. >> Nice. Uh there is a follow-up here saying uh how do you think this will play out as we surge closer to ZK VMs generally? Uh won't it be necessary, for example, to

implement only two to three EVMs? Uh for proving's sake, won't it actually be more dangerous to redundantly re-implement things? >> All right. So, EVM implementations, so like uh I I uh it's it's fine to have an EVM implementation in the say every client and like every language. Like that's already there, like so we are Thomas from the post-quantum team started writing Zig by implementing the EVM in it. So, like that's the something where we understandable.

The thing that is very important is these kind of things in general have security bugs in them. There might be memory leakage. There might be things that might be, let's say, uh some things they're missing. Like I don't uh I don't know how long have you been in crypto, but like the biggest uh ZK library that is used is used used to be used with StarkCom. Like it's not so much used per se, but like there were a lot of high critical bugs found in StarkCom's uh over its lifetime. So, like that is very important to have multiple implementations um because a bug that comes in one implementation would not be there, like

let's say how even from memory, like even from memory, I say different languages have their own different structure of how memory is managed, uh how the GC works. Rust uses its etc. Then they use it in the GC. Zigg uses allocated like allocated internally does everything. It's a nice interface to have around. So, this is something I'd say. And our risk five ZK EVM are from proving sick. All right. I don't know how if you have been seeing but like this the same like security bug arises in the ZK EVM ZK EVM too.

Is this bad one? What else comes to mind? I mean in general I've seen every EVM have certain kind of years like still maturity is like availed in ZK EVMs and like they have been used a lot so that's the thing and like these proofs by themselves are mathematics and codes so like code can always be wrong. There can always be some kind of timing attack or like any kind of cryptographic attack can be found let's say so that's always the problem with these kind of implementations but like like I I'd say like having some diversity is better than having no

diversity but like to re-implement yes like having redundancy is pretty dangerous so like it would rather be to have a few ZK EVMs and a lot of EVM implementations. So yeah, but that's it so like >> I would just say one more from from him to round this out is I think he's saying what he means is that actually the ZK EVMs by definition are proven to be quote-unquote correct. So implementing them more than once seems like it might introduce additional risk rather than redundant security.

Any thoughts about that? >> Good question. Let me think about it. Uh ZK-VM by definition of proven correct, yes. I mean, the math behind this is pretty solid. Yes, of course. Like, it's pretty solid. Like, this currency giving security prior and etc. But, the thing that I would be the most into is these have already have had their security vulnerabilities. These always These all have bugs in them. And these are found day by day. Somebody if this is being shipped into main and somebody exploits

it, this it can be made billions and millions of dollars of loss. So, having something that is proven correct will never work out because, like I said, mathematically, there's always holes in the system. So, like, you can never fill them in their entirety. Uh uh proof generation, like, the pipelines itself is something robust, but memory implementations, uh etc. etc. Memory leaking, then they might find some kind of bug that uh let's say the proof is uh being opened by some kind of bug that they found or some security vulnerability that might exist. And like, also, this is something that I do

believe. So, cryptography is generally never safe. This is something that is also I do believe. I'll tell you the reason why. There is no proof per se that this cryptography that we are using is something that is not being able to break. Like, before quantum computers, we did think that electric current is something that we're going to outclass. But, what happens? So, like, because it was the new computationally hard NP-hard problem that was taken at the discrete log.

However as technology advanced, it became breakable. So, why is it not that maybe someday some technology comes and says "Hey, the PIOPS or the IOPS that we are using have holes in them and maybe we can exploit them." So, then if that would be catastrophic for everyone. So, like what would happen then? That's something that is a very open question. Like even uh So, always cryptography uh lattice cryptography, hash-based cryptography, these are thought to be solid till a hole in them or till any kind of let's say uh

fault in them is found. Uh at the starting of lean Poseidon 2 was a very big uh let's say thing that everybody wanted, but on further cryptanalysis it was found that it's not as sound as we originally thought it to be. So, what would happen then? You would have implemented something on the side right or even worse. So, then later someone comes and says "Hey, inside this you can maybe exploit this kind of uh this part of the world protocol where the traffic is done or maybe in this part of the protocol where uh the Fiat-Shamir is something that is the if you have seen into cryptography, Fiat-Shamir transformation is used for transforming the random uh problems into let's say uh one is to like uh like they

just use the hash of the inputs and use and take that as the random values because random values need to be used in cryptography. And somebody comes and says "Hey, this inside this Fiat-Shamir implementation I can maybe exploit this." And the entire loop is broken. So, who is saving you from that? Nobody's going to be saving you from that. What do you do? So, like that's important. >> All right, thanks so much. Um next question is uh Uh, how does the ZK work that you did in the past? Uh, how's it been helpful for the work that you're doing now?

>> Um, I'd say uh harder Uh, okay, here's the fun part. I haven't worked with ZK in the I I don't work with ZK in my day job or I haven't worked with ZK, but like I do have an understanding of it and I do see that ZK VMs are the directionally where Ethereum is headed. So, like I have an internal understanding of what is happening. That work hasn't been very helpful to me because that is not something I worked on. I chose to work upon this. If you do choose to work upon or if I had chosen to work upon ZK VMs or lean VM etc., it might have been helpful. Like I do I like I I do I did learn pretty deep into when I did that. I

over a small prime field, I worked out examples with hand off how let's say the growth 16 uh, protocol was working. I wrote a I wrote an implementation of the fry. Like if you know fry is the basically the scheme that is used for a lot of the ZK VMs. I I do hope that's the case. I don't know if they have moved into war, but I don't think so. So, it did help me into understanding and like these kind of things always help you into understanding and the work I did in ZK part say was just writing stuff from circuits. So, like not very helpful, but like yeah, like it always helps you in having the idea and things.

>> Awesome. Thanks so much. Uh, next question from the chat. Looking back at your EPF experience, what was the biggest challenge you faced? Something that you didn't actually expect and how did you end up getting through it? >> Uh, okay, a good question. I like it. This is something that I thought One part was um, do keep checks if you're working with somebody. Do keep checks on let's say what they are working, how well they're implementing stuff because you might need to give them a bit of push. This is something that came back to bite me later. And second part is what I'd like to say is

challenge you face. Okay. So, while working with the client and implementing necessary execution blocks, the challenge I faced was there were no tests and there were no other clients which I implemented it. So, I was left in a very weird position that I had an implementation but I don't know if it's right or wrong and it still might be wrong because I don't have anyone to test it against. So, like you would only know that something's wrong when you run it through a devnet, you read the logs, you're like, "Okay, this is something where both of our clients broke. Let's debug this." And this is This is something that caused problem and this is like I didn't face this challenge but this is a challenge that mentally blocked me around feeling like saying the purest project in itself was done.

Anybody else who comes it can do it. So, like that is the biggest challenge I faced while starting I didn't think testing would be something that would be big. Like I was thinking like, "Hey, testing the code would be something that is going to be very problematic." But like these are somethings we learn but like the lack of this testing and other clients implementing the devnet is something that becomes a problem when you're implementing these kind of features. >> Awesome. Next question from the chat.

So, I'm looking into taking up the SSC execution blocks project. Couple of things that I wanted to ask like which EL clients do you think SSC execution blocks implementations in during this cohort? Would you recommend Reth or is another client more needed right now? And are Are any clients you're already in touch with or teams already putting effort into implementing these things? >> All right. Um First and foremost, like the thing that I like to say is use a language you're comfortable in.

So, pick the language like you have if you're good in Java, if the client that is interested in Java. If you're good in Go, pick Go. Like that is something I like to say like you will already have a head start over there. That is very important. If you're good in Go, good in Rust, of course pick the Rust. Are there any client teams you're in touch with? Um because this is an exploratory project and this is not something that I've been included in the protocol yet. Client teams don't have enough people to have implementations on this. Um So, that's another reason of asking the fellows to do it because we would not want the client to so invest their time doing something they'd rather be doing something that is closer to the farm.

Let's say implementing valves or implementing frame transactions. That is um uh writing things, testing things, getting the review. It's something that takes time. So, you don't want to take time away from that. So, no no team does per se has any effort per se. Um Yeah, so like I mean in general in the when it's at the EIP stage, you have an EIP to see the pieces delivered. Then you go through deliberations in AC BE, AC uh C. You debate with other people which will be the one that you're going to be giving in the farm. And then the work we're already there starts to be reviewed. So, that's generally how something moves from an EIP or an idea

stage to its uh any to the let's say inclusion. So, here is something that you guys would like. Um E T D S E T D S the current um >> you guys would like. Um, ETV, ETVs, the current uh protocol feature that is being worked upon was something that was actually worked on during the cohort by uh fellow back then who was Protus and then Protus then went forward and kept pushing it forward

before it was accepted into the protocol. So, that was how it started out and the implementation started out. So, yeah. >> All right, thank you. Uh any final questions here for Tamagna? Go ahead and write in the chat or raise your hand preferably. >> Hey, I'm sorry I did not raise my hand. Um, just wanted to chat a bit as well. Uh thank you guys for for uh doing this.

I was just wondering maybe before we finish like what is some realization, some aha moment you had uh during the cohort or after, like something that uh uh that you learned along the way as a fellow and then transitioning to contributing more long-term. Um, yeah. Uh wondering like some some something that you learned and you can share with the fellows. >> Um, something I learned is uh communication would be something that is I really learned during the fellowship because talking with let's say you talk with 45 different people regarding this feature, this thing. Um, in technical terms, you like this this

thing, this this thing is something that I really learned during the uh fellowship. Something else I learned is project management, how I sort things out, time, how much time this will take, how much time do I need to implement this, etc. is something also I learned. Um Uh this was also like my hardest uh official work that I did, let's say per se. So, that was also that helped me in let's say uh what really helped me was I'd say my code style, how I write code, how I think about code. Uh See like uh he can is all update very

stringent about code writing, about the spec, about securities per se. So, that is something I inherited while working with him. So, this is something that like the good things that I have learned throughout the fellowship. Uh help from mentors, help from others, communication uh or thinking, thinking about it, thinking about things. Uh thinking about things Uh yeah, so like that's something I'd say I learned a lot. I also learned writing Nim, which was very fun uh because Nim is a language which is

not generally very much used per se uh in any other place other than IST. So, running Nim was a great experience. The language itself is pretty pretty fun to write uh but like it's not that popular. So, like I would have never learned that were it not have been the solution. That's something I also also writing Nim did uh what what writing a lot of programming languages will help you understand this, how to think beyond programming languages. This is a question that I've seen and also a problem I've seen a lot of people face like like I like here like what I did there's a pretty famous meme of the bell curve like at the two ends like I know all of

these languages, I know all of these languages. So, this is something I said like something thinking about things in a language agnostic manner while writing it down is something that I have also learned. Uh so, that would be all of all of the major learnings. Yep. >> Yeah, thank you to Mugna. It's great to hear. Yeah. And maybe we can have more questions. Yeah, if not, um one final question for me and and it's maybe related to this and maybe quite a little bit redundant, but is there

something like a piece of advice that you might give to yourself like as you were starting the cohort something that these fellows who are just embarking on this journey can can take to yeah to to help them along their way. >> Um take your time. Do not rush into things. Think about think in a very conservative manner about the implementation timelines. Like before saying yeah, I do this in 2 weeks or 3, think like if something comes up. Like always think in such a manner that's let's say in a negative sense because like you need to have a backup for everything. Think in that manner while writing the project proposals and the timelines.

Also, be very uh What's the right word? Be very vigilant about the person you who you decide to work on the project with because that might make or break your project. So, like getting a vibe check with them, capabilities, etc. is something that would be helpful. And also, communication is very important. This is something I lacked at the beginning. Like I say a lot of things to Ethan, but I see that he didn't he didn't understand what I meant to say. And like working upon that would be very important.

>> Awesome. Thanks so much, Samagna. Here one last question from the chat. What do you think made weekly updates stand out? Good links, cool diagrams, good visuals added to the write-up, playing around with how to make my write-ups more clear and more engaging. >> Um Something I always like to do is be on the point. Don't beat around the bush. So, yeah, if you can add visuals and links, that's that's pretty great. The comic links, let's say, you might not be raising up your every week. The comic links, let's say, what is the diff you worked on? What is the problems you faced?

What were the learnings this week? If if you want to add visuals, like I'd rather say not having visuals in your the weekly weekly things because that's just bluffs it up, I'd say, for a weekly report. But like having it in this way, the presentations you do or the project proposals and presentations would be very important to have. And clear architectural diagrams are pretty important.

That helps you a lot, let's say, later on. And yeah, being clear, being precise. Um Um Uh Also, not using a lot of AI because it just bullshits a lot. So, like using that properly would be using AI properly is very important. Like I use AI. Like I use I like I used to Something I really do is I type out very fast. So, like what happens is that I have a lot of spelling mistakes. So, like I have been using AI very much to get rid of those things. So, that's important and yeah, so like that is what I have to say.

>> Yeah, as it's pretty funny nowadays that I like look forward to a spelling or punctuation or grammar mistake. It helps me to realize that this person actually took the time to write it and didn't just feed it through through a generator. So, I think that is is changing even looking at applications. I'm like, "Oh, there's a misspelled word. Great. This person wrote that." It's like proof of proof of human. Cool. Well, thanks a lot Somagna for taking some time to chat with us today and for all the work that you're doing being mentoring people through this cohort.

Really looking forward to seeing what happens with the period project and and of course with your time in the Steel team. So, thanks a lot and if you have any other questions maybe for Somagna in the future, he is in the Discord server. So, you can tag him at razorclient and I'm sure he'd be happy to answer and help out. >> Thank you so much for having me. Like it's it's it's pretty great coming from the previous cohort into this cohort and like like I was on your side. Like I used to watch these calls with a lot of people from my previous cohorts, researchers and like it's

pretty great to be here. Thank you so much Josh and Mario for giving me the opportunity to be part of the previous cohort. It was a great experience. Like I I remember it for my entirety of my lifetime. Like it's it's it was also let's say first time I worked with a lot of people. So, that is something special I'll never forget. Thank you so much Josh. Thank you so much. Mario, can cannot stop thanking you guys enough for the support you provided during the fellowship.

The different advices you had, etc. So, thank you a lot. >> Yeah, my pleasure. All right. Thanks everybody. We'll see you next week for a stand-up on Monday. >> Thank you guys. Thank you. Thanks so