We should use an interface for chain configuration as well (eg type ChainConfigurator interface {...}. This is of particular importance for our growing chain config which has now far-overgrown the upstream implementation. The effort would be in order to establish common patterns of configuration implementation, to enable translation/conversion between configuration data types, and to further un-hardcode some of the configuration opinions.
meowsbits
commented
4 years ago
Interfaces are currently used for several important data types:
ChainReader(implemented bycore.HeaderChainandcore.BlockChain)Enginecore.BlockValidator, etc.We should use an interface for chain configuration as well (eg
type ChainConfigurator interface {...}. This is of particular importance for our growing chain config which has now far-overgrown the upstream implementation. The effort would be in order to establish common patterns of configuration implementation, to enable translation/conversion between configuration data types, and to further un-hardcode some of the configuration opinions.Doing so would enable various Chain Configurations (ethereum/go-ethereum, parity, multi-geth, even Aleth, PyEthereum, Besu??...) to run "natively" w/o awkward adhoc conversion methods (https://github.com/etclabscore/multi-geth/blob/feat/x-chainspec-types-and-tests/params/convert/parity.go#L321, https://github.com/ethereum/go-ethereum/blob/master/cmd/puppeth/genesis.go#L366). It would also greatly simplify and validate some testing workarounds (https://github.com/etclabscore/multi-geth/blob/feat/x-chainspec-types-and-tests/tests/params.go#L136)
Essentially this helps us pay back some of the technical debt we've inherited from upstream opinions.
Rel #67