|
| 1 | +# DAPI Architecture |
| 2 | + |
| 3 | +This document explains the high-level architecture of DAPI, its components, and how they interact with the Dash ecosystem. |
| 4 | + |
| 5 | +## Overview |
| 6 | + |
| 7 | +DAPI (Decentralized API) serves as the gateway to the Dash network, providing access to both Dash Core blockchain functionality and Dash Platform (Evolution) features. |
| 8 | +Unlike traditional centralized APIs, DAPI is designed to run on the Dash masternode network, ensuring high availability and censorship resistance. |
| 9 | + |
| 10 | +## Architecture Diagram |
| 11 | + |
| 12 | +``` |
| 13 | +┌─────────────────────────────────────────────────────┐ |
| 14 | +│ DAPI │ |
| 15 | +│ │ |
| 16 | +│ ┌───────────────────┐ ┌─────────────────────┐ │ |
| 17 | +│ │ │ │ │ │ |
| 18 | +│ │ API Process │ │ Core Streams │ │ |
| 19 | +│ │ (api.js) │ │ Process │ │ |
| 20 | +│ │ │ │ (core-streams.js) │ │ |
| 21 | +│ │ - Core endpoints │ │ │ │ |
| 22 | +│ │ - Platform │ │ - Block streaming │ │ |
| 23 | +│ │ endpoints │ │ - TX streaming │ │ |
| 24 | +│ │ - JSON-RPC │ │ - Masternode list │ │ |
| 25 | +│ │ │ │ streaming │ │ |
| 26 | +│ └───────┬───────────┘ └─────────┬───────────┘ │ |
| 27 | +│ │ │ │ |
| 28 | +└──────────┼──────────────────────────┼───────────────┘ |
| 29 | + │ │ |
| 30 | + ▼ ▼ |
| 31 | +┌──────────────────────┐ ┌─────────────────────────┐ |
| 32 | +│ │ │ │ |
| 33 | +│ Dash Core │ │ Drive & Tenderdash │ |
| 34 | +│ │ │ │ |
| 35 | +│ - Blockchain │ │ - Platform State │ |
| 36 | +│ - Mempool │ │ - Data Contracts │ |
| 37 | +│ - Wallet │ │ - Identities │ |
| 38 | +│ - P2P Network │ │ - Documents │ |
| 39 | +│ │ │ │ |
| 40 | +└──────────────────────┘ └─────────────────────────┘ |
| 41 | +``` |
| 42 | + |
| 43 | +## Key Components |
| 44 | + |
| 45 | +### API Process |
| 46 | + |
| 47 | +The API process is the main entry point for DAPI. It handles the basic gRPC and JSON-RPC endpoints, including both Core and Platform functionality. |
| 48 | + |
| 49 | +#### Responsibilities: |
| 50 | + |
| 51 | +- **JSON-RPC Server**: Serves legacy JSON-RPC endpoints |
| 52 | +- **Core gRPC Endpoints**: Serves Core blockchain endpoints |
| 53 | +- **Platform gRPC Endpoints**: Serves Platform (Evolution) endpoints |
| 54 | + |
| 55 | +#### Connections: |
| 56 | + |
| 57 | +- **Dash Core**: Connects to Core via RPC and ZMQ |
| 58 | +- **Drive**: Connects to Drive via gRPC |
| 59 | +- **Tenderdash**: Connects to Tenderdash via RPC and WebSocket |
| 60 | + |
| 61 | +#### Startup Sequence: |
| 62 | + |
| 63 | +1. Load configuration |
| 64 | +2. Connect to Dash Core's ZMQ interface |
| 65 | +3. Initialize Platform and Drive clients |
| 66 | +4. Connect to Tenderdash WebSocket |
| 67 | +5. Start JSON-RPC server |
| 68 | +6. Start gRPC server with Core and Platform handlers |
| 69 | + |
| 70 | +#### Endpoints Served: |
| 71 | + |
| 72 | +- **Core gRPC Endpoints**: |
| 73 | + - `getBestBlockHeight` |
| 74 | + - `getBlockchainStatus` |
| 75 | + - `getTransaction` |
| 76 | + - `broadcastTransaction` |
| 77 | + |
| 78 | +- **Platform gRPC Endpoints**: |
| 79 | + - `broadcastStateTransition` |
| 80 | + - `waitForStateTransitionResult` |
| 81 | + - `getConsensusParams` |
| 82 | + - `getStatus` |
| 83 | + - And various unimplemented endpoints |
| 84 | + |
| 85 | +- **JSON-RPC Endpoints**: |
| 86 | + - `getBestBlockHash` |
| 87 | + - `getBlockHash` |
| 88 | + |
| 89 | +#### Dependencies: |
| 90 | + |
| 91 | +- Dash Core (via RPC and ZMQ) |
| 92 | +- Drive (via gRPC) |
| 93 | +- Tenderdash (via RPC and WebSocket) |
| 94 | + |
| 95 | +#### How to run |
| 96 | + |
| 97 | +```bash |
| 98 | +node scripts/api.js |
| 99 | +``` |
| 100 | + |
| 101 | +### Core Streams Process |
| 102 | + |
| 103 | +The Core Streams process handles streaming data from the Dash blockchain, including blocks, transactions, and masternode lists. |
| 104 | + |
| 105 | +#### Responsibilities: |
| 106 | + |
| 107 | +- **Transaction Streaming**: Stream transactions matching bloom filters |
| 108 | +- **Block Header Streaming**: Stream block headers and chain locks |
| 109 | +- **Masternode List Streaming**: Stream masternode list updates |
| 110 | + |
| 111 | +#### Connections: |
| 112 | + |
| 113 | +- **Dash Core**: Connects to Core via RPC and ZMQ |
| 114 | +- **Chain Data Provider**: Maintains a cache of block headers |
| 115 | + |
| 116 | +#### Startup Sequence: |
| 117 | + |
| 118 | +1. Load configuration |
| 119 | +2. Connect to Dash Core's ZMQ interface |
| 120 | +3. Initialize bloom filter emitter collection |
| 121 | +4. Set up event listeners for ZMQ events |
| 122 | +5. Initialize chain data provider and block headers cache |
| 123 | +6. Initialize masternode list sync |
| 124 | +7. Start gRPC server with streaming handlers |
| 125 | + |
| 126 | +#### Endpoints Served: |
| 127 | + |
| 128 | +- **Stream gRPC Endpoints**: |
| 129 | + - `subscribeToTransactionsWithProofs` |
| 130 | + - `subscribeToBlockHeadersWithChainLocks` |
| 131 | + - `subscribeToMasternodeList` |
| 132 | + |
| 133 | +#### Dependencies: |
| 134 | +- Dash Core (via RPC and ZMQ) |
| 135 | + |
| 136 | +### Communication |
| 137 | + |
| 138 | +Both API and Core Streams components operate independently and do not directly communicate with each other. |
| 139 | +Instead, they both connect to the same underlying services (Dash Core, Drive, Tenderdash) to provide their respective functionality. |
| 140 | + |
| 141 | +## Interfaces |
| 142 | + |
| 143 | +DAPI provides two main interfaces for client interaction: |
| 144 | + |
| 145 | +### gRPC Interface |
| 146 | + |
| 147 | +The primary and recommended interface, using Protocol Buffers for efficient, typed communication. Supports: |
| 148 | +- Request/response endpoints |
| 149 | +- Server-side streaming endpoints |
| 150 | +- Strong typing and versioning |
| 151 | + |
| 152 | +### JSON-RPC Interface |
| 153 | + |
| 154 | +A legacy interface provided for compatibility with existing tools. Features: |
| 155 | +- Compatible with the JSON-RPC 2.0 specification |
| 156 | +- Limited subset of Dash Core's JSON-RPC functionality |
| 157 | +- No streaming capabilities |
| 158 | + |
| 159 | +## Connection to the Dash Ecosystem |
| 160 | + |
| 161 | +DAPI connects to several underlying services: |
| 162 | + |
| 163 | +### Dash Core |
| 164 | + |
| 165 | +DAPI communicates with Dash Core in two ways: |
| 166 | +- **RPC Interface**: For direct blockchain queries and commands |
| 167 | +- **ZMQ Interface**: For real-time notifications of new blocks, transactions, and chainlocks |
| 168 | + |
| 169 | +### Drive |
| 170 | + |
| 171 | +For Platform functionality, DAPI connects to Drive via gRPC. Drive is responsible for: |
| 172 | +- Processing and validating state transitions |
| 173 | +- Maintaining Platform state (data contracts, documents, identities) |
| 174 | +- Providing proofs for Platform operations |
| 175 | + |
| 176 | +### Tenderdash |
| 177 | + |
| 178 | +DAPI connects to Tenderdash (a modified version of Tendermint) which serves as the consensus engine for Dash Platform. Connections include: |
| 179 | +- **RPC Interface**: For querying Platform chain state |
| 180 | +- **WebSocket Interface**: For subscribing to real-time Platform events |
| 181 | + |
| 182 | +## Process Flow Examples |
| 183 | + |
| 184 | +### Example 1: Querying a transaction |
| 185 | + |
| 186 | +1. Client sends gRPC request to `getTransaction` endpoint |
| 187 | +2. API process receives request |
| 188 | +3. API process queries Dash Core via RPC |
| 189 | +4. Dash Core returns transaction data |
| 190 | +5. API process formats the response and returns it to the client |
| 191 | + |
| 192 | +### Example 2: Subscribing to transactions with a bloom filter |
| 193 | + |
| 194 | +1. Client creates a bloom filter and connects to `subscribeToTransactionsWithProofs` stream |
| 195 | +2. Core Streams process receives the request and registers the bloom filter |
| 196 | +3. When Dash Core emits a ZMQ notification for a new transaction: |
| 197 | + - Core Streams process tests the transaction against the bloom filter |
| 198 | + - If it matches, the transaction is sent to the client with merkle proofs |
| 199 | +4. The stream continues until the client disconnects |
| 200 | + |
| 201 | +## Security |
| 202 | + |
| 203 | +DAPI protects connections by using TLS to encrypt communication between clients and the masternodes. |
| 204 | +This encryption safeguards transmitted data from unauthorized access, interception, or tampering. |
| 205 | +Platform gRPC endpoints provide an additional level of security by optionally returning cryptographic proofs. |
| 206 | +Successful proof verification guarantees that the server responded without modifying the requested data. |
| 207 | + |
| 208 | +## Deployment Considerations |
| 209 | + |
| 210 | +DAPI is designed to be deployed on masternode. The prefered and officaially supported way is to use [dashmate](https://docs.dash.org/en/stable/docs/user/network/dashmate/index.html). |
| 211 | + |
| 212 | +## Monitoring |
| 213 | + |
| 214 | +Both components use the same logging infrastructure, allowing for consistent monitoring of the entire DAPI service. |
| 215 | +Logs are output to the console by default and can be redirected to files or log management systems as needed. |
| 216 | + |
| 217 | +Key events that are logged include: |
| 218 | +- Process startup and shutdown |
| 219 | +- Connection to dependencies |
| 220 | +- Server listening status |
| 221 | +- Error conditions |
| 222 | + |
| 223 | +## Endpoints |
| 224 | + |
| 225 | +See the [endpoints](./endpoints/index.md) document for details on available endpoints. |
| 226 | + |
| 227 | +## Further Information |
| 228 | + |
| 229 | +- Consult the [Dash Platform Developer Documentation](https://docs.dash.org/projects/platform/en/stable/) for more information about the broader Dash Platform ecosystem |
0 commit comments