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).

Finally it all comes to an end. Considering that I will not be participating in Devconnect, this was my last week being part of the Ethereum Protocol Fellowship. The main focus of this week was on: Preparing my final presentation for the EPF. Solving a bug that came up in the backend simplification. Regarding point (1), there were not many surprises and I focused on telling my progress during these four months, at the same time I mentioned some ideas and pending tasks that arose during this time and in which I would like to continue cooperating. Regarding point (2), the main problem was because I didn't solve the expressions inside the dynamic pushes. Therefore %push(label + 256) did not take into account the "+ 256" of the expression and the results were not correct. Anyway the PR has been updated and this problem should not occur anymore.

During the 14th week of my involvement in the fourth cohort of the Ethereum Protocol Fellowship, my primary focus was on enhancing the way ETK manages different hardforks. Initially, my approach involved adding a flag during the compiler run that would specify the instruction set under which the code should be interpreted. For instance: eas --hardfork london After some testing, I concluded that it would be best to wrap the set of operations of the different hardforks in an enum and adapt the rest of the code to work with this new abstraction layer. However, after discussing the proposal on ETK's GitHub with Sam, we decided to incorporate a new macro mechanism. This macro, for now using the syntax %hardfork(">=london,<cancun"), lets developers specify the exact range of hardforks their code is compatible with. For those writing libraries in ETK, this tool is invaluable: it guarantees that their code is interpreted in the intended context, preventing misinterpretations that might arise if a future hardfork alters the semantics of certain instructions.

During this new week of the Ethereum Protocol Fellowship my overall progress slowed down slightly. There are currently two important fronts I am working on: The most important one is the rewrite of the backend of the ETK compiler that I mentioned before. In this case, I'm still waiting for feedback from Sam who was on holiday last week and seems to have a busy schedule. Additionally, I'm working on refining how ETK processes operations and hardforks. As it stands, ETK interprets operations from a sequence of files that dictate which operations are accessible for each hardfork. However, it only incorporates operations from a chosen hardfork (generally the most recent). My objective is to reconfigure operations so that, by default, the latest hardfork is utilized, but there's flexibility to employ certain earlier hardforks via a command flag. This endeavor demands a deeper knowledge of Rust than the one I currently have, which has led to a slower progression than I initially envisioned. On the bright side, this restructuring will facilitate the easier renaming and deprecation of operations in the future, which is needed to implement some EIPs related to EOF. Progress on this matter can be followed here. In the backdrop, I've been addressing certain challenges tied to the backend's transformation (such as issue 82) and tackling previously deferred features (like issue 106). This week, my aim is to conclude the operations revamp and proceed with my initial proyect of incorporate EOF into ETK.

During the initial half of the twelfth week, I focused intently on refining my recently constructed parser. In my previous development update, I shared that my primary approach aimed to minimize passes over the code while addressing as many modifications as feasible. Even though this strategy successfully passed the tests, it inadvertently reduced code clarity, making the distinct roles within sections of the code ambiguous. Given this, I pivoted towards a process where the parser solely handles the transformation of the current text, delegating the resolution of includes and imports to a separate pass occurring between the parser and the assembler. Not only does this provide a clearer division within the code, but it also offers a platform for potential future optimizations. Admittedly, this shift might impact parser performance slightly. However, given the nature of ETK—an assembly language with a minimalistic feature set—the trade-off appears negligible. Unlike more intricate high-level languages, ETK doesn't deal with complexities like types, inheritance, or other elements that might compel us to adopt more intensive performance measures. Upon completing the adjustments, I submitted the PR for review. It's currently being reviewed by Sam Wilson, one of the project's leading contributors. For those interested in tracking the PR's discussion, proposed changes, and overall progression, you can keep check it here. Wrapping up the week, I dove into ETK's open issues, identifying those that the new version could potentially resolve. Beyond issue 124—the main reason I started this whole rewrite—I found that issue 108 could also be fixed in case my proposal receive the green light.

