Thread by @assafmo

So what's the difference between all of these RPC, LCD, gRPC, gRPC-web, gRPC-Gateway, Amino, Protobuf stuff in the @Cosmos SDK?

Heard the guys @gameofnodes_ are wandering too, so here's an explainer 👇

RPC is an HTTP 1.1 server exposed by #Tendermint (on port 25567). It uses HTTP POST + JSON-RPC 2.0 for data encoding. There's also a Websocket service on /websocket (also JSON-RPC 2.0).

The CLI uses RPC to access the chain and in general everything is accessible via RPC.

LCD (Light Client Daemon) is also an HTTP 1.1 server exposed by @Cosmos SDK (on port 1317). It exposes a REST API for the chain, and traditionally every query was reimplemented for LCD and behind the scene routed to RPC.

Amino is the main data encoding format that was used before @Cosmos SDK v0.40 and is still supported today as legacy because it's still the only acceptable format for signing txs in the Cosmos Ledger App.

github.com/tendermint/go-…

Amino is basically JSON with some modifications. For example, the JSON spec doesn't define numbers greater than 2^53, so we use strings in Amino when encoding a type greater than uint64/int64.

For more example see github.com/scrtlabs/secre…

In @Cosmos SDK v0.40 (Stargate) Protobuf replaced Amino as the data encoding format of txs and chain state. Protobuf has far better encoding/decoding performance and far more developer tooling than Amino. Protobuf encodes to binary and is more compact.

developers.google.com/protocol-buffe…

With the switch to Protobuf we also got gRPC (for free!). gRPC functions are defined and automatically generated from Protobuf, so now devs don't need to implement the same query three times for RPC, LCD and CLI.

gRPC - TCP server with Protobuf for data encoding (port 9090).

gRPC-web - HTTP2 server with Protobuf for data encoding (port 9091). HTTP2 supports binary payload, so this is a thin proxy to gRPC.

gRPC-web is the most efficient way that's also compatible with browsers.

gRPC-Gateway - HTTP 1.1 server with REST API and base64 encoded Protobuf for data encoding.

gRPC-Gateway piggybacks off of LCD, so it's also on port 1317. The endpoints that it exposes are the "/v1beta1/" ones (for now), and it routes on the server to gRPC.

So now that we know what Protobuf and gRPC are, I need to circle back to RPC and note that JSON-RPC 2.0 is used for message passing, but before that the data is encoded using Protobuf and then base64, because JSON doesn't support binary data.

In addition, messages to Tendermint RPC are serialized, so for example queries cannot run in parallel, and txs need to wait for queries. RPC also uses the default Go HTTP server, which is a bit buggy and less performant than the gRPC server Go implementation.

It's also worth noting that in @Cosmos SDK v0.46 the old REST API is supposed to be deprecated, which mean that gRPC-Gateway will be the only thing on the LCD.

26657 🤦‍♂️😅

Amino vs. Protobuf vs. Ledger is also the reason authz isn't supported in Ledger. Its has no Amino definitions in the SDK (as it's legacy) and the Cosmos Ledger App cannot sign on Protobufs txs.

https://twitter.com/larry0x/status/1543665771825463298?t=SccVb8GKrHULEZdUlcGJug&s=19

For reference:

- secret.js uses gRPC-web
- cosmjs uses RPC
- terra.js uses gRPC-Gateway
- Telescope will use gRPC-Gateway and probably gRPC-web too

LCD is called that way because pre SDK v0.40, to get REST API you had to run another service using e.g. `gaiacli rest-server --laddr 0.0.0.0:1317 --node localhost:26657`, hence "Light Client Daemon". In v0.40 REST was moved inside the node service but the name has stuck.