EPF6 Office Hours | Project Presentations 2

Awesome. Okay, thank you so much Shereik. Um, so yeah, let me just give a quick intro. We can we can uh jump into the presentation and um yeah, so thank you so much for joining everyone. We are at the office hours number four now.

Um uh this is another opportunity to present uh the uh project proposal that you have. Uh here is the issue with the agenda. So you can see that there are some people who signed up for the previous week but couldn't make it. So they are presenting now starting with Shereik and there are a bunch of people who signed up afterwards. There is many people I believe there is maybe too many people to um make it in this this call.

So uh we might need to do another one afterwards uh next week. Uh but for now please keep your presentation relatively short 5 10 minutes uh so there is enough room for everybody to present and yeah Sherik please share the screen and and go ahead uh no no need to hesitate um yeah so so yeah we have the agenda in the uh in the uh in the issue there and uh yeah um you're starting

beautiful okay thank you for that intro Mario let's get started Yeah. So,

uh, hi guys. I'm Shahik and I'm working on the team validator client and I'm I'm collaborating with Mark who's also who's another permission that's Can you get what happened?

Oh.

Oh, yeah. Mark said hello. Yeah. Yeah. Uh, we're mentored by KBY ML who's one of uh one of the leads at Dream.

So, a little bit about us. Uh, my name is Shahik Naer. I've worked in the web two space for uh for for most of my experience and I'm deeply fascinated by Ethereum and uh I I wanted to and I'm more fascin fascinated towards consensus layer clients and uh it le is one of the upcoming uh cleanest code most approachable code uh consensus layer clients uh which is why I am contributing to and I can let Mark go.

Hi. Okay, I'm Mark. I've also done a lot of work in the web two space, but I've also done quite a bit of Rust and like C++ mostly mostly C++. So, I decided to do RE because one of those Rust clients, it's a new one. I thought it would be a good opportunity to like help build up like uh build up a new client, especially because like the whole client to initiative.

So, yeah.

Sweet. So, uh I I believe everyone here knows a fair bit about REM, but I can just give give a quick recap. Rem is a beam chain client but for uh but but as the beam chain specs aren't released yet for various reasons including uh like just familiarizing their developers as well as uh to promote client diversity they are building a beacon chain client and in accordance to that we are creating a validator for the beacon chain client. Eventually this validator will work for the beam chain client. Uh so we can straight up jump into what we have done so far.

Uh we started off we started off with uh reading through the we started off with a lot of research reading through the all our resources are on the last screen. Uh we watched a couple of videos the Ethereum study group videos were uh substantial in help helping us grasp these concepts as we have we hadn't done this before. uh and and then we read through the consensus specs. Although the consensus specs aren't like the most comfortable read, they have a lot of information fact in it and I recommend anyone working on a client to read through them. Uh so reading through these specs, we found that it contained a lot of uh lot of helpful functions that we believe we would use in the future.

Uh and it contained a lot of strrus. These trucks were as simple as uh like what does an attestation data look like? What does a block look like? Uh some of these were implemented in the Rh in the re code base. However, most of them were not.

So we started by implementing all of the 50 helper functions across all of the honest violated specs and all the associated strus with them. Okay. So a little bit about key stores. So currently cuz a lot of the current tooling relies on a specific format which is like EIP2335 to essentially store the private keys and public keys for validation like staking. So essentially a key store is just like that JSON encrypted format and it has a few ways to essentially oh and it has a few essential ways to get like that derived key for like actual decryption and encryption.

So like script and PBKDF2 for example. So what we did here essentially we parsed the formats and we found the the actual like key derbation function. We took that process. We actually implemented our own script function. And there's actually good reason that for because the current state-of-the-art at least in like Rust is actually 30% slower than what we had actually like we found managed to actually improve it significantly compared to like the actual current like publicly available crate.

So we were working on that. We made that implementation managed to have the the results which like that 30% boost in terms of performance and obviously it was important because like this this tooling the staking CLI use this I think the uh there's uh I think a web tool as well that also uses it so I'm trying to find out what yeah

sweet sweet uh we then found out that uh PLS signatures are used AC I mean we knew this but like PLS signatures are used across the consensus layer for a lot of processes. Uh however the ream pls create did not yet implement signing or aggregation. So uh the rebs crates uses uh the super national BLST create as well as the ZK crypto create that is optimized for ZKVMs to manage all of its BLS functions. This includes aggregation as well as signing and a couple of other functions that I'm not able to remember at the moment. Uh we went ahead and implemented it.

Uh we implemented signing. Uh we made it a trait that both the super national crate as well as Ziko crypto crate could be accessed from. Uh so if if you were if you were importing this and you wanted it to be uh you didn't want this optimized for ZKVMs, you would improve uh you you would uh you would import it with the Ziko ZK crypto tag. Uh and yeah uh Mark I went ahead and implemented signing and Mark went ahead and implemented application. Uh up next now we were at a point where we can successfully start building a beacon API client.

So with the beacon a beacon node exposes a public API called the beacon API. Uh this is how all communications between the validator client as well as between the validator client and the beacon node takes place. Uh this allows us to publish blocks. This allows us to make addistations uh fetch duties about everything a validator does uh in relation with the beacon node is that happens through this. Uh so we created an HTTP client using the request create in Rust.

Uh and the beacon API spec as shown in the picture here uh outlines everything required for the validator. They have hundreds of other APIs but this is everything required for the validator. So we went and we went ahead and implemented each and every one of them uh as functions in our rust code base that we would use later.

Oh hello. So currently there's essentially two different sort of like flows for this like there's timer based and event uh event driven validator flows. So currently there's quite a few events like according to like the current uh beacon API specs. So like reorgs heads blocks things like that.

Excuse me. Uh uh Mark I'm going to stop you for one second. I think there is that because of me now. Now can you speak now?

Oh hello.