During the start of the eleventh week, I kept working on the tests for the simplified ETK backend I talked about the previous week. An important update is that, after testing some features in my ERC20 implementation, I found a bug. This bug was in how macros are handled, and it's related to how the original ETK frontend was built. I discussed this with Sam Wilson, a big name in the ETK project. After our talk, he told me it was okay to keep the grammar as it was, but maybe remove some of the other code. After that decision, I used much of the week trying to understand the code better (not just the assembler part) and thinking of how to solve this macro problem. But before I share my idea, it's good to understand that ETK has two special operations to include files: %import(path): It's like taking the code from the given path and putting it directly where you called this operation. %include(path): It's almost the same as %import, but the code you bring in is kept in a different scope and doesn't mix with your main code's positions. Also, in ETK, you can create macros. This lets you use a group of operations many times without writing them again and again. And you can define macros anywhere, even after you've already used them in the code.

During this week I have been concentrating on finalising the details of the simplification of the ETK assembler mentioned in last week's update, as well as the implementation of the ERC20 standard using this new version of the assembler. Unfortunately, due to personal medical problems (nothing serious), the pace of progress has not been what I expected, but I plan to make up for lost time this week, which has just begun. The good news is that the assembler simplification I proposed to replace the current ETK code seems to be working well. The implementation of the ERC20 standard I mentioned last week, with which I am testing some of its features, can be found in this repository. It's been an interesting exercise, I admit, especially as it's served to refresh my knowledge of the various development tools (mainly anvil, casting and forge) that I'm usually far from. My plans for next week are Complete the implementation of the ERC20 standard. Basically the remaining steps are:Modify the code to take advantage of some (still) untested ETK functionality. Add a set of tests to the repository (beyond my tests using anvil). Add the ERC20 implementation to the ETK documentation examples.

This week, my work was mainly focused on finishing the assembler simplification I talked about last week. In the first instance I started working on a fairly basic but not very efficient simplification, which can be seen in PR #132. From the text of the PR itself it reads: This is a WIP of the assembler simplification. The main idea is to drop the use of the pending vector that accumulates bytecodes until the definition of a label is reached. There is still a lot to optimise, but the general idea is as follows: Scan the code to identify labels and macros (surely this can be removed).

As mentioned in my last update, the first two days of this week focused on discussing with Sam Wilson and Lightclient, the modifications needed for the ETK assembler. The current problem occurs mainly during the manipulation of labels, which can be used even before they are defined. Since the ETK backend proceeds in a linear fashion, when it encounters a label that it is not yet able to define (because it is declared later in the code), it enters in "pending" state until the portion of code that defines the label is reached. Let's look at an example to clarify the idea push1 end // <- The assembler enters in 'pending' state // caused by the use of the not yet defined 'end' label. jump

During the seventh week, I continued to focus mainly on the implementation of the various EIPs that make up the EOF specification. After finishing the implementation of EIP-4200, I continued implementing EIP-6206: EOF - JUMPF instruction and EIP-663: Unlimited SWAP and DUP instructions. Both EIPs were implemented without complications. The next step was to implement the EIP-4750: EOF - Functions. However, as I started digging into the ETK codebase, I discovered that features like the ability to rename and deprecate opcodes were not easy to implement and a refactoring of the code was going to be necessary. Since then, I have been in contact with Lightclient and Sam Wilson and we have been discussing possible ways to address this situation. A glimpse from the future, since I am writing this after the week is over: Both parties came to the conclusion that the ideal in this case would be to rewrite and simplify the assembler, so my project to implement the EOF specification will be temporarily paused, but now the project aligns even better with my initial idea of working on the implementation of a compiler from scratch. In other aspects, my PR on the MEMCOPY opcode implementation in Huff has been merged. Link to the merged PR here. For next week I would like to:

During week six, and taking advantage of the fact that the presentation of my project proposal will not be possible at least until next week, I focused mainly on starting with the implementation of the EOF specification in ETK. Mainly, I was working on the implementation of the EIP-4200: EOF - Static relative jumps, which mainly deals with the implementation of the RJUMP, RJUMPI and RJUMPV instructions with a signed immediate encoding the jump destination. The PR with this implementation can be seen here. While the implementation of the EIP was not too complicated (although it still needs to be checked by some ETK maintainer), the main complication arose because, in order to maintain compatibility between all forks, ETK builds the operation set and its functions dynamically using the quote! package. While I think this is an excellent decision, it took me a while to understand the general functioning of this part of the code and to understand that one of these functions was not being generated in this way and brought problems with the new opcodes. On the other hand, the MCOPY implementation in Huff that I had done as a warm-up task couple of weeks ago, was finally reviewed by one of the mantainers, so I hope it can be merged with the rest of the code soonish. For next week I plan: Practice and present my project proposal.

