# POC for Code Chunk Tracking - Development Update #1

2021/06/30

Аt one of the recent **state-expiry** [call meetings](https://consensysmesh.zoom.us/rec/play/VoftjeRO0xNFHObLZpot-r0hTj0U6ZG0fUKORwQzy2qoh-JlweRgL6hj5UxqC8WsdYW3IOVBc6l_912R.ND8fJB672c-EpG1T?_x_zm_rhtaid=872&_x_zm_rtaid=Jhbf_Q6fTx-tPJB7vFllMg.1623863913448.e6b0045131eec8ea5666c579c3b613b7&autoplay=true&continueMode=true&startTime=1623848674000), a new [verkle tree EIP](https://notes.ethereum.org/@vbuterin/verkle_tree_eip) was presented by Vitalik. One of his suggestions (around the 21-min mark in the video) is to verify that tracking code chunk access is trivial and does not include any hidden complexities. An issue about this was opened in [Core Developer Apprenticeship Program repo](https://github.com/ethereum-cdap/cohort-zero/issues/62) by Piper Merriam.

This is the first development update. I'm still trying to put a lot of the pieces together. I'm in the process of defining clear goals for this project and setting real expectations. I assume ideas and directions will change fast as my understanding improves and of course feel free to add any comments or suggestions, any help is appreciated!

## The goal

The goals of this project as I currently understand it (feel free to correct me if I'm wrong) is to modify an existing EVM implementation to track multiple code chunks and execute opcode instructions instead of using as input just one big chunk of code. This proof of concept will serve is a way to check if there are any implementation pitfalls.

## Different paths ahead

There are probably few ways we can accomplish this. One way is to modify an existing client code by implementing the new verkle architecture plus EVM modification to consume the code verkleization. We have specifications for [verkle tree](https://notes.ethereum.org/@vbuterin/verkle_tree_eip
) integration and defined state expiry [roadmap proposal](https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal
). On the implementation side, it looks like the geth team is working on a verkle tree
[POC integration](https://github.com/ethereum/go-ethereum/pull/22999), but this ticket is kinda blocked by [this](https://github.com/gballet/go-verkle/pull/59) `go-verkle` PR.
However, It seems that code verkleization is still not supported, and I'm not sure if any of client teams is working on it at the moment. The closest I've come to this is [code merkleization](https://github.com/s1na/go-ethereum/tree/code-merkleization-ssz-stats) implementation in `go-ethereum`.

My feel is that if we take this route, it will add a lot of overhead on the project,
and most likely will involve a lot of coordination and collaboration with the geth team because we will have to integrate code verkleization in the client.

## A simple way

I believe, we should try to explore a more feasible way to accomplish the goals above.
One of the directions I'm currently investigating is if using the standalone EVM
[implementation in Python](https://github.com/ethereum/py-evm) makes sense.
If we can somehow mock the input data as chunks of code, probably it will be easier to modify `py-evm` instead of trying to implement code verkleization in a client. I still need to investigate the different transaction tracing APIs and find out how exactly they work. Do we have to implement a verkle tree and code verkleization in python? Should we use transaction tracing APIs? Is there a better way?

If you would like to help out, you can join the conversation on the **#apprenticeship-program** channel on Eth R&D Discord, or join our weekly calls.