Better API for initializing with genesis parameters

[carver]

What was wrong?

As of #123 there will be a way to specify genesis parameters, but it will take some detailed documentation to understand, and the variety of options will probably confuse beginners. (Thanks to @voith for offering to write the docs)

Let's reduce the ways to initialize the backend with custom genesis parameters, and do it in a way that leans more on the global standards (like the genesis file, which may only be a "de facto" standard, but still better than a custom web3.py thing).

How can it be fixed?

Let's can coalesce around this as the preferred single mechanism for initializing a custom genesis state:

backend = PyEVMBackend.from_genesis(dict(gas_limit=etc))

# also accepts the equivalent json-encoded string:
backend = PyEVMBackend.from_genesis('{"gas_limit": etc}')

---

We should further explore what use cases people have for setting up custom genesis, but I think we can handle them all cleanly by creating tools to easily generate a genesis dict.

The following APIs are shooting from the hip, I'm not saying that any specific one is a good idea. Just some examples...

from eth_utils import make_genesis_accounts

genesis_accounts = make_genesis_accounts(num_accounts=3, init_state=dict(balance=10**18))

PyEVMBackend.from_genesis(dict(gas_limit=7_000_000, accounts=genesis_accounts))

or

# some silly keys, where int(key) in range(10)
keys = eth_utils.get_test_keys(10)

genesis = eth_utils.make_funded_genesis(dict(gas_limit=7_000_000), keys=keys)

tester_backend = PyEVMBackend.from_genesis(genesis)

for key in keys:
  tester_backend.add_account(keys)

How cool is it that the same tools could be used to generate a genesis file for any other node?! Speaking of which, maybe these generation tools already exist somewhere else?

[voith]

I need this feature. I will write docs for it but I don't have bandwidth for the next two weeks.

[pipermerriam]

@carver and @voith maybe we should instead use a less stringent version of the EIP1085 format since it is indeed a standard format, as well as potentially some utility tools for removing any boilerplate for the common cases.

ethereum/py-evm#1299

[voith]

cool. I'll wait for ethereum/py-evm#1299 to land then!

[pipermerriam]

@voith wanted to let you know that currently #1299 is stalled out and likely to still take a while before it gets closed.

[MatthiasLohr]

Still something happening on this?

[cburgdorf]

We do have the APIs now to initialize from a EIP1085 compatible genesis file but these APIs do currently live within Trinity. I actually think it may make sense to check which parts of it may better belong into py-evm so that this becomes more reusable outside of Trinity.