Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
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