EPF 6 Office Hours #3 - Project presentations 1

our first uh session for um recording is on. Yeah, thanks for the recording. Um uh yeah, uh this is our first uh session for presenting projects here at the office hours. Uh we have uh uh seven people signed up today. Uh so each doing five to 10 minutes uh of the presentation.

Um some last minute dropouts. uh we will go by the order in the uh issue in uh GitHub. So um uh here is the here is the issue and you can find your comment there. If you uh if you signed up to present uh in case there is somebody who needs to leave soon or anything like that, let me know. Um uh we can we can move you uh ahead but otherwise harsh is the first uh in the in the order here and we'll start with harsh.

Yeah. Um so if everybody can see the screen and if you're ready feel free to take it away. Yep. So first of all like my screen is visible to everyone right? Yes I believe so it's works for me.

Yeah. Hopefully. Um so yeah let's let's just start the presentation. So this time in the Ethereum protocol fellowship 6 um I'll be working on fast confirmation rule and I am being mentored by Roberto uh from the Ethereum protocol consensus team. So first of all like who am I like you guys must be knowing about me I'm a permission fellow at EPF6 right now but just a brief about me.

So I'm a undergraduate get from India. I I really like academically I really enjoy distributed systems cryptography and machine learning and I do a lot of open source work. Um before the web 3 kicked in inside me I was I'm still a maintainer at uh genkins and a member of and I primarily work in infra right now when it comes to open source and I got kicked into crypto when I was working on a core bitcoin protocol at fediment and after that I just started uh contributing to different open source repositories primarily in starkware explorations and paradigm and I was loving my time so coincidentally now I'm here and I'm loving really loving my Okay, you can go learn more about me through my website if you want to. But yeah, let's get a quick recap of what the Ethereum consensus protocol even is before we talk about the fast confirmation rule. So in brief like the proof ofstake consensus protocol right now consists of LMD ghost and Casper FFG and as you can see in the diagram um the chain is finalized by the cap uh by the Casper FFG where the branches are pruned out and it simply becomes a linear chain and after which the LMD ghost operates and finally decides the head.

So there are different technicalities in these things like LMD ghost is a synchronous consensus protocol and Casper is a partially synchronous but um we are not going to go to the technicalities of all these things. I'm just keeping it brief. If you want to know more you can go through the link here and read about the whole proof ofstake evolution that has happened. It's it's really interesting. So let's go to FCR like what is what is FCR and like why should I even care about it?

So it's a consensus layer algorithm for Ethereum that lets you finalize within 12 to 24 seconds like it's just one to two slots and that block will not be reverted instead of waiting for like 13 20 in best case scenario like 13 to 14 minutes for the full finality under Casper. So it enables the nodes to identify blocks which will not leave the canonical chain under good conditions. So that's a technical synchronous under good conditions by by outputting whether the block is confirmed or not and it has two fundamental properties of safety and monotonicity. So if the block is confirmed by the validator at a given time it has to be a part of canonical chain and that's the safe part about it and once it is confirmed it will remain confirmed for the future. That's the monotonicity and assumingly because uh nothing comes for free like right so we are not getting the full finality under the cash per FFG.

So we are paying the price here. So the price is the assumption of net network synchrony and bzantine threshold. So network synchrony is that the boards are delivered by the end of the slot within the 8 second slot. And the basentine threshold is that the dishonest dishonest stake will not go above and beyond uh our assumptions of one by third. So that was FCR in brief.

If you want to learn more about it which you should uh you can go to the research paper that I've linked down here and you'll enjoy it. And you might think like why do I care like SSF is coming like single slot finality is coming right but it's like long before we reach there and in the meantime pass confirmation rule is the way to go and Ethereum community is pretty excited about it there is a lot of things that we gain out of it first of all like users and dabs get instant near instant trans confirmations for the smaller transactions that we have which improves the UX by a huge margin like you see in the in your wallet like once you do a transaction it is actually going to be backed by the consensus that that transaction is uh confirmed and under the normal synchrony it guarantees that the block remains on the canonical chain. Also uh it reduces the risk trade reversals for exchanges that allow optimistic trade upon deposits. Also it is useful for uh PBS as it provides block builders with an indication of whether blocks that are building upon is likely to be reordered or not. So it it is actually very aha moment.

You guys must be getting some aha moment. Oh, this is actually very very useful like very helpful and that's why I think it's it's very important for us to and that for for us to implement this in clients that we already have the consensus clients. So yes, it is very important but what is the current status of this thing? Okay, it's quite complicated. Um the first original FCR that got out by Roberto and other authors, Circle tried to implement it but not exactly in a client.

they tried to benchmark this stuff and they did a very very good job in that. So there is a blog post which I've linked uh later in the slides which you can take a look at and that that gave us a very optimistic um outlook on the FCR but they did some uh not I would not say mistakes but say left out some major part of implementing FCR which does not give us the complete view. Now after that um prism also tried to do this and it's still in in its early uh early stages but it has given us a very good lance on how it is working when implemented in a client directly they have combined like LMD goes and FFG checkpoint post votes but the problem is even with the prism they have not done it completely because it's it's it's very complex when we introduce um FFG checkpointing votes counting that is kind of complex in any any imple when implemented in any client And another thing is that the specs are now changing. So they're trying to make the core logic more simplified. They're trying to enhance the story structures for the track confirmation routes and checkpoints and cross epochs are being handled now more better.

The proposer boosts are being handled nicely. So there are a lot of things that are changing. So the new spec has hasn't been implemented in any client whatsoever till now. Apart from Prism, no other client has worked on it till yet. Teu is going to work on it as per my uh knowledge but not now.

So I think it's time for other clients to join the band and I am going to work on lighthouse so that they can get new look on what is going to happen when they try to implement FCR in bit. Now this is where things get interesting what I am going to do in the fellowship. So during the fellowship I we're trying to implement a new the new FCR spec from scratch in lighthouse and lighthouse has a very interesting technical architecture compared to other clients where it uses tree states for fast state access. Now this is a very technically complex thing so I can't talk about it here but if you want to learn a bit more about how am I going to proceed with this you can go and take a look at my proposal that I've linked down there. And the vision of this project is to create and benchmark a performant version of the research prototype of the fast confirmation rule.

And I am going to include the FFG Casper with the LMD ghost. And it would be a more complete implementation of the FCR. It's going to pretty hard for sure because nobody else has done it yet and managing those checkpoints and votes is slightly complex when it comes to clients high performing clients like Lighthouse. So it will have like full FFG and LMD ghost integration for the true safety and we'll have lazy FFG support from the headphones because we don't want to scan the full attestations and I'll try to make it reorg safe as well. So hopefully my the aim of the work is to create a strong foundation for future work to happen when we start to adopt FCR in production environment.

Okay. So this this is what I'm going to do now. You might get interested. So if you are more interested in reading about all these things, I have linked a lot of stuff. These these are very detailed things.

Just go and read and you'll have a lot of fun. Yeah. Thank you. If you have any questions, you can ask up. That's the right time.

You are right on time. Uh right in the minute. So uh thank you so much for that. Um yep. Anyone has any comments, questions?

Curious. Yeah. Yeah. You can like if you are curious about it, um you can just simply go through the resources that I've shared. They are very comprehensive.

And if you want to take a shorter look, you can go to the draft proposal that I have. Even though that's sort of technically complex, but if you're good, you can you can take a look at this and you can ask me questions in my DM and on Discord or mail me or whatever you want to do. Uh just a quick reminder to please share all your slides in the discord. Um the so my slides will be on discord and it will also be linked in my proposal most probably when I make a PR on GitHub. So don't worry about that.

Yep. Great. It's just uh can be challenging to see the slides over Jetsy. they get. So any question guys?

Uh this is still using the safe block hash on the engine API or is there a new design there as well? Uh that's actually a very good question. So u ux is not uh we haven't decided on whether what should be doing what we should be doing to expose this by by the engine API or by some other means. So this is actually a research prototype. We haven't gone that far to decide about this thing.

Like there are there are genuine concerns. Do we want people to uh set their own basantine threshold beta value? Because the problem is once the beta value exceeds a certain limit, the mathematical equation will start falling apart. So we don't want that. But I we haven't really thought about what the UX is going to be directly.

