0

Access Lists were introduced in https://eips.ethereum.org/EIPS/eip-2930, and one of the design decisions was to support duplicates "because it maximizes simplicity, avoiding questions of what to prevent duplication against" which has already been discussed that it could have been a bad idea (https://ethereum-magicians.org/t/eip-2930-optional-access-lists/4561/38)

Currently, two of the most popular EL for Ethereum can produce different results for the eth_getTransactionByHash method given differences in the accessList field (more details are available in this ticket: https://github.com/NethermindEth/nethermind/issues/6140).

My question is then, are the following examples of access lists semantically equivalent?

A

[
  {
    "address": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
    "storageKeys": [
      "0x510e81dc21f9d12ece3d833248460825e23f3d1c83a95b3bbd97d46d8116d207",
      "0x67b8f4b3f7634a068794dc582fe78971f7839d32fdaaa6d65130b975c100c4b2",
      "0xe134c27de4a88ed171063a52dcc1b9256efa9a36f2492471429d20385ae9a215"
    ]
  }
]

B

[
  {
    "address": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
    "storageKeys": [
      "0x510e81dc21f9d12ece3d833248460825e23f3d1c83a95b3bbd97d46d8116d207",
      "0x510e81dc21f9d12ece3d833248460825e23f3d1c83a95b3bbd97d46d8116d207",
      "0x67b8f4b3f7634a068794dc582fe78971f7839d32fdaaa6d65130b975c100c4b2",
      "0xe134c27de4a88ed171063a52dcc1b9256efa9a36f2492471429d20385ae9a215"
    ]
  }
]

C

[
  {
    "address": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
    "storageKeys": [
      "0x510e81dc21f9d12ece3d833248460825e23f3d1c83a95b3bbd97d46d8116d207",
      "0x67b8f4b3f7634a068794dc582fe78971f7839d32fdaaa6d65130b975c100c4b2"
    ]
  },
  {
    "address": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
    "storageKeys": [
      "0xe134c27de4a88ed171063a52dcc1b9256efa9a36f2492471429d20385ae9a215"
    ]
  }
]

D

[
  {
    "address": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
    "storageKeys": [
      "0x510e81dc21f9d12ece3d833248460825e23f3d1c83a95b3bbd97d46d8116d207",
      "0x67b8f4b3f7634a068794dc582fe78971f7839d32fdaaa6d65130b975c100c4b2"
    ]
  },
  {
    "address": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
    "storageKeys": [
      "0x510e81dc21f9d12ece3d833248460825e23f3d1c83a95b3bbd97d46d8116d207",
      "0xe134c27de4a88ed171063a52dcc1b9256efa9a36f2492471429d20385ae9a215"
    ]
  }
]

This questions has also been asked in https://github.com/ethereum/EIPs/pull/2930#issuecomment-1737607788, but I doubt it'll get much attention.

1 Answer 1

0

first note that the examples you provided are JSON that the RPC API can receive, but the actual access list is RLP-encoded into the transaction.

but yes, according to the spec those transactions should be accepted by the blockchain. of course it will be needlessly more expensive, but for simplicity sake it does.

the nodes might normalize the lists (remove duplicates or sort items), but as long as they are valid once RLP-encoded and signed then according to the spec the blockchain will accept them.

there could be an issue if you sign a transaction with duplicates, get a different access list from the node then try to rebuild the tx, you will not get the same signature. but this is probably a very niche use case.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.