Common genesis.json format scheme across all client implementations

[winsvega]

Simple Summary

Client should be able to parse genesis.json config file that is commonly accepted and supported by all other client implementations.

Motivation

Currently every ethereum client has it's own genesis.json format which makes it impossible to move one node configuration to another node. (parity config to geth and vice versa). And it is not about unique options that some clients have, it's about using common fields but with different format. Same options has different style and names in .json configurations across client implementation.

Hive tool uses bash script in order to make a config file for each client individually.

Users have to search for correct genesis.json description for each client on different web pages.

Suggestion

Make a list of minimum required fields for genesis.json config file that each client would be able to parse and understand.

Example:

{
       "version" : "1",
       "params": {
                "miningMethod" : "NoProof",
            	"homesteadForkBlock": "0x00",
		"EIP150ForkBlock": "0x00",
		"EIP158ForkBlock": "0x00",
		"byzantiumForkBlock": "0x00",
		"constantinopleForkBlock": "0x00",
		"chainID": "0x01",
       },
       "genesis" : {
            	"nonce": "0x0000000000000042",
		"difficulty": "0x020000",
		"author": "0x0000000000000000000000000000000000000000",
		"timestamp": "0x00",
		"extraData": "0x11bbe8db4e347b4e8c937c1c8370e4b5ed33adb3db69cbdb7a38e1e50b1b82fa",
		"gasLimit": "0x1388"
       },
       "accounts": {
            "0x095e7baea6a6c7c4c2dfeb977efac326af552d87" : {
                "balance" : "0x0de0b6b3a76586a0",
                "code" : "0x6001600101600055",
                "nonce" : "0x00",
                "storage" : {
                    "0x00" : "0x02"
                }
            },
            "0x2adc25665018aa1fe0e6bc666dac8fc2697ff9ba" : {
                "balance" : "0x29a2241af62ca034",
                "code" : "",
                "nonce" : "0x00",
                "storage" : {
                }
            }
       }
}

[holgerd77]

Hi, thanks for submitting this EIP, I think this could be useful to find some common ground here.

In the current format I see different problems with the data structure, which would probably hold me back to use this in production:

1. To have the hardforks added in a centrally managed/updated file makes things unflexible. If a client relies on this and would want to e.g. add some draft Casper hardfork params based an this list, one would have to wait for an updated released genesis.json file. This is not practical.

2. If a hardfork list should be maintained/included I would propose not to include this into the genesis file. Beside that this actually is no genesis data, this takes off the static nature of a genesis.json file. This prevents to e.g. provide a checksum/hash for the file, which would be useful to verify its integrity. So I would instead maintain a separate hardforks.json file.

3. Having the genesis accounts integrated in the file makes the file very large. If clients just need the genesis parameters (e.g. to instantiate a genesis block) they always have to load the whole huge file. This makes things unnecessarily inefficient. I would also propose to use a separate genesisAccounts.json file here.

4. I think for this to be maximally useful this should be defined with different networks in mind, not just the Ethereum mainnet.

Sidenote: have seen that this is discussed in the core devs meeting today, sorry, can't join on this for time reasons.

[holgerd77]

One thought further: I am generally skeptical if this can be provided in a way that clients want to use/parse this "as is". It will nevertheless be helpful if this information is provided officially and from a trustful source, even if only parts are taken and/or not parsed or used directly but just copied.

[winsvega]

Speaking of splitting the config file. I think it is not a good idea. If you split options into several different files everything will become messy pretty fast.
However you don't want to edit a large file with the genesis state.
An idea for solution of this was to allow the field accounts (or state) that contains all the state data for the genesis block to be of two types.

1. if the state is small (like in tests) then it could easily fit into config file
2. if the state is huge, the field accounts could contain a path to the file that contains all the state.

a node reads the link with a path to a file that contains huge state and loads up the state data from it.
thus you could have one small config file with all the options for node and a huge state file separated.

[winsvega]

hmm. I wonder, could we abstract EVM gasPrices to some config file as well.
It looks like some other parties doing their own implementation of ethereum would like to use our test source files

[pipermerriam]

This should probably be updated to use the Fancy names for forks as is being done here: ethereum/tests#488

[pipermerriam]

@winsvega while working to implement this in trinity I've found the spec to be lacking a bit. What do you think about adding a JSON-schema definition to this EIP? I've written one up which can be found in this PR: ethereum/py-evm#1299 though I think there's some necessary discussion on things like required fields and the required formats for data.

[winsvega]

We've tried already. Making a complicated hard to read several pages jsob scheme does not help. Could we just formalize fields and its values? Please look

[winsvega]

Set chsin params at https://github.com/ethereum/retesteth/wiki/RPC-Methods#test_setchainparams

[pipermerriam]

Could we just formalize fields and its values? Please look

Yes, that was my intent with JSON-schema, but I understand that format is not the most accessible. It sounds like you are thinking about more of a natural language spec which defines the fields, formats, required/optional, etc? If so, 👍 as I'm indifferent to how it is specified, only that there is a spec with what I think is necessary information:

• what fields are required
• what each field means
• what formats are allowed (like is the 0x prefix required/optional?)
• additional validation (like is it invalid to have homesteadForkBlock < byzantiumForkBlock?)