fix: use MiningChain

[charles-cooper]

as of py-evm 0.12.x, MainnetChain behaves differently (doesn't have all the header fields filled in). use MiningChain as going forward it will apparently be more future-proof

What I did

fix for #397

How I did it

How to verify it

Description for the changelog

Cute Animal Picture

[fselmo]

I am getting a fix in for that AttributeError but I do think the MiningChain is a better way to instantiate, if all you want is the latest VM starting at genesis. The MainnetChain has the added burden of not having the Prague mainnet block yet because it has not yet hit mainnet. So it shouldn't really be used to configure a chain that doesn't care about non-mainnet properties.

I can't speak to the integration test failures here but this is the recommended way to instantiate the chain. I suggested another approach that can likely make things more modular for future iterations and allow you to control what VM you are at rather than relying on the changing latest_mainnet_at().

[fselmo]

These can probably go now.

[fselmo]

I would definitely recommend using MiningChain over MainnetChain for stability and your own control. Alternatively, you can configure the chain directly:

_Chain = MiningChain.configure(chain_id=1, vm_configuration=[(0, PragueVM)])

Seeing as one of the comments above has a goal to make this configurable, you could eventually configure it as, for example, Cancun to Prague at 5:

vm_configuration=[(0, CancunVM), (5, PragueVM)])

[fselmo]

See suggestion below.

[charles-cooper]

I am getting a fix in for that AttributeError but I do think the MiningChain is a better way to instantiate, if all you want is the latest VM starting at genesis. The MainnetChain has the added burden of not having the Prague mainnet block yet because it has not yet hit mainnet. So it shouldn't really be used to configure a chain that doesn't care about non-mainnet properties.

I can't speak to the integration test failures here but this is the recommended way to instantiate the chain. I suggested another approach that can likely make things more modular for future iterations and allow you to control what VM you are at rather than relying on the changing latest_mainnet_at().

i suspect the test failures have to do with changing the start block from 1 to 0, but when i try that, i get

File ~/.venvs/boa/lib/python3.11/site-packages/eth/chains/base.py:128, in BaseChain.get_vm_class_for_block_number(cls, block_number)
    126         return vm_class
    127 else:
--> 128     raise VMNotFound(f"No vm available for block #{block_number}")

VMNotFound: No vm available for block #0