This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1. Agree: use OpenAPI (alternatives were SSZ and Protobuf) | |
Prysmatic comment: Protobuf can be easily switched to OopenAPI so no blocker here | |
————— | |
2. Agree: use versioning (issue to be opened on the versioning string) | |
————— | |
OpenAPI: Json, integer and byte format | |
- 53-bit or 64-bit integers? | |
3. Hex for int encoding, with 0x prefix | |
Strong sentiment against Base64 | |
Felix: Eth1/Geth uses hex, no people complained in the past couple years | |
issue to be opened | |
————— | |
Beaconstate | |
Defined by slot/state root/ | |
What to do in the context on “duck typing” | |
GraphQL maybe better? | |
Other types: fork choice, … | |
—> small group of 4-5 people to work on this for next week. | |
Jim McDonald: event streams are quite good at avoiding the multiplication of endpoint | |
better for a consumer, not sure for the implementers | |
Requirement for Prysmatic, want to make it a first-class citizen | |
Felix: we don’t want to keep a buffer of historical event | |
—> should be dispatched to any open RPC connection | |
and then discard it. | |
===> Streams not a blocker | |
—————————— | |
Validator API | |
—————————— | |
Closing thoughts | |
On validator/client split: would enable innovation on the validator layer, for example RocketPool | |
Proto: who’s working on a consumer of API, for what | |
Jacek: data through libp2p? | |
-> Danny: what are we enabling | |
-> zahary: reduce attack vector by only having libp2p running instead of a server | |
Felix: note we don’t want to fall in the same situation as Eth1 | |
where browsers have to talk to Metmask/a centralised entity to access the chain | |
i.e. the browsers must be able to access the core network | |
==> TODO: Nimbus team to open an issue with a mapping between OpenAPI endpoint and libp2p endpoint | |
—————————— | |
Working group: | |
Mikhail, Marin, Jim | |
————————————— | |
Chat | |
—————————————— | |
From danny to Everyone: (04:02 PM) | |
https://github.com/ethereum/eth2.0-pm/issues/143 | |
From Mikhail Kalinin to Everyone: (04:11 PM) | |
I vote for 0x instead of Base64, it sometimes handy for debugging to mentally convert values. Base64 would make it almost impossible. | |
From Tomasz Stanczak to Everyone: (04:12 PM) | |
let us not use Base64 please losing readability a lot hex encoded numbers in Eth1 can be mentally converted to some extent - this helps a lot I stand by Felix and Mikhail here | |
From Me to Everyone: (04:14 PM) | |
Base64 is for bytes though, we are talking about integer as stringified int vs hex (I agree that Base64 should be avoided) | |
From Tomasz Stanczak to Everyone: (04:15 PM) | |
ok @Mamy, thanks | |
From Mikhail Kalinin to Everyone: (04:15 PM) | |
May we end up with the default encoding of ints and keep the other option for those cases where it will be appropriate | |
From Felix to Everyone: (04:15 PM) | |
V | |
From Me to Everyone: (04:15 PM) | |
bytes serialisation is next i assume ;) | |
From Tomasz Stanczak to Everyone: (04:15 PM) | |
as for numbers I am less in favour of 0x but it is acceptable | |
From Felix to Everyone: (04:15 PM) | |
https://github.com/ethereum/wiki/wiki/JSON-RPC#hex-value-encoding | |
From Tomasz Stanczak to Everyone: (04:16 PM) | |
but it caused us trouble in Nethermind - some libs are hard ot modify to handle these as numbers | |
From Felix to Everyone: (04:16 PM) | |
for reference, the eth1 API encoding | |
From Tomasz Stanczak to Everyone: (04:17 PM) | |
also we started allowing passing ints in decimal in our CLI and Geth is sometimes inconsistent - small numbers are sometimes sent as normal ints (but very rarely and I think it is just some minor technical debt from far in the past) | |
From Me to Everyone: (04:18 PM) | |
Parsing a base 10: https://github.com/status-im/nim-stint/blob/master/stint/io.nim#L242-L261 I didn’t put a shortcut for Hex but it’s significantly faster | |
From Mikhail Kalinin to Everyone: (04:28 PM) | |
I will be capable of doing the work on API on Thursday or Friday this week. | |
From Marin Petrunić to Everyone: (04:28 PM) | |
I can also help if needed :) | |
From Mikhail Kalinin to Everyone: (04:29 PM) | |
That would be great! I am open for any help. | |
From Felix to Everyone: (04:30 PM) | |
https://geth.ethereum.org/docs/rpc/pubsub | |
From Marin Petrunić to Everyone: (04:30 PM) | |
I would just remind that this is pretty standard tehnology with support everywhere: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events | |
From Raul Jordan (Prysmatic) to Everyone: (04:31 PM) | |
+1 | |
From Chih-Cheng Liang to Everyone: (04:31 PM) | |
come across this quote, but not sure how to fit in to the current discussion https://twitter.com/realLedgerwatch/status/1210519703304708096 | |
From Chih-Cheng Liang to Everyone: (04:31 PM) | |
"What is JSON RPC for? Is it a Web API (needs to be 99% available, but not 100% accurate), or database access API (needs to be 100% accurate, but not necessarily 99% available)" | |
From Raul Jordan (Prysmatic) to Everyone: (04:36 PM) | |
+1, graphql should be optional and not required for client implementers | |
From Mike Goldin to Everyone: (04:36 PM) | |
Can GraphQL schemas be generated from OpenAPI? | |
From Felix Lange to Everyone: (04:37 PM) | |
not really | |
From Raul Jordan (Prysmatic) to Everyone: (04:37 PM) | |
https://github.com/IBM/openapi-to-graphql | |
From Felix Lange to Everyone: (04:37 PM) | |
oh, OK didn't know that | |
From Jim McDonald to Everyone: (04:37 PM) | |
Agree that simple here is good, JSON meets that goal and not sure that graphql does | |
From Raul Jordan (Prysmatic) to Everyone: (04:50 PM) | |
https://github.com/gobitfly/eth2-beaconchain-explorer | |
From Jim McDonald to Everyone: (04:51 PM) | |
https://github.com/wealdtech/ethdo talks to prysm nodes today to obtain bits and pieces of information, and has features such as sending voluntary exits. I stopped work on the API pieces until it standardises, so lots still to do |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment