---
# System prepended metadata

title: Week 20

---

# Week 20

This week we did a lot of rebasing and refactoring throughout the entire codebase in preparation for the new set of tests to release.

## My Work
We stopped our interop as as of now since the clients are in a mixed state, some have the required changes concerning coinbase merged and some donot. So we spent most of the week rebasing our branches. I rebased the reth branch and alloy branch. The reth branch had a lot of changes which needed to be added . I added error wrapping and mappings for `BalDatabaseError` for compilation and running the tests.

However after rebasing, the tests were not working, there was absence of BAL in the block. So we both investigated and after a lot of tracing and manual json tests(blockchain tests) running, we figured that it was an error from revm. I looked into the revm implementation and found that it was missing a commit call.
It needed an: 
```rust
state.bal_state.commit()
```

I reported that to Dragan.Meanwhile I made modifications in alloy-evm based on my finding.After each transaction,I added the state change in bal_state in addition to keeping it in `evm.db`.With that we could get access to the bal for each transaction in `bal_builder`. One thing which was missing was recording the changes concerning system calls.Instead of earlier approach of returning an empty Ok(()) on successful modification, I returned the concerning changes. Getting access to `bal_state` inside the core functions like `apply_post_execution_changes` and `apply_blockhashes_contract_call` would require lots of trait expansions which I was unwilling to do atp.Instead I logged the state back to `finish` and `apply_pre_execution_changes` and added to `bal_state`.With this we got the majority passing and expected 4 failures.
This marked somewhat temporary fix from my end which was soon replaced by actually committing to the `bal_state` along with db by Dragan.
## Additional Details Concerning BAL
Nerolation shared some metrics about keeping the `reads` entry in blocks which would improve **3x on worst case** read-heavy-blocks.There was an ambiguity regarding keeping reads in BAL which I believe will be discussed in the next breakout along with `gas_used`. Having gas_used as a part of block access lists would help in scheduling and parallelization,however this stuffs are yet to be discussed. Balancing the pros and cons of having them(believe its a pro) I will add the changes in reth pretty soon.[Po](https://github.com/dajuguan) from ethstorage was looking into our work and added necessary inputs-we needed an additional check concerning database to prevent unexpected failure and a lookup issue in revm. As of now we are running the newly released bal tests(1.4.0).I am holding on adding the metrics related changes,till other stuffs get finalized.I will be making my final update and ppt soon.Also I am working on my rust skills in the meantime :)
## Resources
* [Latest branch for BAL in reth](https://github.com/paradigmxyz/reth/pull/19409)
* [Attempts to run test by evm changes](https://github.com/Rimeeeeee/evm/pull/12/commits/5b72ad3a28c1c5daf4c77bb1ca5d1f369b692fd7)
* [Bal State Change in revm](https://github.com/bluealloy/revm/commit/6847a656ac9158aaf6e5625d7c49ee20646cde04)