Yeah yeah there was echo because of me. Uh

yeah. Anyway, so there essentially two types of flows like there's a time based and event driven. So as you probably know the like the API specs for events, there's quite a few of them. So event like heads, blocks, test stations, volunteer exits, those so it's a way to essentially like for the uh the beacon API like the beacon node to communicate to the validators in a sense like server side of events. So currently there's like two types.

So there's a timer base. We actually did this one because it actually allows like like precise timing like right at the slot and epoch boundary. So I have to worry about any delays because if you were to do like an API call or like event driven for that sort of thing, there might be a chance that say there's like a delay because of the network. So you didn't want to do that for like the actual like uh like event like the duty execution because in order to do that it's important to be like right on that boundary like timed perfectly. But event

it's important. It'll be useful like we're still working on uh doing like connecting some of the event driven stuff. But the plan is because we actually have some stuff done like for actually taking in the events but we're going to be using that to actually process reorgs. So if there's some sort of chain reorganization event we'll be using we'll be detecting that through the event API.

Sweet. Thank you Mark. Uh now let's jump into what we're doing right now and what we're planning to do in the future. Uh what we're working on right now is the main validator flow. Uh there's a validator flow.

md doc that outlines in within like 100 150 lines how an honest validator should function. uh each of those lines is like 100 lines of code uh when translated because it's like it'll say something like wait for a block to be proposed or wait for one third of the slot and you would have to set up an events API you would have to start a channel uh we we're we're making we're making significant progress with this and once this is done we should be able to start testing out the basic validator functions uh so we have functions for on epoch on slot on slot if you're an aggregator and on epoch end I think I think we will have to add a few more in the future but we'll see we'll see how that goes uh so on slot we will make an add a stationation on slot we'll propose and on epoch we'll fetch duties in terms of road map uh we have worked on a lot of the valative foundation uh everything required to build the validator flow now we're working on the validator flow uh eventually we will work on testing we have looked into it and we'll work on it uh using asset and curtosis. If there are any other testing tools available for validators, please let us know. Uh then we then we want to see how we can get to deploying on test nets. Uh I'm not fully versed uh with how this would work, but we'll get there.

Uh and then uh once all of that is done, once we are tested on uh once we are tested on test net, we will look into performance and UX improvements. Uh so the goal is for us is to build a minimal viable validator client for Dream. This validator client should be able to perform all the main validator duties. It should load in a key store, check what validators are in there, activate those validators, get them to the active states, fetch their duties, propose blocks if they're a proposer, make addistation if they're a tester, aggregate addistation if you're an aggregator, handle sync committees, handle reorganizations, and handle voluntary exits and do all of this without getting slashed uh slashed on like a regular basis. Thank you.

Uh that was our presentation for anyone looking for further resources. Uh this is everything that has been influential in in shaping our understanding and I uh we will share the link to this and you guys can and hope you guys find it useful too. Okay, thank you very much guys. Awesome. Um we got some comments in the chat but if you guys have any questions, comments feel free to raise your hand.

Oh. Uh, regarding the duties change on reorgs, we're actually planning to do that part. It's like I said, we're still working like it's we're still we still have a few things left to do and like reorgs is one of them. So, our plan is actually like reprocess the duties on that event. So, we are we we have taken consideration to that.

Just have to we're still working on specifically reorg. one of the last things you can really have to do before you actually get like those integration tests and like actually pulling on like the hoodie test net for example.

Okay, thank you Mark. Awesome. Yeah, very well. Um so with this we can move to the next presentation. Oudinson uh if you are ready.

Hello.

Hello.

Yeah. Uh yeah, it's a bit loading there.

Okay. Um

yeah, it's good. It's good.

Got it. I hope my screen is visible and I'm audible.

Yeah. All good. Yeah.

Yeah.

So, hi everyone. Um I am polomic and I'll be presenting my project proposal for lighouses better state cashistics. So a little brief introduction about me. I am Paula Bomik. I am currently in my final year of engineering.

I am based in Kolkata, India and currently I am a permissionless fellow in Ethepx core 6. So what I'll be talking about is the problem which led to this project project uh like in the first place. Then the current caching mechanism in lighthouse how it works and what is implemented right now. Then the project description like what I propose to work in this frame of 4 months for this project and some possible challenges or like implementation technicalities and finally some resources. So what the problem was initially?

So you all have heard about the holski pctorski incident by now. So in February this year the holski test net it faced a severe non-pality event during which the specifically lighthouse nodes they experienced this extreme memory growth in which the disk usage or the disk size it went from around 20 GB that is in normal conditions to over 100 GB. This was caused because the beacon state cache which is currently implemented in lighthouse it it is currently count based rather than memory based. I will be talking about it in the next like page next slide. So even though the cache was around 32 states, each of each state grew in size like massively up uh around I guess um 70 MB per state and due to inactivity leaks and validator penalties and because of this thing the it led to out of memory failures and validator downtime as I mentioned like holski finite nonpary incident what happened and the static L cache limitations.

So what currently is implemented in lighthouse that is they have a count of till 32 beacon states but it went to out of memory condition. So how caching currently works in lighthouse. Currently lighthouse uses this LRU cache tech um implementation. What is LU? It is a least recently used cache.

So what it does is that it keeps a track of the recently used or the recently justified and finalized beacon states because those are hot right now and those are to be reused in the future again for the newer states and it does not count the earlier states that was in the beginning like from the beginning. So as I said like around 32 states would typically occupy around 500 MB. Um but during the stress events or like what happened during hski those 32 states exceeded over two to 3 GB and that was unsustainable especially for people or like for stakers who are solo or do not have those hardware like hardware specs which would lead which would require this heavy memory usage or disk usage um in insuffic inefficient during non-finality this design choice right now it is very simple the LRU Timebased LU cache technique is very simple but during these conditions that is what happened during holski or during nonp finality conditions it leads to out of memory why is that because for finalized data currently the block roots are stored as a block slot to block root mapping this is normal like this is fine during normal conditions but whenever it Um,