So unfortunately I can't exactly give you a concrete answer on this. Okay. Okay. Thank you, Ethan. And yeah, thanks for the presentation, Harsh.

Um, it was great. Um, very well. Um, next we have actually three people who uh decided to postpone their presentation after they commented. So, Shahik uh Odinson and Vinit uh if you are here, just want to confirm that you are not presenting now. Um unless you want to want to present now let me know otherwise we will move to um uh u yeah I'm not sure if we can hear you uh so are they are you waiting for them or should I start it please uh share your slides share your screen uh if you're smart and then you can get started.

Yeah. Awesome. Uh is that visible? Yeah. Yeah.

Perfect. You can cool. So yeah, my name is Utsav and I'll be pursuing the project benchmarking ZKMS on names beacon state transition functions during this cohort and I'll be working with Dimitras who I guess is in the call as well and he had presented it in cans as well about this project and I'll try to make the presentation a little different from what was already what has already been discussed during CANs. So yeah, our winter is or not during this project. Uh let's just begin.

So Justin Drake proposed the beam chain in December last year during Devcon and the main goal is to replace the current beacon chain with the new beam chain uh due to the risk of quantum attacks and uh we need to make it we need to startify the beacon chain as well so that all the nodes then all the consensus clients nodes running the consensus clients don't need to execute those functions themselves and they could be executed on the proven networks so that the main goal of lifelines and consensus nodes would be just to verify those proofs and check that the functions are executed correctly or not. So let's just move forward and yeah these are the key features I guess most of us know uh about DMC. It will give us improved security. That's the main goal. Focusing on hashb signature or falcon signatures and we'll try to snarkify.

So uh snarkifying some of you may not have heard of that term. So basically what we want is to compute a state transition functions inside a virtual machine instead of clients running it themselves. So and the current state is that proofs can't be generated inside uh say a MacBook or any laptop because it's just very computationally expensive. So we need to modify the vehicle state and next the beam beam state to make the functions executable and that's what smartifying the consensus is. So by offloading uh all the computations to uh the ZKVMs it will be actually an off-chain execution and onchain verification of those and of course this would reduce the burdens.

So the goal is that uh just like pure does uh the proofs would be stored on data layer and it would be pruned say after 14 15 days and instead verification would be done by the nodes themselves. Uh yes the challenges are that there exist a lot of GTVMs in current ecosystem and more and more are coming recently Zisco announced similarly and most of them are using risk 5 architecture some of them are using a different architecture their own architecture so it's very difficult to say which ZKVM should we prefer and every one of them gives a different performance And the benchmarks are really not clear right now. Some of them are not exactly benchmarks to say they are just uh doing benchmarks on Fibonacci or say SA 256 and not on Ethereum itself. So that and the code base should again be modular so that uh the verify the prover can choose on which ZKVM he or she needs to uh compute it. And so let's discuss now about set transition functions.

Basically uh a block would be the operation input and it will be executed on the current beacon state and we'll get the new beacon state and this whole process needs to be done offchain because it takes a lot of computation. mainly all these operation validation attestation slashing uh state sync committing updates these all take a lot of compute and they can't be done by every node on every laptop and mobile in future so let's just discuss how the SDF is implemented it's basically a state this is it's a wrapper of three functions the first one is process locks the second one is verify lock signature and the third one is process locks So process slots is again an wrapper of process load and process epoch. And then process epoch is just a wrapper of all these functions given here. Uh and then there comes a process block which is a wrapper of all these functions. Out of these one or two needs the execution layers involvement as well such as this one consolidation request and PNS to execution claim.

