# BAL brain dump
- Block builder must include all storage slots individual txs will access
- This is consensus critical, so mismatching BAL lists will fail block validation
- ExecutionPayloadV4 adds a blockAccessList field thats a RLP encoded BAL (So engine API gets a bump)
- The builder has 2 phases: Collection phase and Build phase. Collection just records all touched state accesses. Build phase is encoding this info in RLP for consumption.
- BALs should include the following:
- Address wtih any state changes (storage, balance, nonce or code)
- Addresses accessed without state changes:
- targets of balance/extcodesize/extcodecopy/extcodehash opcode
- targets of call, callcode, delegatecall, staticcall
- target of create/create2
- tx sender and recipient (even for 0 value)
- coinbase addy when receiving tx fees
- beneficient addy for selfdestruct
- system contract addy for pre/post exec
- withdrawal recipient addy
- precompile contracts touched
- they need to be included even for 0 value OR when txs revert or creation fails for contracts (so basically if its ever interacted with then include it)
- list must be lexicographic (byte wise)
- `BlockAccessIndex`: `0` for **pre‑execution** system contract calls, 1..n for txs, n+1 for post-exec system calls
- Address Deduplication: Each address appears only once, regardless of how many changes it has
- tx_index is uint16 (https://eips.ethereum.org/assets/eip-7928/bal_size_analysis)
questions:
- What are pre-exec and post-exec system calls?
- what is the max size a BAL can get to? can we chain together some null ops and see if we can make it significantly larger?
- tx_index is uint16, can we overflow this somehow?
Test ideas:
- happy path of including one of each type
- unhappy path of one of each revert or failed deployment (loop through reasons for failure too)
- contract deployment with too little gas (failed)
- try a 7702 call that will somehow use up over 16M gas (so the initial call that is gated by the RPC goes through, but the subsequent action it triggers should fail)
- have system contract address (withdrawal for e.g) be triggered by a 7702 delegated address
- attempt EXTCODECOPY via 7702 address
- ensure coinbase is included in BAL
- check calling blockhash precompile if it shows up in the BAL (seems like it should, but it wont trigger execution so easy to miss)
- trigger exec from addresses that are lexicographically similar, just endianness switched. It could catch some endian bugs.
- 7702 that triggers an SLOAD but it doesn't write anything
- tx that writes a storage slot to change its value, then a following tx that changes it back to the original value. Do this once with separate txs and once with a single tx. this should trigger edge cases in pre != post checks.
- SELFDESTRUCT where the balance is sent to a 7702 contract that then triggers some other execution? (is this possible?)
- everything in the Edge case section of the EIP should have a test for it in EEST/Assertoor
- 7702 delegation failed tx
- check if the blockhash contract single updated storage slot is included properly
- withdrawals and deposits are subject to queue size and churn limits, test edge cases when this changes around
- reuse actions against one address and make sure that it doesnt get included twice by mistake