# ADR 0006: Validator-Infrastruktur, getrennte Datenspeicherung und Cockpits ab Devnet

> **Entscheidungsverlauf, Stand v0.6:** Die verpflichtende zentrale `potatium-network`-Control-Plane und ein Registrierungsportal sind durch [ADR 0008](0008-schlanker-netzzugang-admin-und-identitaeten.md) **aufgehoben**. Unverändert gelten das frühe Hub-/Network-Admin-Monitoring, die On-chain-Mining-Registry und 100 % PoP-/Worker-Gebühren für den Fonds. Historische Abschnitte unten dokumentieren den früheren Stand.

**Datum:** 2026-10-25  
**Status:** Produkt-/Betriebsarchitektur akzeptiert; technische Komponenten und Ports offen

## Kontext

Der Projektbetreiber möchte nachvollziehen, welche Komponenten er neben Entwickler-LXC, Teilnehmer-Hubs und Workern selbst deployen muss. Gleichzeitig sollen Betreiber und Teilnehmer **vom ersten lauffähigen Devnet an** echte Statusinformationen erhalten. ADR 0005 plante Admin-Web zunächst später; das gilt für **schreibende Verwaltung**, nicht mehr für read-only Beobachtung.

## Entscheidung

1. Keine zentrale Blockchain- oder Coin-Datenbank. Potatium benötigt aktive **CometBFT-Validatoren**, jeweils mit eigener Potatium-ABCI++-Anwendung und eigenem lokalen Chain-/App-State. Der Network Admin ist ausdrücklich **nicht** für Konsens/Mining erforderlich.
2. Erst ein Validator für das Devnet, danach vier mit anfangs fester, autorisierter Validatorgruppe für lokale/multihost Testnet-Tests. Initial betreibt der Projektbetreiber diese Infrastruktur. Die spätere Validatorrolle anderer Teilnehmer ist offen; Mining-Worker werden nicht automatisch Validatoren.
3. **Potatium Hub** bleibt eine autonome Full Node inklusive Browser-Wallet, lokaler Node-GUI und optionalem Mining; Worker bleiben schlanke, gekoppelte Mining-Agenten ohne eigene Full-Chain-/Wallet-Schlüssel. Mehrere eigene Hubs können in der Teilnehmer-Clusteransicht zusammengefasst werden.
4. **Ab dem ersten lauffähigen Devnet:** Hub-Cockpit und gesonderter **read-only Network Admin** zeigen echte Werte wie Chain-ID, Blockhöhe, Validator-/Peerstatus, Fehlerzustände. Beim initialen UI-Gerüst ohne Chain ausschließlich ehrliche „nicht verbunden“-Werte. Beide werden parallel zur Kernimplementierung iterativ erweitert, nicht auf M5/M6 verschoben.
5. Network Admin als kleiner separater Monitoring-Dienst, im Dev-LXC zum Anfang, später optional eigene Management-VM. Optionaler Monitoring-Speicher/SQLite/Zeitreihen ist nur Beobachtung, keine Konsensabhängigkeit. Kein allgemeiner zentraler Hostagent oder öffentliches RPC als Voraussetzung.
6. Netzwerkweite schreibende Betreiberaktionen bleiben späterer separater Admin-CLI mit gültig signierten On-chain-Autorisierungen vorbehalten. Read-only Admin erhält keine Spend-/Validator-/Operator-Admin-Schlüssel und darf weder Guthaben verändern noch Mining-Gewinner beeinflussen.
7. Native Deployments `linux/amd64`, `linux/arm64` zuerst, Docker später optional. Dev-LXC ohne Docker, APIs zunächst loopback/SSH-Forward; Multi-Host-Verkehr nur mit dediziertem Sicherheits- und Firewall-Konzept.

## Begründung

Klare Trennung von Konsens, Nutzerbetrieb, Worker-Steuerung und Netzwerkbeobachtung; frühe Fehlersichtbarkeit; keine zentralisierte Coins-Datenbank oder Single Point of Failure; keine versteckte Wallet-Schlüsselübergabe. Die im Hub eingebettete Wallet gehört einem Betreiber, nicht technisch jeder Node. Mehrere Hubs/Worker können dieselbe registrierte Auszahlungsadresse verwenden.

## Alternativen

- Zentraler Masterserver samt SQL-Ledger: abgelehnt, widerspricht dezentrales L1-Konzept.
- Admin-Cockpit als Voraussetzung für Blockproduktion: abgelehnt, wäre zentrale Verfügbarkeitsabhängigkeit.
- Admin-Web vollständig erst nach M6: für **Statuslesen** abgelehnt, für sensible Schreibverwaltung weiter zurückgestellt.
- Jeder Worker als Validator/full node: abgelehnt, Ressourcenaufwand und Rollenvermischung.
- Jeder Hub zwangsweise Validator: abgelehnt, Full Nodes ohne Abstimmungsrecht sind zulässig.

## Konsequenzen und offene technische Entscheidungen

M1/M2 erhalten neue Akzeptanzkriterien für read-only Node-/Netzwerkstatus. M3 muss Validatorausfall und gleiche App-Hashes verifizieren. Die Monitoring-API und Datenbank, CometBFT-Version, Validator-Key-Verwahrung, Portkonfiguration, Metrikenaufbewahrung und Überwachungsberechtigungen werden vor Implementierung geprüft. Gebührenverwendung (Burn/Validator/Fonds) und Emissionsformeln werden **nicht** durch dieses ADR entschieden; bisherige Burn-Entscheidungen sind durch neuere Simulationen erneut in Diskussion.

**Referenzen:** `docs/INFRASTRUKTUR_UND_DEPLOYMENT.md`, `docs/COCKPITS_UND_MONITORING.md`, ADR 0002/0005 und aktuelle offizielle CometBFT-Dokumentation.

## Spätere Präzisierung

**ADR 0007** konkretisiert: Ein zentraler `potatium-network`-Dienst **ist** für bequemen Bootstrap, Anträge und weltweites/privates Netzwerkinventar vorgesehen. Dessen off-chain Managementdatenbank widerspricht **nicht** dem in ADR 0006 abgelehnten zentralen **Coin-/Blockchain-Master**. Hub und Validatoren synchronisieren unabhängig direkt P2P. Die Gebührenverwendung für PoP-/Worker-Gebühren ist seit ADR 0007 auf **100 % On-chain-Fonds, 0 % Burn** festgelegt.