# Week 5 As suggested by our mentor [@mattsse](https://github.com/mattsse) we started looking for ways to implement the functionality to track the storage changes directly in the [revm](https://github.com/bluealloy/revm) as it would be much faster than just inspecting the transactions. So we spent quite a few days just studying the revm architechture. ## Implementation Details: We decided to just create a few fns and call them when SSTORE and SLOAD are called. We created a structure that stores reads and write in `Account`. I implemented the basic functions and their calling. However our biggest challenge was performance.The revm is extremely efficient and introducing more fn calls will increase overhead. I made the pr here and [Rimeeeeee](https://github.com/Rimeeeeee) tested that against the edge cases. She found one bug that kept the writes even if the transaction reverts. She fixed that. Right now we need a review for our approach so we can proceed to the next step. We also tested two types of implementation and found that one is about 4% faster. We went with that. It was faster as it was doing one less read in the BTreeMap. The main difference between the approaches are how we were handling the read write overlap edgecase. In case of an overwrite we were storing one extra read and removing it later. We modified the sload fn to conditionally store reads. This was faster as expected. ## Additional works Along with that I finished up the JSTracer Pr in foundry. I also added the blob endpoints to alloy. # Resources * [Storage Change PR in revm (current approach)](https://github.com/Soubhik-10/revm/pull/1) * [Slightly worse approach](https://github.com/Soubhik-10/revm/pull/3) * [JSTracer support in anvil](https://github.com/foundry-rs/foundry/pull/11052) * [Alloy blob endpoints ](https://github.com/alloy-rs/alloy/pull/2731)