> For the complete documentation index, see [llms.txt](https://skyneticlabs.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://skyneticlabs.gitbook.io/docs/services/mainnet-networks/polkadot/dn-oriented-tools.md).

# DN-oriented Tools

Latency Matrix, Replay Analyzer, Integrity Probe

### Table of Contents

* DN Operator Latency Matrix
* Consensus Replay Footprint Analyzer
* DN Chain Integrity Probe

***

## 1. DN Operator Latency Matrix

#### Purpose

A network-latency measurement tool for evaluating RTT between regions, ASNs, and your Polkadot/Substrate nodes.

#### Goal

To select optimal locations for validator or collator nodes and to understand inter-regional propagation delays that impact block production and finality.

***

#### What Problems It Solves

* Identifies slow regions before deploying new infrastructure.
* Benchmarks network quality between hosting providers (ASNs).
* Helps quantify RTT that affects:
  * BABE block propagation,
  * GRANDPA message flow,
  * network gossip (transactions, justifications, and proofs).

***

#### Installation

```bash
git clone https://github.com/Skyneticlabs/polkadot/tools/dn-latency-matrix
cd dn-latency-matrix
./install.sh
```

***

#### Usage

**Basic RTT test**

```bash
dn-latency-matrix run --targets regions.yaml
```

**Full-mesh RTT testing**

```bash
dn-latency-matrix run --full-mesh
```

**Example Output**

```
Region A → Region B: 28 ms
Region A → Region C: 112 ms
ASN123 → ASN456: 7 ms
```

***

#### Interpreting Results

| RTT      | Assessment | Recommendation                     |
| -------- | ---------- | ---------------------------------- |
| < 10 ms  | Excellent  | Suitable for validator placement   |
| 10–40 ms | Acceptable | Good for RPC nodes and collators   |
| 40–80 ms | Borderline | Possible propagation delays        |
| > 80 ms  | Poor       | GRANDPA and gossip may be affected |

***

#### Practical Polkadot Use Cases

* Region selection for new parachain collator clusters.
* Verifying peer-connection quality before validation sessions.
* Identifying provider-specific issues (e.g., AWS → Azure jitter).
* Network performance checks before client upgrades.

***

## 2. Consensus Replay Footprint Analyzer

#### Purpose

A hardware evaluation tool that benchmarks system performance under heavy Polkadot/Substrate state replay.

#### Goal

To ensure your server can sustain peak load during:

* database rebuilds,
* warp-sync or replay catch-up,
* congested epochs,
* processing of complex parachain blocks.

***

#### What It Measures

* NVMe throughput (IOPs, latency spikes).
* CPU saturation during block decoding.
* RocksDB/ParityDB lock contention.
* Replay cycle duration and consistency.
* Bottlenecks when processing GRANDPA justifications.

***

#### Installation

```bash
git clone git clone https://github.com/Skyneticlabs/polkadot/tools/dn-replay-analyzer
cd dn-replay-analyzer
cargo build --release
```

***

#### Usage

**Replay local node database**

```bash
dn-replay-analyzer --db-path /var/lib/polkadot/chains/polkadot/db
```

**Synthetic high-load simulation**

```bash
dn-replay-analyzer --synthetic --threads 16
```

**Detailed performance profile**

```bash
dn-replay-analyzer --profile --output report.json
```

***

#### Warning Thresholds

| Metric                  | Threshold | Meaning                              |
| ----------------------- | --------- | ------------------------------------ |
| CPU > 85%               | Poor      | Risk of block-processing delays      |
| NVMe latency > 5 ms     | Critical  | Disk is a bottleneck                 |
| DB locks > 5%           | Poor      | RocksDB/ParityDB contention          |
| Replay < 50k blocks/min | Slow      | Hardware not suitable for validation |

***

#### Practical Polkadot Use Cases

* Validating new servers before migrating a validator.
* Comparing cloud and bare-metal performance (AWS/Hetzner/Equinix).
* Detecting SSD degradation before failure.
* Preparing hardware for parachain workloads.

***

## 3. DN Chain Integrity Probe

#### Purpose

A lightweight chain-integrity verifier for validators and collators.\
It detects state inconsistencies early, before they affect block production or finality.

#### Goal

To protect nodes from:

* database drift,
* incorrect app-hash / state-root,
* height lag,
* silent RocksDB/ParityDB corruption.

***

#### What It Checks

* State root / app-hash consistency across trusted RPC endpoints.
* Local height vs remote RPC height.
* GRANDPA finality checkpoint alignment.
* Missing gossip messages and propagation anomalies.
* Hash drift between peers.

***

#### Installation

```bash
curl -s https://get.dn-probe.sh | bash
```

***

#### Usage

**One-time health check**

```bash
dn-integrity-probe check
```

**Comparing against multiple RPC endpoints**

```bash
dn-integrity-probe check \
  --rpc https://rpc.polkadot.io \
  --rpc https://my-node:9944
```

**Continuous background monitoring**

```bash
dn-integrity-probe daemon --interval 15s
```

***

#### Common Alerts

| Alert                 | Meaning                              | Recommended Action                         |
| --------------------- | ------------------------------------ | ------------------------------------------ |
| App-hash mismatch     | Local state root differs from remote | Recheck database, consider a clean restart |
| Height drift detected | Local height lags > 2 blocks         | Investigate network or provider issues     |
| DB lock anomaly       | Excessive lock contention            | Examine NVMe load, check disk health       |
| Unexpected reorg      | Local fork detected                  | Inspect peers, validate network health     |

***

#### Actual Value for Polkadot Operators

* Early detection of issues before missing BABE slots.
* Ensuring collator correctness and reliable block inclusion.
* Reducing the risk of silent database corruption.
* Providing early alerts through Telegram, Discord, or Prometheus.