# Week 12 & 13
This weeks we focused on fixing the tests for eip-7928 implementation in reth,refactoring and cleaning up our existing work.
## Results based on running eest
We ran the **consume-rlp** and **consume-engine** tests, the initial output we got was that the tests pass for the valid cases but fails if the BAL passed was invalid.Our initial approach was validating the BAL during validation through consensus if the amsterdam fork was active,by calculating hash for the BAL passed in block body and matching it with the header **bal_hash**. We lacked validation on certain other parts and presence check.

Leaving that we also fixed our implementation by passing the **bal_hash for genesis**,with the changes we made, we reached a good number of **14/15 pass cases**.

The test which actually took a toll was **test bal storage_writes**,we checked our initial implementation in revm which looked alright.Earlier we added a bunch of tests for the same there but the problem seemed to be somewhere else.We added tracing in evm,revm and alloy.From what we found it was having different addresses concerning AccountChanges. My doubt was our work in evm, as we handled the reciever for transaction generically without matching **tx.kind()**.
So some attempt from my part was:

 match tx.tx().kind() {
                alloy_primitives::TxKind::Create => {
                    if let Some(created_address) = result.created_address() {
                        if let Some(acc) = state.get(&created_address) {
                            if let Some(bal) = self.block_access_list.as_mut() {
                                bal.push(crate::eth::utils::from_account_with_tx_index(
                                    created_address,
                                    self.receipts.len() as u64,
                                    acc,
                                ));
                                tracing::debug!(
                                "BlockAccessList: new contract created at {:#x}, tx_index={}, storage: {:#?}",
                                created_address,
                                self.receipts.len(),
                                acc.storage_access,
                            );
                                state.get_mut(&created_address).unwrap().clear_state_changes();
                            }
                        }
                    }
                }
                alloy_primitives::TxKind::Call(address) => {
                    if let Some(acc) = state.get(&address) {
                        if let Some(bal) = self.block_access_list.as_mut() {
                            bal.push(crate::eth::utils::from_account_with_tx_index(
                                address,
                                self.receipts.len() as u64,
                                acc,
                            ));
                            tracing::debug!(
                                "BlockAccessList: Tx call arm {:#x}, tx_index={}, storage: {:#?}",
                                address,
                                self.receipts.len(),
                                acc.storage_access,
                            );
                            state.get_mut(&address).unwrap().clear_state_changes();
                        }
                    }
                }
            }

But this did not fix the problem,we ended up getting the same output :(

Meanwhile my friend analysed the traces from reth and worked on locally rlp encoding the BAL we got and decoding the expected bal_hash.Turned out it was **StorageValue**, we used it directly from alloy-primitives so we actually used **U256** for post storage writes while the expected type as per eip is **B256**.After this tiny fix we got the happy **15/15 passes**.

## Pre-execution changes fixes
I followed the discord for eip-7928, geth pointed out correctly that the present set of eest for eip-7928 was not recording the pre execution changes. While [fselmo](https://github.com/fselmo) and [nerolation](https://github.com/nerolation) made the changes with a new release,we found our implementation lacked this too.We were recording the changes for eip-2935 and eip-4788 directly into storage_writes,but our set of results failed to match the expected ones.**nerolation** pointed out that we actually cannot be specifiying changes concerning storage_writes directly,it is totally dependent on how slots are altered so it might be a read or a write. So we actually recorded the pre system call and then match it with post,with that it was also done.

## Refactoring and cleaning up
We merged the latest main and feature-gated our work,with that done I moved the core tracking structures from AccountInfo to Account in revm.With all the changes we made there the overall performance improved a lot.A bit of redundant passing we made in evm during implementation,like passing block number and timestamp for recording changes in system calls which I cleaned up.

## Summary
Apart from this we attended the breakout,where I shared the status of our work,got to know the alot of new stuffs. So it was two busy weeks,where we did all the necessary works for eip-7928.Happily overwhelmed by the everyone's support :)

## Works
* [Tracking issue for BAL](https://github.com/paradigmxyz/reth/issues/18253)
* [BAL in reth](https://github.com/Rimeeeeee/reth/tree/bal)
* [BAL in evm](https://github.com/Rimeeeeee/evm)
* [BAL in revm](https://github.com/Soubhik-10/revm/tree/bal)
* [BAL in alloy](https://github.com/Soubhik-10/alloy/tree/bal)