I lost them. Yeah.

Yeah, me too. That's a shame. Let's u give him a a minute. I want to cut him short. H sorry about it everyone.

Um we got um Vinade in next in the line. Uh are you with us?

Yeah, you uh should.

So yeah, while we are waiting for D and I don't want to waste time on the call. So uh I guess you can get started. Prepare your screen and um Okay, awesome. Yeah, let's let's do yours and we can come back to Odinson when he comes back. Yeah.

So yeah, uh we are we have decided to work on pure that is EIP7919. Uh I'm working with Tamagana on this and our mentors are uh who is the author of the EIP and Adwat from Nimbus. Uh so yeah uh regarding pure, pure is a meta EIP which uh contains other EIPs which are important to improve accessibility uh data accessibility for Ethereum. So these EIPs are uh grouped into four uh categories. Uh we have decided to start our work with log reform EIP.

So log from EIP address a lot of uh you know uh problems with current logging systems uh which results in uh downloading uh access logs and uh some logs are missing. So there there are lot of problems. So these EIP basically you know uh proposes to resolve the inconsistencies. uh and other category is uh remove all transaction type. This and this category basically aims to replace current RLP encoding with the SSC encoding uh in in transactions.

Uh so yeah so these are the two categories which we will be uh targeting for the fellowship. Okay. There are other two categories uh like serialization harmonialization harmonization which aims to replace JSON RPC with the binary uh API and the the other one is the SSD requirements which are the dependent EIP which are required for uh uh other EIPs which are aiming to uh replace uh RLP with SSD and the other EIP. So yeah, so yeah, let's start with the log reform EIP. Logform EIP are required because there are some inconsistencies in the current login system.

Uh let's say uh uh some smart contract wallet wants to download uh the logs in some block range. uh but what happens is the the wallet or uh client has to download lot of access logs due to false positive nature of the bloom filters. Uh and uh another problem is uh because the light clients and mobile devices don't have enough resources to process lot of data. uh uh so they have to rely on the trusted uh JSON RPC providers like Infura or Alchemy uh and it's uh so the current logging system is impractical uh for the light clients and mobile devices okay so that's why log reform EIP is uh uh are trying to address this so yeah a brief u uh overview what happens uh when uh when logs are uh generated. So whenever some smart contract uh does some ERC20 token transaction or we have some swaps on unis swap or some defy transaction their log uh logs are emitted and these logs are uh basically mapped uh to certain uh op codes which are log zero and from log zero to log four by the compiler and each log op code has address topics.

topics and data. So topic is for searching or indexing the log. Uh so in current currently they are topic there are 432 bytes. These are for the topics uh and they are used whenever some e get logs json RPC API is queried uh and this uh looks for the index topics for the relevant logs. So yeah and uh so next uh part which comes into the picture is bloom filter which is the current uh which is currently used uh by the e uh get locks API uh to fetch the logs.

So bloom filter is 2048 bit mask. Uh what it does is it sets uh three bits for each transaction uh in in the header. Uh and uh whenever some log is fetched these three bits are looked whether they are uh for some uh the topic whether these three bits are set. If they are set then transaction received is downloaded. uh but the problem with this approach is uh this can be false positive.

I mean the log might not be present but it says that it's it's present. Okay. Uh we'll see how it happens. Uh so yeah this is the problem. Uh so what what really happens is if there are two uh logs uh with the uh which are mapped to the same three bits they result in conflict uh and this sometimes results in uh false positive.

Okay. So let's say if there are 100 transaction uh then there the false positive rate is guaranteed uh 33%. Okay. Uh and if as the log uh data grew grows in size, it it becomes uh more prone to the false positive and it it's uh impractical. It becomes impractical uh for light clients and uh you know deps to process it.

So here comes the EIP 7745 into the picture. So EIP7745 proposes to replace bloom filters with uh with log in with with index logging as SSSE structures. Uh so SSC structures are compact structures which uh basically uh which basically proposes that log entries will contain Merkel proofs as well which will enable trustless and verifiable uh uh data uh to be given for the log queries. uh right and there's uh it also proposes the filter maps which is two-dimensional uh sparse matrix. Uh so this two-dimension sparse matrix is basically uh reduces the conflict and it uh sets one bit for each log entry uh which helps uh clients to download the smaller uh size data and it is easier for light clients and uh resource con constraints device to process this data and uh rely on the data without uh trusting any uh you trusted API gateway.

So this is this API basically u address uh addresses the current log inconsistencies uh and it is helpful for the light clients. So yeah and the impact of this EIP implementation has recently been seen in the GT. So G has implemented it and there was some data which compared the the block query range uh between G and red and it resulted that G was fetching the same data in milliseconds while the other client was taking few seconds for that same uh log range data. So yeah uh so yeah these are the benefits and next Tamagana will present the next part. I'll go next.

Uh thanks so much for the introduction. Now like uh he has already said there are basically two parts of this EIP. The one is the log parts and the other is the SSA related parts. Um I'll just present. Yeah.

So under the SSA part there are two basically parts. Removing the old transaction basically when we migrate block to SSJ some of the receipt schina get changed and this when coupled with legacy transactions will break backward compatibility. To solve this, we are introducing SSA native transactions and SS receipts. These are in two EIPs 6404 and 6466. Uh this will help us in SSA transactions and SS receipt with also this.

There is another transaction 7706 which adds call data its own gas. And this also says to change all of the three guess gas guess guess the blob the normal execution guess and the call data gas to a singular type of changing which is exponential and also three vectors we will keep uh in place of which are already there and the second part is the SS harmonization we are also going to change the withdrawals and the whole execution block to SS. So the only thing that remains in RLP will be the uh execution state over here. 64 65s will swap with the withdrawal roots with the SS and the final the bigger one that comes as a execution block which will be 7804. uh by doing this we will be getting a binary engine API which will be something like which the beacon APIs are there unlike the current engine API so another pictogram to help this better will be this over here we'll be first starting oh yeah also there are the SS requirements the SS requirements are already being fulfilled by our mentor Ethan so we are not putting much work in that and for the time being he has already given up some workarounds to start the work.