Oh, so the main problems are DLS signature replication, it's very heavy and mercy updates which almost takes 90% of the time when I was checking the benchmarks and you should seeing the flame graphs and I don't think you need to worry about BLS signature verification because in the beam chain it'll probably be replaced by falcon signature or hash signatures and they are a little less heavier than these And other than that yeah it's memory intensive so we can't just give the entire state to the ZTVM we have to give the state route and then we have to give the vertical path along with this and all the state travel is a little memory intensive as well so these are the things we have to consider while choosing which ZTVM to use and how to modify the state transition functions. Now let's discuss about ZTVMs as well. I'll go quick about this. So what we need to do is uh pro verify that the computation is correct and that's what GKVM does. So it will take the pre-state route and it will take the block which validator test stations and validator operations and every other operations and it will get the posted route and uh so this whole process will be done offchain and this verification will be done by the beacon by the beacon node or beam node itself.

So they'll just check that the output which was given and the pre-state and block which was given along with the proof when they have passed that this verification works and yes we can change CGTMs need to be complete that is if state transition function is executed correctly everything is correct then proof will be valid and fraud proofs can't be uh made that is the computation we can't produce beacon state that is not matching with the operation log operation and the intermediate states need not be revealed. they should not be revealed uh which is the zero knowledge property and the most important thing is succinctness proofs should be small and they should be really fast to verify because that's the end goal we need to achieve single slot finality everything should be done within 12 seconds and okay so yeah I was trying to work around just getting an overview of the current landscape and uh came to reach this competition. So I've already worked with SP1, Rezero and Jolt. So I know a lot about them and I was reading stars as well lately a lot. Uh so I know I I know the underlying architecture of RZ as well.

So and the benchmarks have already been performed on SP1, RZ and Jolt. The first two by the re team itself and jolt I have performed it myself. Other than that these are the zinc which need to be studied more and worked on them. The newest one in it is zinc air vendor and I find it has a lot of potential. However, since the documentation is still incomplete, I'll wait a week or two before I start on that.

Okay. So now let's discuss what exactly needs to be certified. This is the ring crate uh which we discussed that state transition function slot processing everything is over here and these are the crates involved rehash sa2 DNS signature three hash is the one which uh we compute the by which we compute the straight route of the beacon jail and it takes really a lot of time here it is uh it almost takes 80% of the time when be this is the benchmark this is a flame graph I ran when I was benchmarking the race zero executing those functions and you can clearly see marker really takes a lot of time and SHA 256 takes little less time and PLS signature also take a lot of time and this is the architecture of concern zero I think the had gone over this in the can so I'll just skip it this is the architecture that's planned now it's really difficult and it will definitely undergo several changes because I don't think it will be possible to just create a trait which can be used by every VPM because they are really uh running differently everything is being done differently unless they themselves change their architecture which is really not possible. So the idea is that we can keep all the ZKVMs in the runners and the trade common functions traits will be here and orchestrator will be used to benchmark those and this is the reate where the reate will be placed and the snarkified STF and this is just benchmarking cycle risk by cycle tracker or any other ISA cycle tracker and yeah these will be exported. So basically the prover should be able to just run it through CLI and choose whichever GTVM back end he or she needs to use and proof must be generated and they can share that proof to node or whatever needs to be done and they can easily verify it.

All right. So yeah zero and sp1 the re team has already benchmarked all these functions test or test most of them are process operations and again this is from the process block and I had talked with not and he thinks that we should next be doing process slot and process epoch the problem is that some of them really are very uh don't need anything so they can be run on chain as So they really need not be snarkified right now and some of them will undergo heavy changes like process BLS to execution chain or random because BLS will be entirely replaced in the beam chain. We'll just have to wait for beam specs until then. Uh yeah, so we had already uh yeah so until yes, I was making this PPD yesterday and until then I couldn't find a workar around this and I was stuck at jolt till yesterday. So basically they don't they have their own constraint that input can't exceed this size and the execution uh can't exceed this size.

So the guest eventually panicked and so I was I was talking to Michael who is Joel's maintainer. So we both could fix it after some changes troubleshooting it and uh I have not checked the benchmarks in detail but they looked faster to me than SP1 zero. Maybe it's something good for us but the problem with voltage proof aggregation is not possible. So we wouldn't be able to make uh I mean snarkify won't really work on jolt a lot but if the execution is really fast it'll be great. Uh so the priorities are we can either just yeah all right I'll just uh yeah just two or three more slides so we'll can wait until gives this break uh and meanwhile we can just focus on which ISA is best for uh benchmarking GKVMs.

