2020-04-20 eth2 API.txt

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