First of all, we'll be starting off with the like we said this is we are parallelized the work will be working on the 2D logs and I'll be working on SS transaction and then SS receipts. Uh so that is uh how basically we'll be doing it. Uh yeah that's all from my side and we are open to questions. [Music] Yeah. Uh also yeah I forgot to add this uh this was already implemented in Ethereum JS on a older version of the spec but Ethereum JS has been depreciated so yeah that's also there okay thank you guys um what well uh awesome uh if anyone has any comments questions thoughts Yeah.

So um my only question would be like that uh there is this division of labor uh between you and Venit and uh you also work on another project right so I wonder like how does this how does this because we strongly recommend uh focus only on single project in EPF so I'm wondering like how uh do you see your role uh responsibility division here like how much how much scope is working on the SS your part um versus venit like what is the what is the ratio there or like how do you divide it time wise whether you first want to work on this and later focus on the other project or yeah

yeah uh so basically the both of the projects are fossil and pure for pure like I said I'll be working on the SS part we need to be starting on the 2D logs which is the harder part for him and for me it's the 6404 I will have I will have started working on this and for sale parallelly for fossil like me and Zcash are working. Zcash is looking after the P2P and the fort choice related changes and I'll be looking into the engine and the validator changes. Uh some of the work has already been done by uh Zcash which is the P2P changes and I will be almost my engine related changes are done so I can maybe put up a PR in name web 3 by the end of the week. So that is what I'm thinking and like the final decision was because uh speeds and stuff are going fine. So I decided I can work on both of them uh parallelly and also like I had a vacation so uh some of the work I I couldn't do but like yeah I do feel like it will be possible for me.

Okay. Uh just something to be careful about. Um it's a big challenge. Okay. Uh there's a question from Malik uh about what is the cost of this EIP?

I'm not sure what do you mean by the cost like a gas cost or

if you guys have um any answer

uh yeah I also don't understand the what does he mean by post?

Oh okay. um we are not actually changing anything basically related to let's say the execution of stuff we are changing uh for the logs I am not very sure that we need an answer but for the SSA part we are just transing we are translating how the data format is and uh it's not much of a computational memory headache from that side but for logs I think we need 10 can go

uh uh I The log part will not be very costly for memory uh because it is aiming to reduce the you know amount of uh data which is being downloaded currently for logs and it will reduce the log size uh uh for I mean data which is being downloaded and it will add the Merkel proof to the data uh for the trustless this uh behavior. So yeah, I mean it uh so computation wise it will uh basically help to reduce the computation on the client side. So it will help the light clients so that they won't have to rely on full nodes or trusted APIs uh for the computation of the logs. Right? Uh so yeah I I hope it answers

the aim of this EIP to actually purify the data that comes from the RPC so that we don't actually need to trust somebody to give us the right data. So this is more related to the data validity or purifying the Ethereum data rather than computation or memory. I hope that answers your question or do you have any follow-up questions?

Okay, thank you guys. Um I think we should move on uh because we are 40 minutes in on the basically second presentation now. Let's try to get back to Odinson if you are now with us and ready.

Yeah. Hello.

Yeah.

Um yeah, please try to continue. All right. Sure. So,

so I guess this is where I was cut off.

Yeah. Yeah. Go ahead.

Okay. So, as I was talking about the fixed size cache implementation, so this um current implementation that stores around 32 beacon states that typically occupies around 500 MB. But during non-fality incidents during stress events this can exceed to two or 3GB. Now that is unsustainable or like inappropriate for the solo stickers or validators who do not have those hardware specs to run this amount like run the nodes with this amount of storage or disk space. Okay.

So in inefficient during non-finanity this implementation or design choice while it is very simple this currently timebased LRU cache implementation is simple and has not been any problematic till date but it was during the non-fanity incident because of this out of memory condition. So what happens is that during the holski incident um the peers were requesting for the non-finalized blocks as they were trying to sync their local view and what lighthouse does is that it executes the state lookups for now for finalized data the block roots are stored as a block slot root to block root mapping but for unfinalized data it is a little complicated because of certain reorgs or like uh it can conflict with the side chains with the main view of the chain. So what is my project proposal? So my proposal is to replace this currently um fixed count LRU cache with memory aware LR cache. How will it work?

So currently there are this 32 states implemented like that stores the cache in lighthouse. But what we will do is that we will have a certain limit and we'll be storing the memory of this beacon state. Now what would this help in? This would avoid crashes. So this dynamic cache can avoid out ofmemory conditions in a way that whenever the limit is passed we will be evicting certain LRU states until the entire cache limit comes uh below this safe mark.

Now we will also have the option to adjust the cache like optionally adjusting the cache capacity based on the pressure or like conditions like if it is a normal condition or in stress conditions such as something that took place in the um fire holk tect incident. So certain possible tech uh did he cut off? Did he get cut off again? I think so. Yep.

And here we go again. Hi. Okay, let's give him a minute. Otherwise, we have uh uh back.

Yeah,

yeah,

I'm not sure what is happening actually. My internet looks to be good but it is just disconnecting.

Okay, let's give it one more try. And if you cannot make it or I mean this applies to everyone. If you guys cannot uh make the presentation for any reason, you can always make a recording. You can just use OBS to record your screen and do presentation locally and then share the video uh in case uh you know uh you don't feel like doing it live or you cannot make it in these calls. So um that's a that's a fallback but now yeah go ahead while that works.

Yeah. So where was I lastly before I got disconnected?

