# 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