Most of them are on GK uh risk 5 and some of them use their custom CPUs and this is the main thing we talked to not and he said a centralized documentation would really be good which tracks all the GKVM comparisons and we could list all the performance issues they were facing so that the state transition functions could be modified accordingly and so I was working on Jol integration and soon I will be working on Pico integration. Uh meanwhile, Demetrius is working on OpenVM integration. The plan is to work on 809 ZTVMs to find patterns on what we can do, how to make it better and find proof aggregation strategies, recursive proving and finding pre-ompiles for cryptographic primitives that do not diminish security and would give us good results. And the problem with SSC serialization, I think we'd have to directly modify the Ethereum SSD library to make those changes. And the eventual goal is to make a comparison matrix and give performance recommendations, how to boost performance, GPU acceleration.

And of course, the strategies would be optimized for each GTVM. We can't just propose a single solution for all of them. And yes, there should be an integration guide and proper documentation as well for anyone to come and prove using the proven networks. Uh that's it for now. These are all the resources and if anyone has a question, I would love to answer that.

[Applause] Okay. Um have you thought about continuation support like uh in in the modern Zo VMs I think they should be there but uh for the state transition function it can break it can it will help in horizontal scaling right because multiple provers can work on a single segment for the computation in parallel so it you mean right this yeah that's something not every ZKVM supports right now only eight or 10 ZKVM support that and that too it's very li limited rest zero has a very r zero and s1 both have a really good documentation about that and this was uh right now announced and they both of proof aggregation so that's something that's really needed because they're working on proof aggregation and we are working on that right now and I guess that will help a lot like not only proof aggregation but also the parallelization like we want to proof in parallel so there is something called continuation as well. So maybe it's not exactly proof aggregation. Uh you mean like par proving right? Distributing the work in GPUs.

I guess that's something each proof is doing right now. Executing blocks over GPU clusters and they are doing it for the execution layer but I think it should be possible for us as well. Okay. Maybe because right now the current focus is to mainly change the straight transition functions accordingly according to proof aggregation and how it should be fitted to ZVMs. I think all this like parallel proving can be achieved later as well.

So I don't think it's the current focus of VM. Yeah, that does that does make sense. And uh about the architecture as well like I think risk 5 is is like the most u celebrated one but there's there are others as well like myips and something and I think openvm has like no CPU architecture of some sort. So like how are because it is a modular architecture that they're trying to use. So how are you choosing between them?

So maybe you will benchmark all these zika VMs in the project and then you'll pick and choose or how are you going about this? The initial step is just to create a comparison matrix and benchmark literally all the ZKVMs we know running the SCS on all of them and then maybe coming to a conclusion I don't think we can still conclude but maybe just uh get to know more which ISA is better proving architecture we can literally make any ZKVM of our own as well through that and that's would be really interesting to work on we'll Next it's the next in line we'll be working on after Jol and Valida and Valida has also announced proof aggregation themsel so we'll be working on that as well. Yeah, great. Yeah, thanks for the answering my question. Nice question.

Yes. Uh, one second. So can you see my screen? Yeah. So we are working on the block level access implementation in red.

So in Ethereum most of the blocks can be paralyzed. So over 60 to 80% of the transactions have shallow dependency chains are somewhat independent of each other. Now of course there are some level of the blocks which have a high degree of the entanglement or the long dependency chains but their numbers are quite few and keeping in mind the entire transaction execution can be done in a parallel way. So an initial effort was back when EIP 2930 which aimed at creation of the access list but I believe since it was kind of optional it reduced its effectiveness. EIP7928 or or likely we call it block level access list.

We is aim at causing the transaction to be executed parallelly by enabling the storage of the storage locations and the transaction level states. Now we can think of it something of like a state transition function like the apply bal which would take your pre-state and the bell as an input and provide the post as an output. The clients are somewhat prepared since they already use optimistic parallelizations which I believe is kind of helpful when the uh dependency change are of average size but it fails when they have uh have a long dependence attached to them. uh not only that it is kind of helpful in case of your ZKVM context as well since it would enable for the proving verification to be takes place without actually executing them and in case of stateless uh partially stateful client as well which only have to maintain a subset of the state. So it can easily do that without actually caring about the rests and it is helpful in case of your reorgs and these things since it can update the states in that.

