# Week 8
This was a busy week - we finally started on the **building** part of Block-level Access List.

## Eip-7928 Implementation Update

I spend a bit of time of the week by patching 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) ) and fixing the errors along with Soubhik. We then studied how reth actually executes the transactions.

They donot use revm directly,there is a wrapper crate of revm called alloy-evm that has a trait called **BlockExecutor**. There they execute the transactions and store the results in **BlockExecutionOutcome**.

It took a lot of time to design what's the implementation will look like. But because of our weeks of hardwork of modifying revm, it seems that building the bal won't be such a problem. The idea is with every execution of the transaction, all the necessary info will automatically get stored with the id directly in the **opcode level** due to the modification of the **Journal**.We already showed this approach to **Matt** and **Dragan** and they said that this is right now the most optimized way of storing the accesses.

I started with adding a helper function that will convert the **revm account** struct into the proposed **account change** of bal. The structs cannot be the same as the eip because there are a lot of revert conditions to be implemented and for that we would need extra stuffs that Block-level Access List does not covers (for example the prev value before write is not needed for bal but needed to revert the txn).

This is the initial fxn :

pub fn from_account(address: Address, account: Account) -> AccountChanges {
    let mut account_changes = AccountChanges::default();

    for (_tx_index, read_keys) in &account.storage_access.reads {
        for key in read_keys {
            account_changes.storage_reads.push((*key).into());
        }
    }

    // Group writes by slot
    let mut slot_map: BTreeMap<StorageKey, Vec<StorageChange>> = BTreeMap::new();

    for (tx_index, writes_map) in &account.storage_access.writes {
        for (slot, (_pre, post)) in writes_map {
            slot_map
                .entry(*slot)
                .or_default()
                .push(StorageChange { tx_index: *tx_index, new_value: *post });
        }
    }

    // Convert slot_map into SlotChanges and push into account_changes
    for (slot, changes) in slot_map {
        account_changes.storage_changes.push(SlotChanges { slot: slot.into(), changes });
    }
    for (tx_index, (_pre_balance, post_balance)) in &account.balance_change.change {
        account_changes
            .balance_changes
            .push(BalanceChange { tx_index: *tx_index, post_balance: *post_balance });
    }

    for (tx_index, (_pre_nonce, post_nonce)) in &account.nonce_change.change {
        account_changes
            .nonce_changes
            .push(NonceChange { tx_index: *tx_index, new_nonce: *post_nonce });
    }

    for (tx_index, code) in &account.code_change.change {
        account_changes
            .code_changes
            .push(CodeChange { tx_index: *tx_index, new_code: code.clone() });
    }

    account_changes.address = address;
    account_changes
}

For the actual storing part, we tried a couple of approaches, mainly **populating from reciept**, or **using txn sender,recipient**. Reciept one has some trait issue but will have this week to complete the actual implementation. Meanwhile we discussed our approach to our mentors. [Roman](https://github.com/rkrasiuk) from reth, [Nerolation](https://github.com/nerolation) and [Jochem](https://github.com/jochem-brouwer) also joined our tg group !

## TODO

- Complete building the bal.
- Test (the tricky part since its a struggle to run a node in our laptops,even if it's testnet).
- As per the eip, parallel execution is not a mandatory part to complete for bal however we would like to do it.

## Additional Work
Also started working **OpFlashBlock support** issue in reth. Previously I had made the changes in alloy concerning it. So really excited to see how everything turns out!

## Resources
* [BAL utility function](https://github.com/Rimeeeeee/evm/pull/3)
* [Eip7928 patches](https://github.com/Rimeeeeee/reth/pull/11)
* [Refactor for BAL](https://github.com/Rimeeeeee/evm/pull/2)
* [Native Op Flashblocks support](https://github.com/paradigmxyz/reth/issues/17858)