Final Report: PeerDAS in Grandine

Project Abstract

My project on implementing (actually improving) peerDAS in Grandine, basically it is an interesting feature on networking protocol which allow peers to perform data availability sampling to ensure the blobs are available on the network (hence the name PeerDAS), without having to download the whole blobs, just a few chunk each. It was planning to divide the tasks among 3 fellows, which I’m one of them, others are working on back porting eth2_libp2p from Lighthouse, and continue implementing rust-kzg for peerDAS (not inside the scope of the project, but also a part of peerDAS as well), which I can’t give a update for them, since they were already disappeared, leaving me to handle some of their tasks, but the main functionality of this feature has already been implemented by the team, we just make sure to keep up to date with other clients implement, and finishing some remaining tasks from the team, those are the main goals, others are just nice to have :)

Current Status

The implementation is now not 100% bugs free, but at least I have done some works to make it ready for the previous devnet (peerDAS-devnet-3), even though there was a crazy reorg on Prysm after a long long time of lost finality and participation rate, still not sure what is actually the root cause of the reorg since core devs didn’t have time to debug on the issues yet. After the event, I have identified, also got reported from other client devs - on some of the issues related to synchronization, particularly on the req/res of block and data column side cars by range. I also try to keep up with the spec changes over this last few weeks, the main changes for the upcoming devnet is rebase peerDAS onto Electra, which already been implemented, and resolved some of the conflicts as well.

Based on the roadmap that I set early in the program, it is almost finished, I just need to continue improving it later on. I can't give yes/no on whether the project is finish or not, but I can say it is 80% done compare to an up-to-date client implementation. Regarding the usability, you can try to interop with other clients by activating eip7594_fork_epoch in the kurtosis config, you also can try the rebase after electra as well with a few client with this config, but I have identified an issue on missing blobs proposed by grandine, because I have not implement engine_getBlobsV1 engine API which get blobs from local EL, need to work on this after Devcon end.

Future of the project

I would really like to continue maintaining this project and working on PeerDAS in Grandine til the finish line, but I have to hand over to the team for a review, hopefully there will not gonna be much complain from them :).

As I said earlier, I still need to implement the engine API to keep up with the merged specs for the next devnet, and the specs still involving for peerDAS, there is no end goal for Ethereum, and will be a bunch of improvements along the way. Of course, there are still several bugs to be fixed, which require to debug further, maybe I have to learn how to debug efficiently as well.

After all done, Its performance should be improved as well. For example, switching from c-kzg binding to grandine own kzg implementation for peerDAS is a main thing to boost the performance, since we don't have to convert back and forth between Grandine's types and types in the binding, which would have a better performance outcome. but it has to be done on the other side first before switching. then, I will clean up the implementation, remove unnecessary logs for further improvement, and a clean codebase.

My Experience in EPF

One of the most interesting and challenging part of implementing on this project was trying to get a sense of DAS concept, mainly peerDAS, and getting myself familiar with the codebase, and other clients implementation as well, since whenever I faced some potential wrong behaviour, I have to look into other clients code as well, to see how they handle the thing, what is the correct behaviour we should expect of, and doing that is not quite fun, I have to understand those client codebase and structure, where to looking for specific functions and handlers, but that is the way of clients diversity, and interop should be, logically centralized. I almost think of dropping out a few times, but I always look back to what I have done so far, it keeps me motivated and pushes me to move on til the end of the program.

It was a great journey for me, starting as a permissionless participant, then later was selected for the cohort after reevaluation on the progress. It is a great opportunity for the public to get to know better about the core protocol and its development between different clients. Although, I should be more active and joining the weekly update calls and office hours, but due to the timezone different (it is 10pm at night), I couldn't make it in the last several weeks. It would disturb my relative if I speak up for the update, so I would choose to post the update in weekly update threads instead.

Last but not least, Thanks to Saulius for giving advices, on-going discussion and supports over these 5 months, I couldn't made this far without your helpful suggestions.

Thanks to Josh and Mario for this wonderful opportunity and organizing this program which allow more contributors into the core protocol. I just enjoyed reflecting back over the course of the program.

Have a nice day, reader!