evm

In case of contract creation, to field should be null.

Currently the json-rpc endpoint return 0x0000000... which is inconsistant with the transaction receipt value which return nul

{
  "blockHash": "0xdb8e24f2b9eb7bc046c957b0dd6f60118cb0a49dc23dcd3c2ee55a242db4666b",
  "blockNumber": 203281,
  "from": "0x94b93044f635f6E12456374EC1C2EeaE6D8eD945",
  "gas": 3788418,
  "gasPrice

What is wrong?

Previous to ethereum/py-evm#1805 we had classes like eth.vm.BaseVM that served as the reference. Now, we have interfaces defined in eth.abc.

There are now two primary problems.

• Many of our docstrings might still refer to the wrong class. Most class references in docstrings should be referencing the abc base classes now.
• Most of the met

Would be really nice to get native BSC support :)

Right now env vars that accept boolean-esque values (like DAPP_TEST_FFI, HEVM_RPC, and DAPP_BUILD_OPTIMIZE) each require slightly different values to represent true.

Sometimes 1 means true, sometimes yes means true, sometimes any non 0 value means true, and sometimes the variable being set at all means true!

Ideally all boolean-esque env vars would only accept one of these value

We can safely disallow any use of solc below 0.4.25.

Add an example to load file from a directory along with https://remix-ide.readthedocs.io/en/latest/locations.html#load-one-of-the-default-remix-files

Describe the solution you'd like
Nethermind currently uses the Parity chainspec format while virtually all other clients use the Geth chainspec format. It would be great for composability if Nethermind also supported the Geth chainspec format

We should create a corpus of tests to verify that CFG recovery is accurate and complete, and there are no regressions.

First of all, when upgrading CI to clang-13 to do coverage report, the llvm-profdata reports malformed data. So we need to make it work with clang-13 first. Try reproducing the issue locally with clang-13 toolchain.

The CI steps: https://github.com/ethereum/evmone/blob/dca15dfd3a7a998b38821061e329d54df41484e6/circle.yml#L335-L357
Clang documentation: https://clang.llvm.org/docs/SourceBasedC

The ethabi::errors::InvalidData error could use some more info such that the user can find which part of their input is invalid.