[EPIC] Read-only client APIs

[KtorZ]

Tasks

• Define a subset of local-state-queries to support in the mini-protocols and their equivalent in the utxoRPC

• Establish (and implement) a test strategy for the client APIs

• Extend utxoRPC specification with new Conway's primitives

Scope/Acceptance Criteria

1. Support the following node-to-client (server side) ouroboros mini-protocols:

   • Local-chain-sync
   • Local-tx-submission
     • What about transaction validation and user feedback? Using the node-to-node tx-submission protocol we won't get any feedback from the trusted Haskell node, so how do we make a not awful UX out of that? Most of the validations will require at least the protocol parameters.
   • Local-tx-monitor
   • Local-state-query restricted to queries available in any era (ledger tip, system start, chain height)
     1. Over local domain socket & named pipes (Windows), CBOR-encoded data
     2. Over TCP, CBOR-encoded data

2. gRPC (cf: https://utxorpc.org/) covering the following areas:

   • Block synchronization
   • Transaction submission
     1. Over TCP socket, Protobuf-encoded data

3. JSON API should as much as possible follow existing "standards" and practices from the ecosystem.

   • Interesting CIPs to keep an eye on:
     • CIP-0116? | Universal JSON Encoding for Domain Types cardano-foundation/CIPs#766
     • CPS-0012? | Query Layer Standardization cardano-foundation/CIPs#625

4. Ensure compatibility (and integration) with the following middleware:

   • Oura
   • Ogmios
   • Kupo
   • Scrolls
   • Sundae Sync
   • Snek first of its name
   • cardano-cli (partial support, in the extent of what's covered by the local-state-query support)

5. Windows? What do to?

   • On the one hand, we don't need immediate Windows support and certainly won't need it for the Relay and Full nodes.
   • On the other hand, adding Windows support to a stack late in the process is complicated so we might not want to overlook Windows support.