The fourth cohort of the Ethereum Protocol Fellowship (EPF) has concluded, and I am excited to share my experiences and learnings. In this post I will make a summary of my experience during the EPF largely influenced by the overview I presented in my final presentation [Slides here].

Initially, it's important to mention that my primary interests lie in compilers and virtual machines. With this in mind, after confirming my participation in the EPF, my first step was to review the list of projects proposed by various core teams.

This led me to connect with the team at Ipsilon, who were, at that time, the only ones considering work on virtual machines or compilers. After some discussions, I began working on several warm-up tasks, among which the most notable were:

• Implementing MCOPY in Huff
• Implementing MCOPY in ETK
• Developing a program to test the implementation of the EOF specification inside evmone (a task that introduced me to the concept of EOF, which became a significant element in my final project).

Simultaneously, driven by my interest in creating a programming language for the EVM, I delved into research on potential features for such a language and spent time exploring some "experimental" languages like Obsidian and Flint.

I soon realized that my options during the EPF were twofold:

• I could delve deeper into research and embark on developing a proof of concept for a programming language.
• Or, I could work on a pre-existing compiler to enhance my overall understanding of EVM.

After discussing with Mario Havel, I concluded that developing a programming language from scratch would be too ambitious for the EPF's four-month timeframe and would be challenging to find a mentor with sufficient context to assist me without impacting their own tasks.

Thus, I opted to focus on an existing compiler, specifically ETK. I was drawn to ETK due to its lower market share, which I believed would offer more freedom to explore and more challenging problems to solve. Additionally, ETK's foundation in Rust was a plus, given my interest in the language.

I quickly began addressing various Ethereum Improvement Proposals (EIPs) that form the ETK specification, like EIP-663, EIP-4200, EIP-6206, etc. However, I faced a significant challenge when attempting to implement the "EIP-4750"

This challenge stemmed from ETK's inability to manage different fork versions efficiently. With the existing codebase, it was necessary to edit all imports and recompile to target a new hardfork, which caused issues if the new hardfork required renaming some opcode. In some cases, like with EIP-4750, it even required rethinking a large part of ETK's test suite.

Therefore, I reached out to Sam Wilson and Lightclient, two of ETK's main contributors, to discuss my idea of implementing a "hardfork selection" feature. While they both supported my idea, they separately concluded that it was essential to rewrite and simplify the ETK backend firrst. This led to my first major task during the EPF: the simplification of ETK's backend.

The primary challenge with the older version of the ETK backend revolved around its management of dynamic operations. To give some context, some of the ETK's operations are designed to determine their bytecode size during compile time. However, the way these dynamic operations, such as macros or labels, were implemented led to a significant issue. Each time the compiler came across such an operation, it would add the bytecode to a "pending state." The complication arose when the system needed to initiate a new pending state before closing the previous one. This sequential dependency meant that if a new operation requiring a fresh pending state was encountered before the earlier one was resolved, it would trigger an error. This inability to simultaneously manage multiple pending states effectively led the compiler into a state of panic, as it could not process overlapping or nested dynamic operations without resolution of the preceding ones.

My efforts were then focused on planning and implementing this backend simplification, currently under review by Sam Wilson[Link here]. The next step involves implementing the "hardfork selection" feature, pending the integration of the backend simplification.

In addition to these specific tasks, I actively participated in general issue resolution for ETK, addressing Issues #82, #108, and #124, and implementing features like Issue #106. There's also a proposal to create an ETK website featuring a playground, which I plan to contribute to in the future.

Finally, I would like to say that I'm immensely grateful to the Ethereum Foundation and the Ethereum Protocol Fellowship for this invaluable opportunity. It has been a transformative experience that I would highly recommend to anyone interested in making a mark in the Ethereum community.

I look forward to making further contributions to the Ethereum ecosystem in the future!