# Week 9
This week was significant in terms of development. Successfully constructed the earliest *BAL* in [alloy/evm](https://github.com/Rimeeeeee/evm).
## Checkpoints:
### New rlp structure
The new eip marked a major shift from using **ssz** to **rlp** .Additionally, the pre_execution system contract index was moved 0. This is responsible to store changes concerning **eip-2935** and **eip-4788**.The post was at transactions.len()+1,storing changes concerning to **eip-7002** and **eip-7251** .I made changes to the core structures present in alloy as per the new convention.(e.g bal_hash->block_access_list_hash etc)
### Recording pre and post execution changes
We initially had some struggle concerning getting access to the **Account** of revm in alloy/evm. The **CacheAccount** enabled access to AccountInfo without trait extension. So it could be either using `db_mut().database().basic()` to get access to it or using `db_mut().database().load_cache_account()`.The change was undertaken by Soubhik.

After that the major work was recording pre-execution changes.The previous version of eip has a solid foundation upon how to tackle this. I had some initial doubt regarding the `HISTORY_STORAGE_ADDRESS`(which was present as a ecrecover precompile/dummy address in example section of eip).Upon sharing it with the writer,he fixed it. Thanks to [@nerolation](https://github.com/nerolation):)

For the implementation,I was responsible for keeping the changes concerning eip-2935.We previously lacked helper fxns like `with_address()`and `with_slot()`which would allow us to add the required part of change along with `AccountChanges::default()` .So finally it was something like:

 let slot_change = SlotChanges::default()
                .with_change(StorageChange {
                    block_access_index: 0,
                    new_value: parent_block_hash.into(),
                })
                .with_slot(U256::from((block_num - 1) % HISTORY_SERVE_WINDOW as u64).into());
        
        let acc_changes = AccountChanges::default()
            .with_storage_change(slot_change)
            .with_address(HISTORY_STORAGE_ADDRESS);

For the post execution, the key point was predetermined slots. For both the eips(eip-7002 and eip-7251),the system contract storage diffs from slot 0-3 are needed to be recored in `StorageChange`.This proved to be quite simple.

Also we noticed that we donot need access to the `state` in the post-execution directly,so the concept of `CacheAccount`(not really suitable tbh) was replaced with `Account`.

### Sorting and removing duplication
One of the key aspect of eip 7928 was having a lexicographically sorted list of `AccountChanges` in bal. Along with that the problem we feared is duplication. Since we were storing the changes across all 3 core functions dealing with **pre-execution**,**execution of txns** and **post-execution**, it was a possibility that we have redundant `AccountChanges` entry concerning addresses.We feared that we might have same addresses in txn execution and post_block_balance_increments. So after finally building the bal,I created a simple `sort_and_remove_duplicates_in_bal` to tackle it before it finally moves to `BlockExecutionResult`.

### Getting the essence of Block-level Access List
After patching the new modification of alloy/evm to reth,I enabled bal building through `assemble_block` and finally constructed the `block_access_list_hash` as `keccak256(rlp.encode(actual_bal))`.

After adding a simple test,we got the result like:

{
  "block_access_list": {
    "account_changes": [
      {
        "address": "0x0000000000000000000000000000000000000000",
        "storage_changes": [],
        "storage_reads": [],
        "balance_changes": [
          {
            "block_access_index": 3,
            "post_balance": "5000000000000000000"
          }
        ],
        "nonce_changes": [],
        "code_changes": []
      },
      {
        "address": "0x000000000000000000000000000000000000beef",
        "storage_changes": [],
        "storage_reads": [],
        "balance_changes": [
          {
            "block_access_index": 0,
            "post_balance": "49999899999979000"
          },
          {
            "block_access_index": 0,
            "post_balance": "49999799999958000"
          }
        ],
        "nonce_changes": [
          {
            "block_access_index": 0,
            "new_nonce": 1
   },
          {
            "block_access_index": 0,
            "new_nonce": 2
          }
        ],
        "code_changes": []
      },
      {
        "address": "0x000000000000000000000000000000000000dead",
        "storage_changes": [],
        "storage_reads": [],
        "balance_changes": [
          {
            "block_access_index": 0,
            "post_balance": "150000100000000000"
          },
          {
            "block_access_index": 0,
            "post_balance": "150000200000000000"
          }
        ],
        "nonce_changes": [],
        "code_changes": []
}
}

## TODO:
* Adding actual tests to verify the block-level access list.
* Preparing reth in terms of bal building and generation.
* Refactoring and optimization.

*P.S. : There were no additional fun works this week.But looking at the output it was worthwhile!!!*

## Resources
[New revm approach](https://github.com/Soubhik-10/revm/pull/17)
[Alloy Evm build bal](https://github.com/Rimeeeeee/evm/pull/3)
[RLP Changes](https://github.com/Soubhik-10/alloy/pull/7)
[Eip-7002](https://eips.ethereum.org/EIPS/eip-7002)
[Eip-7251](https://eips.ethereum.org/EIPS/eip-7251)