etclabscore / eth-x-chainspec Goto Github PK

• multi-geth/multi-geth#91 (comment)
• https://github.com/paritytech/parity-ethereum/blob/1871275ecdf02431bf67d09a1b25be8ff8916e3a/ethcore/src/client/evm_test_client.rs#L98
• https://github.com/paritytech/parity-ethereum/blob/0199acbece836c49e07410796c40c185e9051451/ethcore/src/ethereum/mod.rs#L129
• https://github.com/paritytech/parity-ethereum/blob/002496603c18234f129ba99fbe3659dd927bf05b/ethcore/src/json_tests/state.rs#L132
• https://github.com/ethereum/tests
• https://wiki.parity.io/Chain-specification.html
• https://github.com/keorn/parity-spec

https://wiki.parity.io/Chain-specification

Pretty well documented. Pretty thorough. Parity is popular.

... Maybe some things we'd suggest to change?

https://github.com/etclabscore/eth-x-chainspec/blob/master/config_parity.go

The general idea is to create a go package that can read parity chainspecs.

I chose using structs with custom json Un/Marshal methods because it seemed to most logically extensible; maybe eventually config.go might house some kind of abstracted 'chain spec' interface. But for now I just wanted to get these Rust-native JSON structures in to Go land.

With x-client available chainspec, defining specs, for, *cough, tests, becomes more approachable.

https://wiki.parity.io/Chain-specification.html

Chain configurations also matter because

• https://eips.ethereum.org/EIPS/eip-2124
• https://eips.ethereum.org/EIPS/eip-2364

Configs need to agree on what is considered a fork and what is not.

For example, is 1920000 considered a fork for classic?