State Proofs: Client SDK for communication with nodes - Design

[ashcherbakov]

Motivation
It's possible to use gRPC/REST for communication with nodes

• query (read requests) via REST (no specific SDK is needed, everything is quite standard)
• write requests: generate and sign a transaction via code generated from .proto files (can be done for any language); send (broadcast) transaction via either REST or gRPC.

This doesn't require any specific client SDK. However, lack of a client SDK for DCL has the following drawback:

• If there are no trusted nodes a client can connect to, state proofs must be used for queries. And a client needs a convenient API/library/SDK to be used for state proofs verification.
• It would be good to force client to call the state proof verification API (if response is obtained via REST, and proof verification has to be a separate step, there are high chances some clients may forget to call it).
• It's possible to have state proofs support if there are no SDK, but both State Proofs: Return proofs in gRPC/REST #185 and State Proofs: Verify proofs in gRPC/REST on platforms and languages supported by Tendermint/Cosmos #186 has to be done. Alternative (and probably more simple) option is to have a client SDK which uses Tendermint RPC, so we have state proofs out-of-the-box and don't need State Proofs: Return proofs in gRPC/REST #185.
• Although it's possible to generate the code to be used for generating and signing transactions from .proto files, it requires quite advanced users. Moreover, it's sufficient to do it just once for every platform/language and re-use.
  Having an SDK can simplify that process a lot (clients just call simple and clear API for DCL specific operations).

Acceptance Criteria

• Prepare a design how DCL client SDK API may look like.
• Decide what technology (language) it should be based on (Go or Rust)?
• Decide what platforms and languages it should support
• Decide what communication pattern (gRPC/REST or Tendermint RPC) should be used