Externalizable config for a chain

[splix]

A json or yaml config for a chain.

I propose following structure:

# id of a chain
id: main 
# human readable name for chain
name: Mainnet 
genesis:
  block:
    nonce: 0x0000000000000042
    mixHash: 0x0000000000000000000000000000000000000000000000000000000000000000
    difficulty: 0x400000000"
    author: 0x0000000000000000000000000000000000000000
    timestamp: 0
    extraData: 0x11bbe8db4e347b4e8c937c1c8370e4b5ed33adb3db69cbdb7a38e1e50b1b82fa
    gasLimit: 0x1388
    stateRoot: 0xd7f8974fb5ac78d9ac099b9ad5018bedc2ce0a72dad1827a1709da30580f0544
  gasprice: olympic # id of gas prices table for evm
upgrades:
    - id: homestead
      name: Homestead
      block: 1150000
      features:
        - id: homestead # a feature configured in a code
    - id: gas-reprice
      name: Gas Reprice
      block: 2500000
      features:
        - id: set-gasprice
          options:
            gasprice: gastable2
    - id: diehard
      name: Die Hard
      block: 3000000
      features:
        - id: ecip1010 # bomb delay
          options:
            length: 2000000
        - id: set-gasprice
          options:
            gastprice: gastable3
        - id: eip155 # replay protection
          option:
            chain-id: 61
state:
  - address: 0x3282791d6fd713f1e94f4bfd565eaa78b3a0599d
    balance: "1337000000000000000000"
  - address: 0x17961d633bcf20a7b029a7d94b7df4da2ec5427f
    balance: "229427000000000000000"
bootstrap:
  - "45.32.7.81:30303"
  - "174.112.32.157:30303"

Configs for mainnet and testnet should be compiled into geth binary, but user should be able to specify custom config file from command line

[realcodywburns]

This is much needed.

[pascaldekloe]

We already have the core.ChainConfig JSON, just no geth flag to specify the file.
The core.GenesisDump works with geths "init" command.

[whilei]

I've got a preliminary JSON-ified sketch of @splix 's proposed chain config structure (per above) in a gist here, if it saves a few keystrokes.
... and this is an example of a ChainConfig struct JSON dump (as implemented in branch chain-config), which covers some of the proposed specs https://gist.github.com/whilei/d2f5bf4680ed65f7e264b74922e6a2f8

Edit: most recent example of JSON chain configuration file (including features structure): https://gist.github.com/e5f76982e9bbd83d992d28a22e261db0

[whilei]

@splix By your proposed outline for the chain config above, would it be accurate to translate/summarize it in Go as something like:

type ExternalChainConfig struct {
	ID string `json:"id"`
	Name string `json:"name"`
	Genesis *core.GenesisDump `json:"genesisDump"`
	ChainConfig *core.ChainConfig `json:"chainConfig"`
	State []*core.GenesisAccount `json:"state"`
	Bootstrap []*discover.Node `json:"bootstrap"`
}

?

I'm just wanting to get feel for what we should expect the external chain config to cover, since we have an existing struct ChainConfig that comprises some but not all of your proposed specs.

[splix]

the idea of features { id, options} is that we don't know upfront which upgrades are going to happen, and in most cases it will be something uniq written in code.

So for example:

- id: ecip1010
  options:
    length: 2000000

means that this fork should enable code related to ecip1010, and pass options to it (anything custom, as kv map).

ECIP-1010 is implemented in code, it's a change to difficulty formula. And this code will check if it's enabled or not for current block (chain config should be available from many places).

Similar for

- id: eip155
  option:
    chain-id: 61

But this code is located in completely different place. So it's just a common place to make this configurations.

Enabling a new gastable is another feature, which we already used for 2 upgrades. Prices itself are hardcoded and that's fine, we just need to enable price table by an id, such as olympic or gastable3 in example above.

Also keep in mind that

• features of upgrade are separate, all getting enabled at that block
• can have different options (say for testnet and mainnet)
• on some chain aren't part of chain upgrade (like EIP155 feature is not enabled in diehard fork for testnet)
• there could be private chains with completely different set of features and upgrades, we jsut provide an interface to that

This config is proposing different structure and will require rewriting of different parts of app, like way to enable/disable current code for ECIP-1010, EIP155, and so on

[whilei]

Another question: we now have an init command which reads from a given genesis JSON file, and I've made the methods for writing a genesis dump as well. Would it make sense to separate chain configuration from genesis block config and allocations?

I'm imagining in this case a user could use either/both --chainconfig and --genesis flags to independently specify separate JSON files. I don't have a great sense of the typical use-cases involved, but there seems to be something "Unixy" (~ do smaller things simply) about modularizing them at intuitive levels?

[whilei]

Closing via #189.