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 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

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.
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.
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.
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.
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.
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.
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.

5.1 KiB Raw Permalink Blame History