What's is the current industry landscape in terms of RPC specs and what should we be focusing on next?

[deblasis]

This question stems from #112, where one of the goals/deliverables is:

Compile a list of examples and references of other RPC specs for next steps

The objective of this discussion is to understand what the community is accustomed to, to identify things we should or not focus on, priorities, and generally speaking to have an open conversation with whoever is interested in the topic and wants to contribute in any shape or form to defining how our RPC should be designed and evolved over time.

[deblasis]

First of all, I'd like to cover the basics in terms of architecture/protocol being used and then later on dive in, perhaps with a follow-up discussion into defining more minute details like "What procedure calls we should expose?", etc.

This is to reduce the scope of the work that will be potentially planned from this.

Research

Following a list of a few blockchains that I sampled "randomly" with links to their Specs / RPC docs and a summary of the highlights from the protocol point of view:

• Ethereum - Docs (Spec)

  🏷️ JSON-RPC 2.0 standard, uses OpenRPC.

  🚄 Transport: HTTP API, WebSocket and Unix Domain Sockets.

• Algorand - Docs (Spec)

  🏷️ not JSON-RPC 2.0 but similar approach (arguments are in array form in the body and the endpoint represents the method call), secure (HTTPS + API token).

  🚄 Transport: HTTP API.

• Solana Docs

  🏷️ JSON-RPC 2.0 standard.

  🚄 Transport: HTTP API, PubSub WebSocket.

• Cosmos - Docs

  🏷️ not JSON-RPC 2.0, secure (HTTPS + basic auth).

  🚄 Transport: HTTP API (using gRPC-Gateway with OpenApi generation via protoc plugin), gRPC.

• Polkadot Docs

  🏷️ JSON-RPC 2.0, secure (HTTPS + basic auth), SDK (javascript library), Sidecar to provide HTTP API

  🚄 Transport: HTTP API, WebSockets.

• Avalance Docs

  🏷️ JSON-RPC 2.0, secure (HTTPS + JWT token)

  🚄 Transport: HTTP API.

• Ripple Docs

  🏷️ not JSON-RPC 2.0, secure (HTTPS + JWT token)

  🚄 Transport: HTTP API, WebSockets.

• Monero Docs

  🏷️ JSON-RPC 2.0, secure (HTTPS + basic auth)

  🚄 Transport: HTTP API, WebSockets.

Takeaways

• ✅ It looks like that the ubiquitousness of HTTP APIs is here to stay.

• ❌ The JSON-RPC 2.0 specification is pretty much implemented in the majority of cases and perhaps we should consider doing the same

• ❌ We should start thinking about security as well at some point

• ⁉️ Implementing other transport methods could be important. "Build it and they will come"? It would be probably nice to ask node operators from V0 for what they feel like is missing in the RPC and interaction with the nodes in general.

    Guide
    ❌ | ⁉️ = potential action item for next steps
  

This answer is meant to capture what was previously answered here in this comment and to make it more open for discussion

[Olshansk]

We discussed this offline in a team meeting today so I just wanted to capture

• Pocket endpoints: We'll stick with the OpenAPI implementation in [Utility] Local Proof of Stake CLI - CLI and RPC client [part 1/2] - Issue #112 #177 for now since it solves all the problems we have for now build on it if/when we need to.
• Relays: When we start working on M3 more heavily, we'll start deciding whether to prioritize gRPC over JSON RPC

I also wanted to capture the notes from @deblasis below for others to see:

---

Goals of a good RPC (not in particular order)

• It’s easy to understand and well documented
• I can implement it easily regardless of my tech stack/programming languages
• It provides all the functionalities I need to interact with the server
• It’s performant
• It’s secure or securable (perhaps it would be great to provide guidelines for node runners if we want to offload security to other layers like reverse proxies for example)

Protocols / Standards / Tech being used in the wild

• WebAPI

  • OpenAPI 3.0 / Swagger ⬅️ we are here currently in V1 (after we merge my PRs)
    • Ubiquitous WebAPIs
    • Extremely easy to implement clients
    • Documenting the API is easy
  • JSON RPC 2.0
    • It adds structure to requests and responses
    • Useful when there’s an open communication with the server, for example via WebSockets for async and/or long running operations
      (nice example here: https://open-rpc.org/getting-started/)

• Websockets

  • Full duplex communication between hosts over TCP.
  • Wildly used in many areas for notifications, messaging, especially in-browser but also being used in blockchains
    • It makes sense to use it in conjunction with JSON RPC 2.0 (see [Using WebSockets | ethereum.org](https://ethereum.org/en/developers/tutorials/using-websockets/))
  • Example: [WebSocket (javascript.info)](https://javascript.info/websocket#:~:text=Here's%20an%20example%3A,%22)%3B%20%7D%3B%20socket.)

• gRPC

  • Fast, schema enforced alternative to JSON
  • Supports bindings with multiple languages (all the major ones) and therefore code-generation
  • Streaming support
  • Honorable mention goes to Cosmos for implementing gRPC along with WebAPIs using gRPC-Gateway ([Messages and Queries | Cosmos SDK](https://docs.cosmos.network/master/building-modules/messages-and-queries.html#queries))
  • Examples: (go specific examples here: [Basics tutorial | Go | gRPC](https://grpc.io/docs/languages/go/basics/))

• Unix Domain Sockets

  • Very performant and ideal when client and server are on the same host.
  • The same handlers can work with remote hosts as well with small variations so it’s easy to support both scenarios.
  • Examples: [Unix domain sockets in Go - Eli Bendersky's website (thegreenplace.net)](https://eli.thegreenplace.net/2019/unix-domain-sockets-in-go/) and [Docker Socket File for IPC (lobster1234.github.io)](https://lobster1234.github.io/2019/04/05/docker-socket-file-for-ipc/)

[DragonDmoney]

Personally, I am in favor of JSON RPC 2.0 because gRPC and Websockets aren't the best combinations (and WebSockets are definitely going to be implemented), and applications will most likely be using JSONRPC, so it would make sense (at least to me) to use the same framework.

[Olshansk]

I came by Chia's go RPC implementation here and just wanted to throw the link for future reference.