Rationale
Cardano nodes can assume one of two roles:
- block producer: in charge of minting blocks
- relay node: in charge relaying blocks from / to peers.
Each of these roles has concrete responsibilities and runtime requirements. Criteria such as network topology, resource allocation, backup procedures, etc vary by role.
We argue that there’s a 3rd role that should be treated independently with the goal of optimizing its workload: nodes that are used with the sole purpose of resolving local state queries or serving as data source for downstream tools that require ledger data.
There are many potential optimizations for nodes performing this type of workload that are not currently possible with the Cardano node:
- drastically limiting the amount of memory required to execute the node
- switching to storage solutions with different trade-offs
- providing alternative wire protocols more friendly for data queries
This new role would be useful in the following scenarios:
- As an efficient backend for dApps (eg: a Lucid provider).
- As data source for well-known tools such as DB-sync, Ogmios, CARP, Oura, etc.
- As a fast, low resource node for syncing other producer / relay nodes.
- As a ledger data source that scales dynamically according to query load.
- As a node that leverages network / cloud storage technology instead of mounted drives.
- As a node that scales horizontally, allowing high-availability topologies.
- As a low resource local node for resolving local state queries.
Detailed design
Data nodes will share some of the features with the mainstream Cardano node:
- Node-to-Node and Node-to-Client Chain-Sync mini-protocol
- Node-to-Node Block-Fetch mini-protocol
- Node-to-Client Local-State-Query mini-protocol
This new type of node will also provide features not currently available in the mainstream Cardano node:
- HTTP/JSON endpoint for common local state queries
- gRPC endpoint for local state queries and chain-sync procedure
- Different storage options including NFS, S3 & GCP Buckets
- Low memory consumption (allowed by the trade-offs in scope)