-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Common genesis.json format scheme across all client implementations #1085
Comments
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:
Sidenote: have seen that this is discussed in the core devs meeting today, sorry, can't join on this for time reasons. |
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. |
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.
a node reads the link with a path to a file that contains huge state and loads up the state data from it. |
hmm. I wonder, could we abstract EVM gasPrices to some config file as well. |
This should probably be updated to use the Fancy names for forks as is being done here: ethereum/tests#488 |
@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. |
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 |
Set chsin params at https://github.com/ethereum/retesteth/wiki/RPC-Methods#test_setchainparams |
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:
|
I guess explicitly mention that network ID is not identified in genesis (so the same genesis can be used for different networks), but chainID must be specified if the SpuriousDragon fork (or later) is included. |
Now that I have to run so many different clients with different ways approaching this issue, I would say, the ones implementing the Genesis format / EIP-1085 are the most annoying ones. I think we should not stop at defining the genesis and forks only but give a complete network description. This is what Parity Ethereum is doing. The advantage is, you can simply pass a single file to a client and it runs without any additional need for parameters or descriptors. My main critique is the lack of Parity Ethereum and Nethermind with chain spec:
Geth and Pantheon with EIP-1085 Genesis:
Note the scrollbar. When I talk with client implementers I encourage them to use chain specs rather than genesis files. /cc @cburgdorf @ajsutton Happy to draft an additional ERC for that, however, meanwhile what about networkID and bootnodes support? |
|
I hope you do @5chdn! It's pretty compelling to be able to launch the client with only the chain spec file. It seems that chain spec is a proper subset of the genesis file spec, which is a nice property: implementing chain spec means that you necessarily support genesis files, too. |
I only became aware of this EIP just a moment ago and I was thinking about this topic today. The Hive updates now allow simulations to run multiple flavours of client at once, and I am now in the process of adding Trinity, Nethermind, Harmony,, into the available clients. Simulators now determine which clients should be invoked, rather than letting the Hive engine specify. In this case, the Simulators can now also specify which concrete configuration/genesis each client instance can use. The current Hive code places the responsibility of parsing the genesis.json (supplied by the engine) onto some fairly fragile shell scripts in the client container entrypoints. I want to get rid of all that. So until I noticed the convo on AllCoreDevs and here, I was about to go the route of having the Simulator instantiate the client with a client specific config that the Sim supplies. Based on this new info here, I think the best route instead would be for me to have Hive accept a common format and then implement the conversions there, so the Simulators can be agnostic about Client launch details. |
Supporting Chain spec also looks quite good, the only concern I have is that it enables significantly more customisation in a couple of areas which I suspect wouldn't be supported by a number of clients (such as defining precompiles in the chain spec file). It could be trimmed it down to the configurable options that are widely supported and/or required by major networks, or for some things maybe it's a reasonable lever to make them more configurable (e.g. some of the ethash params seem sensible to make configurable). |
One other consideration is what the default values should be for things that aren't specified in the config and/or which fields are strictly required. That's important for cross-client compatibility but also for upgradability as new fields are added as part of future hard forks. |
The common genesis format should be as a yellowpaper rule for all clients to implement. Writing scripts that convert one format to another for specific client is not a good design. |
@winsvega That is true. Hive, however, needs to support scenarios like starting simulations involving different versions of client concurrently, including those prior to a commonly agreed format, and even when different versions of the later common format exist. A common format however would make the implementation of those requirements a lot simpler. In the meantime, the code from Hive (when implemented) could serve as a config/genesis generator for whomever (eventually) |
With
|
We lately have introduced a new https://github.com/ethereumjs/ethereumjs-common library - providing generic access to network and hardfork params - where a lot of design thinking has been put in, it might be worth to take some inspiration for some structures. On the other way we are also ready to rework if things are suboptimal, over- or under-engineered. Just as a first note, have no time right now to go into more detail but will join the discussion during the next days. |
Have opened an issue https://github.com/ethereumjs/ethereumjs-common/issues/30 on genesis format changes, if you have a first look on our library and stumble over things which you think we should definitely change, feel free to post there. |
Sorry, due to personal reasons I am delayed on this, still plan to jump in though and give some thought. |
Is there a standardized name for the new constantinople fork yet? We picked |
Pantheon picked constantinopleFix which I believe matches what the reference tests are using. |
So your genesis key name is |
|
Interesting, that's definitely something this EIP would have to get consensus on. All of the key names in trinity (and in the issue summary above) include Would be good to check what other major clients are doing too. But for now, I have to go push a trinity release. |
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
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:
The text was updated successfully, but these errors were encountered: