Introduction

The goal of the project was the creation of a prototype that incorporates zero-knowledge proofs in the codebase of Ream client. In collaboration with Utsav under Unnawut’s guidance we worked on 2 subprojects. Both of them were about proof generation and validation of a state transition function (STF) with the difference that the first subproject used the beacon chain while the second one the lean chain. Here is the link to the project proposal elaborating on the technical issues.

Status report about the final state of the project, overview of the roadmap

The second part of the project was added in mid September due to the advancements in devnet0 and devnet1 of the lean chain. It made much more sense to work on something that will be used by the team in the future after getting some experience on the beacon chain. As a result we currently have a project that achieved the milestones set during the fellowship but still has a lot of future work remaining. In particular,

Proving STF on the beacon chain

Currently, proof generation is feasible although time consuming. Using OpenVM, it took around 10 hours to prove the execution of the test attestation_invalid_correct_attestation_included_after_max_inclusion_slot found in https://github.com/ethereum/consensus-spec-tests/releases/. Utsav has created a common framework that combines 5 zkVMs: SP1, RiscZero, Zisk, Pico, Jolt. I don’t think that there is much left to do on this part of the project apart from including OpenVM to Utsav’s codebase. Currently, it is quite tedious to optimize proof generation. Since beacon chain is not part of Ream’s roadmap there is no reason to invest further resources on this, we’ve already reached many useful conclusions, it’s time to move on!

Proving STF on the lean chain

Proof generation is working, our verification logic is set up but currently cannot be tested due to an issue in setting up a p2p network. There is a draft PR in Ream’s client specifying the plan for this project. Our implementation adds proving as a new optional feature. For this, we introduced a new service LeanProverService that handles the proving logic. We hope that this design decision facilitates the review of our PR and provides modularity to the client.

Future work

  1. Setup 4 nodes with one validator each, so that p2p network runs properly and executes proof validation. In principle, the validation logic is the same as in the beacon chain project so we are not expecting any issues. Nevertheless we have to implement it.

  2. Abstract the function calling RiscZero to use any of the 6 zkVMs that we have already implemented in the first part of the fellowship. In the case of beacon chain, the framework that combines the zkVMs has been set up by Utsav here. We should either recycle it or consider other option such as ere framework. For ere in Ream, Jun has created a prototype.

  3. Go through a PR review (already counting one refactor)

In a more general context, we could also think about optimisation. For example, Grandine team implemented precompiles that cut down on proving times. In general, optimisation is a complicated topic. For example, OpenVM breaks the proof into segments allowing for parallelization. The tradeoff with this type of optimization is memory usage which will increase by 2x, 3x, 4x, etc. It is not clear to me how we could proceed with optimisations in a framework that incorporates 6 zkVMs. Going through the implementation details of each zkVM manually is too much work. Additionally, even minor version updates in zkVMs include major revisions in implementation, features and optimizations. As a result, a naive implementation of a framework would go obsolete in a few months at best.

Current impact and future of the project

The project was a followup to the work of Unnawut on SP1 and RiscZero on the beacon chain. It was set to explore Ream’s compatibility with zkVMs and possible bottlenecks. The progress of lean specs enabled us to progress even further. I think that the initial goal was achieved. Based on the lean chain roadmap zk proving will be required, therefore some form of this project will be merged to the client. My guess is that our expertise will become more relevant as time passes, I hope to be available and able to contribute to these efforts.

Self-evaluation, general feedback about your project and activity within EPF

I had very limited experience with a scientific project written in Python that is related to the topic of my PhD but no experience with Rust, zero-knowledge proofs, scripting needed to set docker images, local networks, proving and validating. My goal was to make a decent contribution while learning since I had limited amount of time and many topics to cover. I think that we managed to get some interesting metrics that will be useful to Ream. Even though I didn’t manage to cover all I wanted to learn, I’ve got a clear picture on what I have to understand and the resources to do it. I am satisfied with the result. If I were to do it again, I would request for help/ask questions sooner, that would save me some time.

Feedback about EPF, your takeaways from the program, both the positive and negative

THANK YOU MARIO AND JOSH!!!

It is hard to provide suggestions for EPF due to the variety of profiles and prior experience of each fellow. The current format provides a lot of free time that the fellow can use to its best interest. I think that this should be preserved. A general observation that is probably too complicated to implement and beyond the scope of the program is the structure of resources. Usually, books and other resources progress in sequential manner, building up on previous chapters/paragraphs. This is not, how we usually think when writing code. First we try to understand the feature by going through resources such as specs. If there is something unclear, we keep thinking or searching for more resources and once we are satisfied, we move to the next unkown. Once everything is clear, we stop the iteration and return to the initial feature which should then be fully understood. I believe that epf.wiki and other resources should have this structure as well. Various concepts should be clearly defined once and referred everywhere else with the use of hyperlinks. This way text will allow the reader to choose how to allocate reading time instead of imposing a certain structure that requires increasing amount of time to reach later chapters. The paradigm that I have in mind is ArchWiki that impressed me with its clarity. It also avoids fragmentation by collecting all the material in a single website.

Of course, the suggestions above are up to us, the fellows, to implement and not Mario and Josh but it was the closest that I had to some form of feedback.