Yeah, this slide. Um,

okay.

Yeah. So some possible technical challenges. One of them would be like measuring the actual memory for the beacon state because it has a diff it has different structures such as vectors, hashmaps, arcs and accounting the actual heap usage for this would be a little difficult and like we'll be figuring it out. But one of the main challenges that even Mario was talking about with while I was sharing my project proposal with him was like mimicking this condition to check how the implementation has worked that is like how we can create a scenario for this whole incident or like a non-finality incident where this actual memory like memory based um caching would actually be helpful instead of the count based. Another is like um currently as it is a simple LRO time based LRO caching technique that is used by lighthouse from from this to migrating to a memory based this can impact performance but this would be checked upon the implementation as it like progresses and with time some resources that I would like to share is um Michael Sprrow's um lighthouse architectures video the pctor incident by sigma prime um that is a blog written by it um two issues related to this exact project proposal and how LRU cache is implemented by Lighthouse.

Um, this was my project proposal. Thank you. With a little bit of hectic.

Awesome. Thank you. Uh, it's in three parts, but uh, if we get it, thank you.

Yeah. And I also posted some review to your uh, project proposal in the repo. Thanks for submitting that. Um, yeah, I think it's a good scope and uh and a useful feature. I just think the biggest challenge there is testing because right now we don't have a network where we could simulate uh such a big uh uh non-fality with such a big state, right?

Like we cannot just take hoodie or some bitet or mainet or something to

to simulate this. So uh there might be might be some some efforts to do this uh later in coming months and um I will let you know if DevOps have some better tooling or panda have some better tooling for this but right now we are we are kind of missing this. So yeah

sure like that would be great and I also have a talk with Michael and Dapland regarding this as well.

Yeah cool. Uh yeah, any other thoughts, questions here otherwise? So looking at the last person from last week, uh we're still in the last week's call here. Um uh Vidant, um

hello. Am I audible?

Yeah. Yeah, go ahead.

Yeah, let me share my screen. So I think it is visible for everyone.

Yeah. Yeah. Good.

Yeah. Yeah. So I'm Vant Asati. So I'm from I'm CC student at IIT Dhanat basically India. So my project is back fill implementation for loadar.

Uh so this is the PR for EPF project that uh Phil has made on loadar GitHub. Yeah. So yeah so I will start with some background actually. So what is weak subjectivity? I think like most of us are like very aware about what is weak subjectivity but yeah still I would like revisit some things weak subjectivity.

So it is a concept specific to PY systems uh to address how new nodes can safely join the network and synchronize with the correct blockchain history. So in P systems uh there is this computational overhead that uh any attacker needs to have to attack the system. But in uh in P systems there is like uh uh not that technical overhead for attacking the system and like uh there have been research about certain uh attacks specifically I would say like long range attacks when uh when a uh when a validator who when two when one/ird of validators can leave the system and when their stake is uh uh when the stake is returned and off it and there is like a very long time and the nodes which uh get offline for this long time and when they try to reconnect uh reconnect to the network when they try to catch up with the network. So these one-/ird nodes if they are uh if they are attacking nodes so they can somehow manipulate uh the node to believe in wrong chain. So this is called like long range attacks.

So basically for for this uh like there is uh specifically uh a like sync mechanism was uh developed like so it is checkpoint sync. Meanwhile I will like also scroll uh about also like brief about other syncing methods. So like there are many syncing methods which are like currently uh implemented in the clients specifically I will tell about like uh the beacon clients. So yeah so like first is historical sync it is the like normal sync it involves processing all blocks from genesis or from a specified starting point to the current block. So this is most comprehensive sync method and yeah it is very resource intensive and like we need to sync from the genesis.

So as I mentioned like the long range attack so it is prone to those long range attacks and it is currently not the recommended method. Current recommended method is the checkpoint sync. So it it is faster and also it is safer. So what is checkpoint sync? So this is also called state sync.

So checkpoint sync basically it it inolves sync uh syncing to a recent finalized checkpoint allowing the node to quickly join the network and participate in consensus activities. So basically we uh we get uh a recent finalized state from some trusted node. So basically this is done currently by providing checkpoint sync urls. So the node gets the state from there and uh after that finalized state it can like uh it can move forward and like sync to the head of the chain. So like the forward syncing part after the finalized checkpoint it is like called range sync.

So we can uh like request for specific blocks in the network and like we will get it like range sync is like also for if we want to uh fill up some holes in the our like previous previous uh blocks or or so. Yeah. Then comes back fill sync. So what exactly is backfill sync? When we do checkpoint sync, we get uh we get state for finalized checkpoint and like then we do forward sync.

So we have uh the blocks from finalized checkpoint to the current head and like we are we can continue with like participating in the network validators can also start performing their duties. So like we are uh uh we are catch we have like we are catching up with the chain but we don't have the previous blocks. So for getting those previous blocks we need to do back filling. So we do this like uh uh starting from the the checkpoint state we uh request uh going backwards blocks all all the blocks up to uh there is this uh yeah there is this minimum epox for block requests. So it is like around 5 months period.

So basically we need to back sync up to almost 5 months of blocks so that like uh we can part participate in the network and like we can uh uh we can be able to fulfill beacon blocks by range requests from the network and like yeah be more useful to the network. And this issue was also like the loadar fa loadar nodes faced this issue when uh there was non-falty in the in the spectra testing in in the test nets. So yeah, so like this is basically the process basically after node starts and after week subjectivity duration it does a checkpoint scene from from a test trusted node and after that we do back sync. So yeah we get the blocks backwards and yeah it can alternatively be done up to genesis. This is for the archival nodes or like a specific uh use cases testing and all.