Now this is somewhat a very brief overview of how exactly we thought of it to be helpful but there is much more to it and I believe that anyone who will read the EIP and the associated talk of it will find out. Now uh coming to the implementation part as per the EIP which I believe is kind of continuous revolving state it will involve change to that of the block structure that in your block header and the uh block body. Now the uh block header would have something like the bal hash which is the uh bytes 32 field and the block body would have the block level access list. Now it's not just a simple structure but it is uh more there is much more to it since uh it delves in a quite a depth and I believe show will give a better overview of it. Uh but all in all I can say the kind of the changes this CIP wants from us is kind of not backward compatible and will require hard work.

Hello. Can you hear me? So the block access list to implement block access list we need to introduce several structures. The block access list is is kind of a list of account changes and an account change is the state difference of for a particular account. It has several components such as slot read which store which slot has been read in a transaction.

The slot changes which is further composed of storage changes. It tracks tracks the storage slots that has been written and also the new value. The code changes tracks the code change non-chain and balance change also traces the also traces the states. This compos this these are collected together to form the block access list. To properly implement the block access list, we must we must also change the state transition function in a state transition function.

We need to track the pre state because it is needed for comparison. Then we also need to trace the storage chain, non-chain and other state difference for every transaction in the block based on the various condition given in the EIP such that what happens if the value is not changed actually I mean the new value is previous same as the previous value and also for the zero balance transfer there are also different age cases we have to consider after the recording we need to actually assemble the block level access list. Then we'll use it to validate the block data and probably next it will help us to parallelize the transactions. We have created a rough road map. I am saying it rough as the EIP is constantly evolving and as per the discord discussion there are several more changes to be made.

So at first we will make the structural changes of the block in red which is located in the alloy. So we have already done some part of it and next we'll try to implement the corresponding traces. uh I believe the VM inspectors provide the great tracing API for red and currently right now we are working on the storage tracing but we we believe that in a couple of weeks we'll be done with the tracing part and we'll go into the next part which is constructing the actual block level access list. After that we'll we'll test our implementation of the tracers and ask for review of our from our mentor and if modification is needed we will modify and meanwhile if the specs changes we'll have to take in account that too and after all that we will use the block level execution list to block level access list to parallelize the transaction and benchmark our results. In our in our project currently working is me and Isika also known as Ry and our mentor is Massie from RA.

Thank you. If you have any question you can ask us. [Applause] Uh maybe just some explanation about the 2930 which is like the current access list in the transactions and yeah they are essentially not used for acceleration anymore because like originally this was introduced for I think like to match the guest database more closely. But they have since switched their database design to this path-based storage. And now the only reason why this feature is still sometimes used is because there have been a couple gas repricings.

And if you have funds on some random smart contract that doesn't uh work well with the repricing, you can kind of abuse this access list mechanism to lower the cost to access that storage slots from that contract and still unstuck your funds. But there is not really any reason to use that feature anymore because as you correctly pointed out, it's optional. It is not reliable. It can have extra entries. It can have missing entries.

So yeah, we have gone through the IP and that's exactly what we found out like we just had a sharp contrast of when blocking the 7928 and while studying the 2930. Well, I believe that after like going a bit more in delving deep, I believe that it will be much more helpful for us to formulate exactly how this will stand out compared to that. Yeah, I mean this this new one doesn't change the gas pricing. I guess it's just to serve as a hint for other ELS to execute the block faster. Yes.

Yes. Absolutely. Thank you. Yeah, sounds good. Did the link share or I think should see chats being a little weird.

I tried the Yeah, I sent it in chat. There it goes. Okay, go ahead and post it in Discord as well because Yeah, Jy chat is not working real well. All right, let me throw that there. All right, you can all see my screen just fine.

Perfect. All right. Hi everyone. My name is Pella. I'm a third I'll be a thirdyear CS student at CU Boulder this fall.

