Adds a transaction type which contains an access list, a list of addresses and storage keys that the transaction plans to access. Accesses outside the list are possible, but become more expensive. Intended as a mitigation to contract breakage risks introduced by EIP 2929 and simultaneously a stepping stone toward broader use of access lists in other contexts.
Really interesting concept. Seems like a stepping stone towards stateless clients.
The EIP mentions that the discount for transactions using access lists will increase over time as more tools are developed and access-list generation matures. What kind of tools will need to be developed? Is it just for access-list generation, or also for validation?
Just for access list generation. The code for determining whether or not accesses are part of the access list and doing things based on that is already in 2929.
Why does the second option need to have 3 in multiple places? Couldnāt we alternatively enforce keccak(3 || rlp([nonce, gasPrice, gasLimit, to, value, data, accessList])) be the hash that is signed over? It would require minimal assemble and would avoid the weird edge case where the outer type doesnāt match the inner type.
I believe this option would work, but it means we would have two different encoding schemes at play, which is a bit unfortunate. Part of the goal with these 4 proposals was to minimize the complexity of encoding, and having to encode most of the signed data and then encode that along with some more data to get the final signed thing increases complexity.
If people believe that this proposed solution is superior to the 4 options above, I donāt mind adding it to the list to be discussed though!
At the All Core Devs call we decided on no SSZ for Berlin. After some discussion in Discord, we have decided to go with multi-pass as it saves a byte and aligns pretty closely to with how we already deal with transactions. We also decided to switch over to yParity rather than v to pay down a bit of technical debt around v (EIP-155 and Bitcoin baggage).
Should SSTORE gas cost also be reduced by being included the lists? Looks like the SSTOREās performance can be increased if its MPT paths are pre-loaded - writing a key-value in MPT is essentially a read-modify-write operation.
What exactly is the rationale for introducing this Y_Parity parameter? This seems to add unnecessary complexity? Why would we want to introduce this Y_Parity - are there use cases?
Doesnāt this ruin the idea of EIP-155, which prevents that we can run Transactions on chains with a different chain ID? Since we only have a binary v value now, this thus does not prevent us from running the Transaction on other chains with different chain IDs?
Y_Parity is essentially the same as V in normal signatures. It was simplified to just 0 or 1 instead of 26 or 27. Since chainID is now an explicit element in the payload, we can interpret however we like.
Although it is not supported in the current spec, we could definitely add support for chainID == 0 meaning that the transaction is valid on all chains.
What is the reason that we have to save all the zeros of these addresses and storage slots? Canāt we save some data by left-padding the addresses to 20 bytes with zeros, and the storage slots can be left-padded to 32 bytes with zeros? It does not make sense to me to save all these zeros if we can also left pad them. Transactions are invalid if they provide addresses longer than 20 bytes or storage slots longer than 32 bytes.
The yParity, senderR, senderS elements of this transaction represent a secp256k1 signature over keccak256(rlp([1, chainId, nonce, gasPrice, gasLimit, to, value, data, access_list])).
Hash ( 01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, access_list, y, r, s]))
Also a thing about this 01 byte inserted before RLP kind of breaks the block rlp encoding. this byte is not rlp encoded and thus makes block rlp oversized.
Does this EIP also implement the Homestead rule: if you create a contract, then charge 53k gas instead of 21k? (Iād assume yes).
From EIP-2:
The gas cost for creating contracts via a transaction is increased from 21,000 to 53,000, i.e. if you send a transaction and the to address is the empty string, the initial gas subtracted is 53,000 plus the gas cost of the tx data, rather than 21,000 as is currently the case. Contract creation from a contract using the CREATE opcode is unaffected.
How exactly are we supposed to encode this transaction type on a eth_getTransactionByHash (and friends)? Do we include a new field transactionType here? If this field does not exist, it is a legacy transaction? Simply trying to cast it on the available fields seems dangerous to me (if we get an alternative transaction type which also uses access_list then it might get wrongly casted by consumers).