---
# System prepended metadata

title: 'EPF: Cohort 4 - Week 6'
tags: [Compilers, MCOPY, EOFv1, Huff, Ethereum Protocol Fellowship, Week6, ETK, EPF, Ethereum]

---

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](https://eips.ethereum.org/EIPS/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](https://github.com/quilt/etk/pull/128). 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](https://docs.rs/quote/latest/quote/). 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](https://github.com/huff-language/huff-rs/pull/289) 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.
- Move forward with the implementation of EOF in ETK:

Regarding this last point, there are two main objectives:

[EIP-3540](https://eips.ethereum.org/EIPS/eip-3540): Since ETK is an assembly language, I have some doubts about the EOF implementation, which I will try to solve with [@lightclient](https://github.com/lightclient). Mainly regarding how much we should meddle in the header implementation and the different sections of code and data. While I think we should leave everything to the user (as I said before, ETK is an assembly language), I think it's interesting to offer some features that can make life easier for the user who just wants to create a PoC and doesn't want to have to read the whole specification. I think it is a feature that could help the mass adoption of ETK, a task to which I am more and more committed every day.

[EIP-4750](https://eips.ethereum.org/EIPS/eip-4750): This EIP implements new opcodes that are related to my comments regarding the EIP-3540, but in addition, it deprecates dynamic jumps. Based on my experience implementing EIP-4200, it may not just be a matter of adding new opcodes, and part of the ETK codebase may need to be rewritten to take this into account. 