Uh currently I'm interning at Microsoft doing some like Rust hardware security stuff. And today I'm going to tell you about my project a breath implementation of fossil. So real quick, I know a lot of it's been a couple projects already, I think at least three or so that are doing fossil implementations. So I'll keep the explanation pretty quick and try not to bore you guys with the details. But what is fossil?

fossil. There's we're going to add inclusion list, which is just a new data type of a list of signed transactions. We're going to add the inclusion list committees, which are just randomly assigned validators that propose those inclusion lists. And then we need to enforce those inclusion lists. This enforcement part is still a little murky on the best way to do it, but essentially it's ensuring that new blocks are only valid and only attested to if they include a certain amount of transactions or fill any empty block space with those transactions.

And this is all in an effort to help reduce censorship as right now I think it's like 80% or probably even more since the last time I checked the numbers of blocks are built by these large sophisticated centralized block builders uh who have been shown in the past to be censoring OFAC transactions and other things that states uh have sanctioned. So this is all in hopes that we can help make Ethereum more neutral, more credibly neutral, and less and more censorship resistance resistant. Um, getting into it real quick. As you can see on this graph, it's showing the progress of other execution layer clients and restbar is pretty far out there, but this is also based on the work that was done about five months ago and it hasn't really changed much. Uh, and this was all done by Jacob Calfman who has since stopped working on it four months ago or so.

and I talked to him and he said I was good to take over the work. Um what is what has been done so far is a basic implementation ref um it was based on the assumption that would be included in Prague. Um so that's one thing that needs to be updated and rebasing it on top of the Prague changes and other updates of ref. And then also um but sorry I'm getting ahead of myself. Uh he uh in his fork has a basic implementation that was able to do some best case scenario interop testing but was still failing a lot of other stuff from what I was able the graphs from the meeting notes.

So what's left to do is that rebasing I was talking about which is pro which I've already started is proving to be a little bit more difficult than I thought just because ref has been the insides have been rearranged quite a bit. So working through that and then also updating any changes to the spec. There's only a few pretty small things right now. So hopefully nothing major changes. Um, and then also helping contribute to the execution spec tests that are in the works right now and just general testing both in ref uh ref unit and interop test and also interop test with other clients through ktosis and other means.

And then last but not least uh different implementations of git inclusion list. Uh the spec doesn't specify this on purpose. Uh and that's to give clients more freedom to decide how they build their inclusion lists. So right now I believe it's just taking the highest fees, throwing in an inclusion list and calling it good. But you could see more complicated um schemes that maybe look how long transactions have been in the me pool to try to help with that censorship resistance part.

So maybe making that modular or just changing out for something else still up in there. So final deliverables. Um what I'm going to be aiming for is just create a ref client that is able to effectively participate in local interop testing. Um, so just get it up and running, finish the rebase, um, fix all the issues that I'm able to in the time and try to make the most battle tested, um, RET client that I can. And then a stretch goal would be having it ready for more public devets.

But this is also dependent on what the core developer schedule looks like, if Fusaka gets delayed, if Fossil even makes it into Amsterdam. So just trying to push Reth as far as I can with this uh EIP. And then there's no official mentor for this project because it isn't really official project. Uh but Reth has a very good strong open source community. I some of my first open source commits have been uh to Reth and everyone's been more helpful than anywhere else I've been on the internet.

So I'm not too worried about that. With that said, I'm still very open to a mentor if Mario or Josh wants to throw something together, but uh not a big worry of mine. And then with that said, I'll give you guys back some time. Um follow me everywhere, Pell Crab, um Telegram, Discord, Twitter, pelcrab.com, etc.

But yeah, any questions? [Applause] That sounds great. I think Paradigm is really really good when it comes to like helping open source contributors. So, you might just be able to work without a mentor as well. It's they're just way too good.

Top tier. Yeah, top tier. I've met a couple of them in person and they're all just amazingly smart people. Cool. I don't see them in the list of participants.

Yeah, sorry. That's a message on Discord by Van. He he's me. So yeah, here you Next one. Yeah.

Like in general, what's the best uh way how you recommend we organize it? Should we have like a separate call or should we do this as part of this one? Yeah. I I mean