So generally clients do provide additional flags. If you want to like force this up to Genesis. Yeah. Like talking about lighthouse there are also like certain flags you can like limit backfill sync if it is uh taking too much of RAM or if you want to like force it to be like uh done done very fastly then you can like also provide it more RAM so that it can be done fast so that you you can serve these requests and yeah if you don't serve these requests as per the spec you will be like uh your score will be reduced and you might get disconnected and maybe blacklisted. Yeah.

So this was for the blocks and similarly we need to back fill the blobs. So currently like for the blobs all nodes are uh like expected to keep uh the blobs data but with PR dash it is going to change P- custody groups. So the blobs will be divided for different nodes like the duties will be divided which nodes will store that. So that is like more of PL specific things. So basically from the spec I got this when syncing a node must backfill columns from all of its custody groups.

So basically whatever like a node is required to serve so it needs to serve those blocks otherwise it will it will be dored and like all those consequences. So uh back fill back filling blobs is currently implemented in most of the clients. Yeah in in teu I think in lighthouse in uh Nimbus but it is currently it was in the loadar but not currently enabled in the load star. I will come to that but yeah but back film blobs and like this pd integrations these are mostly work in progress. I I like I inquired about this in the discord of like uh lighthouse and like I also like like saw on the GitHub and all like it is not currently implemented in the clients.

So like this will be new thing for me to look on. Yeah. So previous work. So in loadar uh they already had backfill implementation but uh I then inquired about it and then like discussed with the codevs. Then I got to know like it it was causing some performance issues long back.

So it was disabled. It is currently still there and I like I had explored it and yeah I was trying to grasp it and yeah so like what we want to do next. So as per the devs they are like planning to write design efficient algorithm for backfill. uh like we need to reimplement back filling from first principle so that

over time if you can just take it faster uh yeah like

yeah yeah yeah two more minutes yeah so like I will come directly to what the main things yeah so we need to like reimplement it uh from first principles and uh previously there were no worker threads in loadar as like it is a typescript client So like there are many issues with uh JavaScript like it is high level language. So like we we want to reimplement it from the scratch and uh then utilize worker threads so that we can not block the main loop main thread then testing and yeah we need to release it in load starv 2.0. So this is my like tentative timeline. Currently I'm in this stage I'm working with them.

I am getting review on like the algorithm what what we will continue with. So like week 1 to five currently I think week four five time it's so I'm basically on the algorithm design I'm like working on the proposal and I will soon share my proposal then I believe 6 to 9 I will implement back filling then for blobs and then yeah 3 weeks for testing work fixes and optimization I think this project will be little slightly uh less lesser duration Then actually because uh as I said for loadar v 2.0 release they are planning in 2 to 3 months. So we need to do all of this testing and all before that. Yeah.

So final deliverable is create implementation and testing release. Yeah. And then present my work at dev connect. So there are no official mentors currently but I would like confirm with the team uh people are helpful and I'm discussing with them. Yeah, these are my resources.

Yeah. So, if Yeah, that was it. If you have any questions specifically, if you want like more info, you will you can see the resources and I might also add some more resources here. Uh my most of the updates are in like EPF updates. So, I didn't repeat all those things here.

Okay. Thank you so much. Uh what about Well, yeah. Uh do we have any questions? and thoughts about uh the back fill yield star.

Thank you so much Vant. Uh okay, we have 90 minutes for this call. So we have 30 more minutes but again please uh make sure to keep your presentations between 5 to 10 minutes. Uh everybody now has been longer than that and we don't have enough room for more people. So please be conscious about your fellow fellows and uh uh you don't need to spend too much time explaining the basics the details about like what is what is you know clients and sync uh but focus on the actual uh uh meat of your project.

Uh Omanikin uh if you are ready uh you would be the next present.

Yeah sure I can present. Okay, awesome. Please go ahead.

Yeah, great.

Is it visible?

Yes, all good.

Hello. Yeah. So, hello everyone. I'm on this side and uh I'm working on a grandance project uh which is ZKBMS for beacon chain. this notification and this project is similar with rain plans project uh and usa have already presented so I will not go much technical and will not take much time and uh uh as we all know Justin Drake announced the beam chain proposal at the open 2024 and he also talked about Chinese nification since then validator clients are planning to integrate ZKVMs so also started experimenting with ZKVM to enable snark proving of the beacon chest transition function and also recently we got an AF blog about shipping L1 ZKVM for realtime proving so ZKVMs are in a competitive competitive world okay so this transition function is a core of beacon chain and uh it takes two inputs beacon state and beacon block and uh it uh goes with a heavy computation and gives and provide us with the output uh that is a new beacon state.

So because of this heavy computation uh we we are going to use a ZKVM which will be doing this which will be offloading this uh computation and uh uh providing us a s zero knowledge proof uh success zero knowledge proof that will that can be used to verify the valid validation of the state and we can say if it is valid or invalid and uh execv is going to take two inputs like pre pre-state root and a uh block and it will be providing us with a post state root so that and proof so that proof can be used to uh function verification that is the chain nification. Now, Grandine is currently working on SP1 and disk zero ZKVMs that are set to be most mature and uh production ready ZKVMs which currently so promise four networks with tens of thousands of validators. Our future work would be to scale this work to support larger validator sets and uh explore ZKVMs like openVM and disk that offer continuation supports. Okay. So this is grand architecture.

Uh you can see in in the repo like uh they have a state transition sort processing and epoch processing block processing uh different files for different things and we have also BLS and S SSD BLS signatures SS serialization. This is a straight transition function architecture. Basically transition function is a wrapper of process slots and uh custom process block and this process slots contains uh process slot slot processing and the epoch processing. So this epoch process epoch and custom process block custom process block uh these two functions are very computationally heavy. So we'll be mainly implementing on these two.

Current focus for the project will be to explore open VM and ZISK for potential integration. We'll be looking into the architecture and uh see what what they uh give us about continuation and uh we are waiting currently for SP1 and disk zero render reports integration reports to be get public. so that so that we can resume work. Uh currently they are private and I talked with Solius and he said that we can start uh getting to know getting f get familiar with open VM and zix till that time. In the meantime we'll also be looking in the ring clients uh repos.

