basefee OPCODE support in london fork and Awaiting transaction in the mempool error

[penandlim]

Environment information

• brownie Version: 1.19.2
• ganache-cli Version: 7.7.3
• solc Version: 0.8.18
• Python Version: 3.9.9
• OS: osx M1

What was wrong?

Contracts that use block.basefee cannot be fetched from explorer due to VirtualMachineError: invalid opcode
When instantiated with ABI, still fails in istanbul hardfork network at the time of simulation.

Trying to use london as fork setting will accept the opcode but then get stuck with Awaiting transaction in the mempool

This can be replicated via this repo
https://github.com/penandlim/brownie-base-fee-test

Replicating basefee fails using ape-safe and eth-brownie

After applying the network-config.yaml, runing the below script fails due to invalid opcode

brownie run --network goerli-fork scripts/basefee_simulation_get_from_explorer.py
Using the hardfork london setting still fails with same error

brownie run --network goerli-fork-london scripts/basefee_simulation_get_from_explorer.py
If we try bypassing compiling by providing the ABI, we encounter a new error. The transaction gets stuck with Awaiting transaction in the mempool and does not proceed.

brownie run --network goerli-fork-london scripts/basefee_simulation_from_abi.py

How can it be fixed?

Allow compiling with london evm_version when contracts are fetched from explorer.
Allow using 0 gwei for gas to prevent tx from getting stuck .

[Shchepetov]

Bumping this, this is an extremely necessary change

[Shchepetov]

@penandlim can you please tell, have you found a workaround for this?

[penandlim]

@Shchepetov Unforuntately no :(

Using ganache v7 + brownie 1.19.2 with impartial support for forking seems at best right now. (workaround for waiting in mempool but the new opcodes still doesnt work)

Unfortunately we aren't able to fork and test all contracts using brownie so we have moved to using foundry and hardhat more when we can with tenderly as another supportive tool.

[penandlim]

@Shchepetov

Apeworkx/ape package might be able to be used as an alternative. I havent tried it yet but looks like a successor of the brownie project.

[gosuto-inzasheru]

i even see this happening using the most basic transaction as soon as i fork london or above:

Brownie v1.20.5 - Python development framework for Ethereum

Generating interface ABIs...
*** is the active project.

Launching 'ganache-cli --chain.vmErrorsOnRPCResponse true --wallet.totalAccounts 10 --hardfork london --fork.url *** --miner.blockGasLimit 12000000 --wallet.mnemonic brownie --server.port 8545 --chain.chainId 1'...
Brownie environment is ready.
>>> accounts[0].transfer(accounts[0], 0)
Transaction sent: 0xc86c0a9f7b80b70b25adae66b8e317858e936a9658359e5918e182bde25b1aa3
  Awaiting transaction in the mempool... /

[gosuto-inzasheru]

solved!

the awaiting tx in mempool can be prevented by setting priority_fee to auto on your development networks:

networks:
  development:
    priority_fee: auto

[gosuto-inzasheru]

unsolved still for me though is that that actually requires gas on the accounts that are sending the transactions. would be nice to not have to send (test) gas from accounts to those eoas in question