Beacon Node API for Validator #1069
Conversation
…ing stuff specific to the issue and conforming to standard text layout.
- Added all the fields from BeaconBlock(Body) - Tagged all paths as 'Minimum for validator' - Removed BeaconNode and ValidatorClient conventions - Moved the basic non-object schema components to the top - Broke out common beacon block properties into the BeaconBlockCommon object - Fixed links to Eth2.0 spec
- Moved /node/fork up with other node endpoints - Added descriptions and ordering to tags - Removed common merkle_root schema, to be more specific in descriptions. - Moved BeaconBlockCommon next to appropriate schemas. - Lots of small grammar improvements, full stops at end of descriptions.
- Removed TOC - Removed all the old spec stuff - Uploaded spec to SwaggerHub and provided a link to it. - Added a 'license' section to the API description.
spble
changed the title
if we formalize the schema format for the spec messages a bit, one can be generated from the other, potentially - that could be useful in the future as well, when defining new messages! |
- Corrected to use American English instead of Australian - Fixed spelling mistake with indices - Changed tag to 'MinimalSet' and 'OptionalSet' - Added a response to the list of components - Renamed 'block_production' to 'block_proposal'
|
Thanks very much for your review @hwwhww! Yes, it is a shame to have it duplicated and would be best to have it generated. |
|
Just wanted to chime in and show that this is possible with Here is an example of the playground with the ethereum-json-rpc-specification It simplifies a lot of what you have already since it follows familiar principles. |
Thanks. We're not using REST/HTTP just for OpenAPI though (I think we'd use it even if OpenAPI didn't exist). See here for detailed reasoning. |
|
REST is great until you want to support other transports. Then it starts to fall apart. JSON-RPC is simple and transport agnostic, and now has the tools to compete. The arguments outlined (like stateful across multiple calls) only apply to API design and can be avoided. I’d love to see ETH continue to use JSON-RPC with the rest of the blockchain ecosystem. |
|
@shanejonas REST APIs (HTTP) are fairly transport agnostic. Can you clarify? Eth 1.x implementers see stateful rpc apis as having been something of a mistake, afaik. |
|
With HTTP (and swagger outlined here). When you do want to support websocket, IPC, postMessage/webworker or any other transport in the future you will need yet another spec and debate on how to best describe it. JSON-RPC doesn't tell you how stateful your API should be. Those are implementation details. |
- Rewording of specification goal paragraph - Clarify get duties description regarding chain reorgs. - Add epoch parameter to get duties, and new error 406 - Block publishing action is clarified around validation, with a new status code 202 - The validator pubkey and PoC bit are passed to produce attestation - Attestation publishing action is clarified around validation, new status code 202 - Rewording of genesis_time, 'block' -> 'slot' - Update Crosslink to latest spec - Added missing signature field to IndexedAttestation
- Fixed spelling (and made American English) - Clarified the schema for the new poc_bit field, and description.
… to the master branch (instead of dev).
This PR proposes an OpenAPI specification for communication between the beacon node and the validator client. This is intended to be as minimal a specification as possible, just enough to allow the validator client implementation to function without any extra features.
This PR formalises the discussions in issues #1011 and #1012.
This RFC/proposal creates an OpenAPI yaml file inside the
specs/validatorfolder which is discussed by a short markdown document in the same folder. A link to this markdown document has been placed in the primary README.md file for the repository.If you'd like to explore the API proposal directly, please take a look on SwaggerHub