Update from week 0

During Week 0, and after a short exchange with the Ipsilon team, they proposed me to work on the implementation of the MCOPY opcode (EIP-5656) in Huff, which should not take too much time. While kind of trivial, this was actually a really good first task to familiarise myself with the codebase, etc. The PR of this implementation can be seen here.

We had also talked about the possibility of working on EOF related tools in Solidity and Huff. To that end, I also read the EIPs that make up the EOFv1 unified specification to get a better understanding of the proposed changes. This unified specification is used as a guide to understand the various changes the EVM Object Format is proposing:

• 📃 EIP-3540: EOF - EVM Object Format v1
• 📃 EIP-3670: EOF - Code Validation
• 📃 EIP-4200: EOF - Static relative jumps
• 📃 EIP-4750: EOF - Functions
• 📃 EIP-5450: EOF - Stack Validation
• 📃 EIP-6206: EOF - JUMPF instruction

This series of changes involves not only separating the code from the data, but also adding new opcodes for static jumps, and deprecating the opcodes for dynamic jumps, removing validations that are now unnecessary before each execution.

Of course, these modifications involve a lot of work at the compiler level, so it could turn out to be an interesting project. I intend to contact other teams to see where each project stands on this topic.

Week 1

Flint

During week 1, I decided to investigate different implementations of programming languages for the EVM. My main idea is to try to find out more about the different strategies that are used by the different programming languages. Since my main focus is to try to provide more security guarantees, a language developed as a thesis at Imperial College in London called Flint caught my attention.

After reading the main paper, I have the feeling that some ideas, such as protection blocks, can definitely be useful in an "industrial-strength" programming language (which Flint does not seem to be).

I also chose to contact the project's director, Dr Susan Eisenbach. Unfortunately, although she seemed confident about the future of languages for the EVM, she told me that she was about to retire and that the project had stalled. Anyway, I also read the thesis that led to Flint's development.

Reading about Flint renewed my desire to create a language for the EVM with a strong emphasis on security. The emergence of L2 solutions and the resulting reduction in gas costs could potentially allow for the application of various constraints, not only at compile time but also at runtime, which could enhance the user's experience in terms of their code's security.

Vyper & Fe

After contacting the Fe & Vyper team via Discord, I found out that none of them can answer if they are under the scope of the EPF. However, there are a variety of projects to collaborate on.

In Fe, for example, no one is working on adapting the compiler to comply with EIP-3540 (EOFv1), and I think it could be an interesting collaboration. Even if we cannot find a project that fits the requirements of the EPF, we agree to have a meeting next week with one of the contributors, to start collaborating with them anyway.

Conclusions

This opens up two (and a half) possible ways forward:
On the one hand, I could take the idea of developing a programming language specially designed for the EVM, with a focus on security (along the lines of Flint). While I still think that this is too big a task to accomplish during the EPF, part of me thinks that if I get good results during the fellowship, there might be a chance to apply for a grant after the EPF, and thus be able to continue with its development.

As a compromise mid-point, I could focus on investigating the needs of the EVM programming languages and their users and develop compiler-level solutions (without necessarily implementing them at this stage).

Finally, the option that seems most viable is to continue working with the different compiler teams, solving some simple tasks and then focus on implementing EOFv1 in some of them.