They have already implement integrated spar and zero and their repos are public. So yeah we'll be looking that also. Okay. Thank you. That's from my side.

If you have a doubt, I would love to discuss.

Yeah, perfect. Thank you so much. Um, yeah, great timing.

Awesome. Any questions? Um, any ZK curious people questions, comments? Okay. And um because I don't see Onikin in this call, uh we would go we would continue with um uh Vukasin or uh excuse me.

No. Um he's he's not available today. I'm sorry. Uh it's not outdated. Uh Lucas in uh yeah Razor client on the fossil then.

Oh

yeah. Tamagna are you are you ready?

Yeah I am ready but I don't think Zcash will be joining so I'll be presenting for both of us. Um right

hi um I'm Tamagna so I have also chosen Nimbus Nimbus fossil our mentor will be Agnes Bos what is fossil basically fossil gets back create neut credible neutility for the chain we have we introduced uh I committee and they they give out um inclusion lists and this inclusion lists transactions must be included in the next block u so I'll be not going into much detail because everybody knows about it for the proposed timeline this is three parts uh for the for the first part we'll be working on the code changes we have divided uh two ways the P2P changes and the fork choice changes which will be handled by Zcash and I'll be doing the engine and validator changes for the second phase we'll be going into the interrupt testing with the prism CL and get and determine CL to check if the if Nimbus CL can consume and is able to process is the fossil enable blocks and in the final we'll be deploying it to the local test net that is being run by Jiun which has a lot of the clients participating in it and continuously monitor our implementation and also help in some other Nimbus efforts for fossil and then if we have time we might also check out things like 6second fossil fossil plus EPBS uh interop for Nimbus and stuff like that. Um so for uh the updates from us uh the P2P changes the PR has been already put up by Zcash and it has already received uh some feedback from the team and I'll be doing the Indian changes by this week. U yeah that's all from our side and we also had uh uh we are all scheduled for this project. So yeah, nothing much.

Any questions or anything related if anybody would like to ask?

Okay, thank you. Uh yeah, that's uh that's pretty easy. Um yes, so I mean I asked about this before, but maybe just reiterate like which uh project do you see uh has a bigger scope uh for your own work? like uh where are we going to pay more attention or we'll have to spend more time. What do you see as the bigger challenge?

Uh the bigger challenge will be pure because for we have already mapped out the work and like we already know where the changes are going which changes will be going and how fast we already have a timeline but for pure I'll need to sit with the e codebase and like stuff like that. So that is what also also like for purel I think some of the ch things might change some of the things may be discarded and rewritten. So I see that as the bigger challenge. So yeah makes sense. Um thank you.

Anyone else otherwise we can move on and uh there is developer. Yeah. Hey guys,

I share my screen right now.

Yeah, looking good.

All right. So, yeah, my name is DJ. Um, I have a background in computer engineering and also blockchain engineer. So my project for the EPF called sex has focused on ZK EVMs and it scalability for Ethereum. So I'm working hand in hand with the protocol team at the Ethereum Foundation is EVM team at the EU foundation and um yeah that's it.

I'll just dive you through what I'm working at right now and what I'll be working on for a while. So um my process is kind of different because uh um my tax comes in as as some research questions pop up. So these are the questions I've been given so far and um some of them is almost done some of them is heavily in progress and more will be coming in as time goes on. So my core research areas right now is um an hybrid EVM environment. So an EVM environment that can run EVM contracts and RX 5 contract.

So um this is tailored to the possible proposal for um uh and the RIX 5 enshrining RX 5 as the execution environment or sandbox for the Ethereum blockchain. So the research is aimed to having a P and um giving us data on if this is a good idea uh if this is good for compute if this is good for ZQ if this is good for statelessness if this is good for light lines and all those questions would be answered by this research. So the next question I have on my table is um um zix trace generation. So the team zix so the spin-off of um polygon so they did something unique um few weeks ago where they made their trace generation process trace generation is a stage in ZKVM proof generation. So they make their trace generation process as fast as 1.

5 GHz per second which can go up to 2 GHz per second. That's about 10x state of the art. So um my research interval was to see if this can be generalized over various ZKVM in the ecosystem having also different IS. So um the next is um Linux API system call for ZKVMs. So currently um if you are confident with ZKVMs these days most of the guest program is written in Rust and there's a reason why that is so.

So um Ross have a good abstraction for the std and the target machine or virtual machine that the ROS program is being run at. So you can easily swap out um the runtime environment using um a custom target built with LLVM back end or something. So in other language this is tightly coupled. So if I'm building for if I'm building with get and I compile it to RX 5. So, what I get is Rix 5 um Linux or RX 5, whatever OS I'm going to be running this on.

So um that poses a problem because if we transition to snackifying the execution layer fully um all the work we've put into client diversification having clients of different programming languages would be a waste. So this Richard endo is to try to expand um it's a proposal to highlight things we need to do to make ZKVMs um to be make VM be able to run um let's say get guest program as it can run red as its guest program. So um I've pretty much talked about all those so you you could check on the side but this everything I've talked about. So uh the research one EVM environment for EVM pl execution. So this is something I've been working on before the program.

So after joining the program, I'm meant to ask I finish this and also give um a report as it's an item that um the research team has on their tickets. So um the report for this that's the complete report things like how this is going to pose to computation how this is going to p to things like um an 20 token transfer how many cycles on an EVM how many cycles on um bricks five sandbox so um more questions is also documented to be answered by this report and this should be on the 15th. So the next one I'm done with this already and the report have been released. So the end goal of this is um it's possible to generalize the ZIX trace generation technique but it's um it's fairly complicated and it would have to force ZKVMs to redesign some certain component of their proof system which many ZKVM would not like to do with it for one one of the one of the um parties to have everybody use the zix ISA and um not everybody's going to do that. So um the research is report is also published and public.