During this week, I was finishing up some of last week's unfinished tasks, while also outlining my project proposal. In a nutshell: I finished defining and submitting my project proposal for the EPF, which can be seen here. I will be working on the implementation of the Ethereum Object Format specification in ETK. The different branches that implement each of the EIPs will appear in this repository. I'm still cooperating with Ipsilon people on the EOF tests for evmone. I have learned a lot, but I still think that my C++ knowledge is not fresh enough and if I wanted to dedicate myself to evmone, this would add an extra weight to my progress (besides, I prefer Rust over C++). I've also been finishing the task I mentioned last week (the implementation of MCOPY in ETK), which has already been merged, marking my first significant contribution to the language :smile: Finally, I have been deepening my knowledge about EOF and ETK and working on the slides to present my project proposal. Once presented at one of the meetings, it will be uploaded and linked here. By next week, I hope: Finish resolving all the coding suggestions from my PR on evmone.

My fourth week of the EPF was mainly about starting to outline the possible scope of my project together with the members of Ipsilon. As a first warm-up task, I implemented a small C++ program inside evmone in order to evaluate the official Ethereum test set (actually a branch updated by Ipsilon) with respect to the EOF implementation. It was an interesting task that helped to refresh my C++ knowledge. The PR with this implementation can be seen here. After that, we talked about the possibility of my EPF project being based on one of the following options: EOF support in Solidity EOF support in Huff EOF support in etk

During the beginning of this week, I tried to coordinate meetings with the Ipsilon team members. As I thought, most of the team was busy or with personal issues. Luckily, I was able to coordinate a meeting in which I was offered to solve a relatively simple task related to evmone. The idea is to implement the necessary code to be able to run the official EOF related tests. This task aims to refresh my "rusty" C++ knowledge and to get to know the evmone codebase, which will probably be the main project on which my own project for the EPF will be based. On the other hand, I'm coordinating to participate in the next weekly meeting of the Fe language development team. My goal is to try to work with them also on EOF related issues, but at compiler level instead of virtual machine level, which would give me an orthogonal view of the issue. Now that things are starting to move faster, my goal is to solve this task quickly so that I can get a better understanding of the subject and submit my project to the EPF in no more than two weeks. Also, I'm interested that these updates start to become more "technical" (which is more fun for me).

During this week I have an exchange with Mario Havel about the possibility, which I mentioned last week, to dedicate the four months of the EPF to work on this idea of a new programming language that I have been thinking about, even before the EPF. We both came to the conclusion that it might be too long and complex for one person and four months of work. Considering this, I decided that the ideal would be to help the Ipsilon team to gain more experience, possibly with the implementation of EOFv1, if there is no rush for it to be part of the next update (I don't want to slow everyone down). At the same time, and since I will probably keep reading and developing ideas about this new language in my free time, we agreed that I could add all the ideas I collect to my development updates. Ipsilon Regarding my idea of helping the Ipsilon team, this week the progress was a little bit slow, mainly because the communication via Discord doesn't seem to be working (not sure if we share the same timezone or if they are too busy with other projects). I will try to communicate again next week, because my lack of progress is starting to worry me. Others

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

Hello, my name is Gaston Zanitti. I've been accepted as an official member of EPF Cohort 4. Here is my week 0 update: Interests In the long run, my main interest is to develop a language for the EVM (or one of its L2 derivatives) or an LLVM-style IR that allows the generalisation of specific optimisations of smart contract languages. As I consider these tasks too big to be solved in 4 months, during the EPF I intend to Gain more experience in compiler development per se. Gain a deeper understanding of the specificities of EVM and gas cost management in terms of language design and optimisations. Better understand the current needs. Do L2s and their lower gas costs open the door to new designs/optimisations? Integrate my work at EPF with my ongoing learning path on compiler design and the EVM