Most of the week was devoted on the project proposal for which I am waiting for a second review.

I also learned the proper way to create pull requests in git and a few things about the ere framework that provides a modular interface to all the zkVMs that we are currently working on: risc0, sp1, openVM, jolt.

Git and pull requests

The following are trivial for everyone but new to me. I learned the following from Mario’s notes. I have been syncing from remotes using git pull that fetches the remote and merges it to the local branch creating a merge commit. This results in a messy commit history. Instead use git fetch to fetch the remote and then git rebase to rewrite the commit history removing temporarily local commits, writing the remote commits and finally adding the local commits that were removed on top. If merge conflicts arise, they must be resolved and then continue the rebase by git rebase --continue. Finally, if needed, git rebase --abort stops the rebase and returns to the commit before initialising git rebase.

A pull request is done by creating a personal copy of the remote repository. This can be done easily using the tools provided by the website. Then, create a local branch that includes all the changes to be included in the pull request. Push this local branch to the personal copy of the remote. Finally, use the website’s tools to create a pull request of the brach in the personal copy of the remote to the remote reposity of the project.

Ere framework

I looked briefly in the ere framework. The examples presented involve only the fibonacci sequence as guest program and there is a warning about breaking changes. I cannot estimate how much more time it will take us to implement all our tests in this framework but my mentor Unnawut considers that the modularity of the framework will be useful later on when beam chain specs become available. At that time zk proofs will be necessary for the consensus client.

Next week

I will try to build a simplified example with openVM and explore further ere.