So if you want to check it out, you can check it out. So the last one which is currently in progress is um highlighting all the sys calls and Linux APIs that ZKVM needs to support to be able to run Rust. not just Rust to be able to run things like get or neither mind execution client written in C# compile onto X5. So guess programs of those nature wants um wants the ZKVMs to be able to support it also. So when we snapify when we go full on on snapification of the execution client we don't just have guest program written in written for red and we can also like have to enjoy this um client diversification even during snackification.

So um I'm done with the red side currently working on the get side. So we'll be done with everything by the 30th and um yeah that's the second thing. Yeah. Yeah that's it. So for my deliverables for this there's a proof of concept which is done a research which is done report which would be done.

So um my mentor is Kev from the EF and this is me David. Thank you very much. [Applause] Thank you. Devil approach. Great.

Yeah. Um do you have any uh uh questions? Anyone any comments?

Uh yeah, one question. Uh like you said for the we will be needing to the Linux ABS and stuff like that. So um are there any plans to let's say support um direct LLVM back end uh joints or something like that because that would be helpful like also we were working for with big for because most of them support uh rust so we needed to uh we needed to link the generated file back up for us to run the code for zero. So like how does it look for a generalized solution look for all of the clients using and stuff like that?

Yeah. So um I looked into that and um it was like a a big challenge because it means um we can't just have one LVM backend for all the ZKVMs. So auto zkms have various things like pre-ompiles and various um custom related code injection they inject into their into their cache program to help them prove faster. So we can't just have one zk one um LVM backend for all the zkms. So what we are looking to do is to like see if you could have a standardized um um some standardized documents that all this all the zikvms will have to like um commit to.

So we can now still have um more like a road map to having something general where um any programming language that has um an LVM IR um which almost all programming language today do have we could easily just com combine it with um a particular back end and we can have a provable get program but that's that's still long long long away from the pipeline. Okay. Yeah, makes sense. Thank you. Thank you.

Uh we have some Okay. Research. And now for the last one. Uh it's uh Jay on the rim client. We get you here.

Yeah. May.

Awesome. tell him

so you guys can see my screen.

Yeah. So good. Go ahead.

So uh yeah, I'll be working on REM. So what is RE? Rem is uh REM is a RS based valata client for the beam chain. So before the project, uh this is about me. I'm Jay.

I'm a blockchain developer from India and I've joined permissionless. So what is beam chain? So I mean just quick introduction is beam chain is the redesigned consens layer of ethereum beacon beacon chain which is proposed by Justin at decom. So the reason behind this proposal is right now the road map of Ethereum is a decade long and before uh only once all these updates are completed we can finally bring the Ethereum into the maintenance mode and also the current implementation of Ethereum the cryptography forward is not quantum resilient. uh which means since we have the quantum chips being developed the development of quantum chips is getting multiplied uh day by day and the progress is exponential.

So there it does poses a significant threat to the Ethereum resilience to its cryptography hashing and all. So and also uh right now we also have another problem with the decentralization with the validators uh being centralized like only the centralized people with the 32 ETH uh organizations uh the big organizations are running more validators which is in a way making Ethereum centralized day by day. So these are the problems that the beam chain is supposed to solve by reducing or the other methods of uh amount for the staking and also making the state trans strain transition function quantum postquantum resilient by using the zk proves or ad approach. The main goal is to use the zk proofs which is the best option we have right now. So we can find the information about be uh about the beam chain and the road map of it in this link.

So this is the beam chain and when it comes to ream ream is a high performance beam consensus client uh that is written in rust. So there are around uh 15 teams that are trying to implement the beam client and uh reim. So right now the beam chain road map is not yet like the even though the road map is finalized the technical specifications the end goals are not yet completely fulfilled. So it's still uh under progress. So according to the road map by the quarter for by the end of this 2025 the year 2025 we should have the technical specs written and uh uh like from the proposal what we have so far the beam chain should be backward compatible with the beacon chain that's what we have right now so it's more like a redesign rather than a uh total new implementation so it should be backward compatible and it should be using most of the current endpoints that we have at the moment which includes the validator management the attestations etc the sync committees and all so I'll be working on the validator endpoints uh and uh possibly the beacon chain endpoints as well on the re client so the specifications of the uh pin chain and other things can be found here and uh I think one of the leads for this meme re client is Colby.

So I'll be taking his help and since it's already implementing the existing parts of the Ethereum consensus right now there shouldn't be any problem apart from the knowledge caps. So these are the like uh at the moment the ream client is focused on implementing the electra hard fork of the ethereum rather than the latest update. So yeah for and for that we can find all the resources here uh that we can use and also since uh consensus layer are a deep knowledge like deep part of the uh like deep subject I'll be using the lighthouse implementation as well for the reference. And uh yeah, these are all the resources where we can find uh more about the current consensus picks. And yeah, that's all from my side about about this project.

Uh hello Uh, yep. Thank you uh for the presentation. Not sure what happened to Mario, but um any questions or comments for that presentation? [Applause]

Yes. All right.

You're back.

Yeah. Thank you, George. Um, yeah. Thank you guys. Um, and uh, yeah.

Okay, I think that was enough. It was all for today. I'm sorry. I just lost last minute. I I lost connection there.

I had to reconnect. Um, so yeah, Jay, thank you so much. Um uh unless there are some more questions or comments or anybody wants to discuss, ask something. Um otherwise we will wrap it up here. Um and we'll have another officeover presentations next week because we have still a couple of people who didn't like it.

Okay. Okay. We're very well. Uh so thank you so much everyone who presented today. It was really great.

Um many great projects out there. I'm excited to see that and uh I'll see you again uh next week for more presentations. Then I'll see you on Monday on the sendup. Yeah.

Bye. Thanks.

Thanks everyone.