Eth2.0 Implementers Call 18 Agenda

[djrtwo]

Eth2.0 Implementers Call 18 Agenda

Meeting Date/Time: Thursday 2019/5/23 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing Updates
2. Client Updates
3. Research Updates
4. Network
5. interop lockin
6. beacon node validator api
7. Spec discussion
8. Open Discussion/Closing Remarks

[jrhea]

How about we bring up everyone's new favorite topic? The interop lock-in

https://hackmd.io/24LjX1XDQp6cQ6AC5TqrVg?view

[hwwhww]

@spble's Beacon Node API for Validator PR ethereum/consensus-specs#1069 looks good to me to merge. Just want to signal here in case any objection.

[BelfordZ]

I'd love to discuss OpenRPC as a replacement for OpenAPI in @hwwhww's PR #1069 if possible.

[paulhauner]

I'd love to discuss OpenRPC as a replacement for OpenAPI in @hwwhww's PR #1069 if possible.

@BelfordZ, just to confirm, we're defining a RESTful-HTTP API, not a JSON-RPC.

I'm not familiar with OpenRPC, but I suspect it's for the latter not the former?

[BelfordZ]

@paulhauner Thanks for the reply. Understood this is for RESTful api. I would like to talk about the benefits of sticking with JSON-RPC, and how using OpenRPC we can get the same tooling and standardized interface description, but without having to complicate things by adding an additional service interface (rest over http when JSON-RPC is already prolific within the blockchain space, and growing in others).

I'd be happy to help in showing how the OpenAPI yaml file can be converted to OpenRPC, and even more happy to discuss why JSON-RPC is the superior standard.

for context, we've long toiled over the idea of ditching JSON-RPC in favour of REST so that we could use OpenAPI. We then built OpenRPC as a fork of OpenAPI that fills the gap in JSON-RPC tooling. Here we are today, hoping that we can keep ethereum using JSON-RPC =).

[paulhauner]

No worries. Perhaps you could expand upon your proposal?

As mentioned here, the fact that OpenAPI exists was not a driving factor in the decision for REST/HTTP (at least for me).

[zscole]

As discussed on the call, here is the link to our test repo for libp2p. I would say that we should expand on these test series and add some more based on the initial results. We'd likely want to run additional tests to observe the effects of various peer counts. Any feedback or comments would be appreciated.