# Week 8 This week was a lot things all at once . Rimeeeeee patched the dependencies ( [alloy](https://github.com/Soubhik-10/alloy/tree/bal), [alloy-evm](https://github.com/Rimeeeeee/evm/tree/bal), [revm](https://github.com/Soubhik-10/revm/tree/bal) ) on `reth`, `alloy-evm` .There were a few ci environment issues and we fixed it by defaulting to `ubuntu-latest` . ## Work for the week During this I added the `bal_hash` in the `BlockHeader` which we skipped initially because there were a lot of debate about ssz vs rlp . After that we were ready to start our next big step: Actually building the `BlockAccessList`. We modified the Journal part of revm previously so that all the storage, nonce etc changes will automatically be stored in the `Account` struct of the revm. With that we can just load the account by address and convert the changes into the proposed AccountChange struct of the Eip. The tx execution is very interesting in reth as it uses `alloy-evm` crate wgich is an abstraction layer on top of revm. There is the actual `BlockExecutor` trait defined and implemented for Eth and Op-stack. We added the bal there and after executing the txs we start by populating the bal.There are two options: 1. Populate the bal as we go on executing the tx one by one 2. Use the generated receipts for the block to build bal after all execution. 3. One more wild thing that can be done is to switch up the revm implementation a bit to move the access parts into AccountInfo so that its cached and can be accessed easily from outside. This needs a lot of discussion and perf check so thats kinda off for now. Currently I tested the 2nd option but that creates a lot of trait issues that generate in the revm. So we either need to change revm a bit or go with the first. Rimeeeeee implemented the 1st option after mine in the pr but that needs some other things to consider such as the system calls. Haven't tested that for both the options. However there are a few things that have again changed in the eip. We havent tested for them yet but hopefully they will just be similar to the existing code. We asked for reviews on this and our mentor said that thats the perfect place to build the bal. Still need to figure out which of the 2 options are better and faster . Speaking of mentors, we have [Roman](https://github.com/rkrasiuk) from reth, [Nerolation](https://github.com/nerolation) and [Jochem](https://github.com/jochem-brouwer) in our tg group now :) Nerolation and Jochem are mainly for tracking the progress of client implementation for Bal. Apart from that I watched the ACDE call. It seems BAL is pretty much confirmed and rlp is the go to option. ## Todo - Finish the bal building - Maybe try 3rd option as an alternate approach for perf check - Patch Evm into reth and fix the errors that rises - Test - Try to parallelize the transactions ## Resources [Evm pr (wip)](https://github.com/Rimeeeeee/evm/pull/3) [Bal Hash](https://github.com/Soubhik-10/alloy/pull/6) [BAL Website](https://blockaccesslist.xyz/)