# 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? ✅ (65k tx @ 21k gas is 1350M gas limit) - If worst case for BALs is that the optimisation is fully disabled (e.g uniswap pools filling the full block), then how do we plan on using any benefits of BALs for scaling? Do we ignore the attacks? 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 - malicious block that provides fewer touched addresses than expected and observe all clients reject it - update the worst case block size table with worst case BALs -