If seems could be quite useful from security monitoring standpoint, as we can easier access state changes and do block-level assessments;
Would it make sense to have 7702 delegation designation traced there as well?
Yeah you can infer the delegation already statically having the raw transaction (tx type, tx_to + calldata should be enough to tell where an EOA will delegate to).
Furthermore, with regards to 7702, the BAL will contain the nonce change + a code change for the respective EOA. So, should have everything needed.
I added one additional sentence to the EIP to clarify that delegation indicators as inlcuded in BALs:
1 Like
Yeah, looking again code_changes should be sufficient
Would be interested in getting your opinion on one question that is still open. Should the BAL include state locations that are nod modified but still needed during execution (without any post-value but just the signal that a certain storage slot is needed) e.g. from BALANCE opcode. The argument against including those is that is adds additional 50% in size. On the other hand, from the performance persepctive, it might be enabling parallel batch I/O.
Curious what you think about security/auditing aspects here.
@yoavw are there any important interplays/gains to be aware of between BALs and native AA storage restrictions?
I’m curious about your opinion on how to best deprecate EIP-2930 Access Lists. I see the following two options:
- cleanly deprecate by removing - very much not backwards compatible but removes code which is generally nice.
- reprice them to silently deprecate them (economically). I proposed something like this here.
I’m not sure if there are usecases that are maybe not that visible on chain where it is urgently needed that txs come with state access predeclared (even though its correctness isn’t enforced). I don’t have a strong opinion and see why a clean removal of everything 2930 related might be the best option.
I agree with the economic approach. Penalize them according to their burden on the network, and people will stop using them. It also seems fairly simple.
I would like for that change to be in the same hark fork as the replacement mechanism (which I hope is a strict block access list though I haven’t been following this discussion recently), but if tx access lists are already a net negative then they should be deprecated as soon as possible.
Yeah agree, it’s best for Glamsterdam.
The thing that matters most to me is that the worst-case block size was significantly reduced with 7623, but the new worst-case block size now includes of a transaction that used 3/5 of the gas available for 2930 ALs and the rest for calldata. This is because you’d still get the cheaper 4/16 calldata price.