accessList seems to be failing in very particular case.

[novaknole]

Hi @ricmoo @zemse

I am having a really, really interesting problem here...

I have a contract that was deployed with EIP-1667. So It means that I have one original contract and then proxy contract that looks at this original contract.

Scenario 1:

const signer = await new providers.Web3Provider(
   window.ethereum
 ).getSigner()

    let tx = await signer.sendTransaction({
      from: 'myAddress',
      to: 'toAddress',
      data: data,
      value: 0,
      type: 1,
      accessList: [
        {
          address: 'address', // whatever(original contract) is behind the proxy...
          storageKeys: []
        }
      ]
    })

data calldata tries to call the function on toAddress and this function uses .send in the code to send some funds to that proxy contract. Because my recipient is the proxy contract, .send would never work unless I use accessList feature, because send redirects 2300 Gas, but delegateCall needs more, so I need to warm the address.

So the sum up is that above code just worked in only,ONLY,ONLY,ONLY the first time ever. After this, it never worked at all. Always fail at the line where I use .send.

Scenario 2:

let provider = ethers.getDefaultProvider('rinkeby');
let walletWithProvider = new ethers.Wallet('myPrivateKey', provider);

  let tx = await walletWithProvider.sendTransaction({
    from: 'myAddress',
    to: 'toAddress',
    data: data,
    value: 0,
    type: 1,
    // gasLimit: 500000
    accessList: [
      {
        address: 'address', // whatever(original contract) is behind the proxy...
        storageKeys: []
      }
    ]
  })

As you can see, I only change provider and use my private key to call transaction. So not much difference. This Always works.

Any idea why the first one fails and second one always succeeds ?

[ricmoo]

There should be no difference, off the top of my head.

My first guess would be the client you are using in the first example is not EIP-2930-aware and is just using legacy transactions.

Can you add provider.on("debug", console.log)? In the eth_sendTransaction call, if type And accessList is present, it’s out of ethers hands and your client may need to be updated. You could also try eip-1559 (via type 2) which also supports access lists and that ethers can detect for you whether the client supports it. :)

[novaknole]

@ricmoo

Unfortunatelly , I don't have a demo project, but the same access list works when I don't use metamask provider..

Strange thing is that since access list now appears on etherscan transaction, metamask seems to be supporting it, because before I updated metamask, access list was not found at all. now it appears, but empty, though..

[novaknole]

@ricmoo

My new version(latest) supports EIP-1559 because I changed to type 3 and metamask threw the error. So all good here. As for the EIP-2930, they must be supporitng it as I already explained and here is the link: MetaMask/metamask-extension#11288

Nothing makes sense now why it's not working.

[ricmoo]

So it could be a bug in how ethers passes it to MetaMask. Because in the screen shot, it still looks weird. :)

I haven’t been able to test w/ MetaMask yet, so sounds like now I can. I’ll look into it this evening. :)

[novaknole]

@ricmoo

Thanks a lot for the quick answers.

Keep me posted ^__^

[ricmoo]

Tracking in #1877