potatium/docs/COCKPITS_UND_MONITORING.md

Potatium: Benutzer-Cockpit, Clusterübersicht und Network Admin

Produktentscheidung, noch nicht implementiert, 25.10.2026. Überall echte Quellen und klar erkennbare Fehlerzustände. Beide Anzeigeoberflächen ab der ersten lauffähigen Devnet-Phase, nicht erst ab M5/M6. Die jeweilige Funktionstiefe wächst mit der Architektur; UI ohne Node darf ausschließlich „nicht verbunden“ anzeigen.

Drei getrennte Blickwinkel, zwei Produktlinien

1. Potatium Hub (Teilnehmer): Lokale Full Node mit eigenem Web-Cockpit und integrierter browserseitiger Wallet, optionalem eigenem PoP-Mining und Verwaltung der eigenen Worker. Man kann mehrere berechtigte Hubs desselben Betreibers im Hub-Cockpit zu einer Clusteransicht aggregieren. Ein Hub bleibt ohne zentralen Cluster-Master bedienbar. Wallet-Schlüssel verbleiben clientseitig.
2. Potatium Worker (Teilnehmer): Keine vollständige Blockchain-/Wallet-GUI nötig; einfacher Pairing-/Health-/Diagnosemodus optional. Konfiguration und Status primär über den zugeordneten Hub. Worker meldet signiert, Hub und Chain validieren Ergebnisse unabhängig. Private Wallet-Schlüssel nie auf Worker.
3. Potatium Network Admin (Netzwerkbetreiber): Von Beginn an read-only und vollständig getrennt vom Benutzer-Hub. Beobachtet bestätigten Chain-State, bekannte Validatoren, registrierte Operator-/Mining-Identitäten und freiwillig angebundene Host-Metriken. Keine Freigabe-/Sperr-/Validator-Änderungs-Buttons in erster Version. Für spätere Änderungen existiert eine getrennte geschützte Admin-CLI, später möglicherweise Web-Workflow mit expliziter Signatur. Ein öffentliches „Super-Admin-Token“ ist nicht vorgesehen.

Abgrenzung der Rechte

Ansicht/Aktion	Hub (Teilnehmer)	Cluster eigener Hubs	Network Admin read-only	Späterer registrierter Admin
Blockchainhöhe, Blöcke, Transaktionen, Netzwerk	Lesen	Lesen	Lesen	Lesen
Eigene Wallet-Balance und signierte Transfers	Browser-Wallet	Nur explizit gekoppelt, keine Keys verteilen	Nein als Admin-Privileg	Nein
Eigene Worker starten/pausieren, Limits und Gebührenbudget	Ja, lokale Berechtigung	Ja, je Hub freigegeben	Nein	Nein
Eigene Node-Version, Sync, Logs, Ressourcen	Ja	Ja, nur gekoppelte Nodes	Nur publizierte/ausdrücklich freigegebene Daten	ggf. gesonderter Infrastrukturzugang
Andere Betreiber-Identitäten anzeigen	Nur zulässige öffentliche Daten	Nur zulässige öffentliche Daten	Registry-/Aggregatdaten soweit freigegeben	auditierbar
Miner/Validatoren genehmigen/sperren	Nein	Nein	Nein	erst signierte, regelkonforme Aktion
Guthaben verändern, Lose festlegen, Konsens umgehen	Niemals	Niemals	Niemals	Niemals

Früheste Anzeige: Datenquellen und Widgets

Kennwert	Quelle	Hub	Network Admin	Umgang bei fehlender Quelle
Chain-ID/Netzwerk (devnet/testnet/dauerhaft)	lokale geprüfte Nodekonfiguration/Genesis	Ja	Ja	nicht verbunden
aktuelle Blockhöhe, letzte Finalisierung	CometBFT-RPC + bestätigter App-State	Ja	Ja	Höhe unbekannt, letzte Messung mit Alter
Node-/Validator-Peers, Voting-Power, Sync	CometBFT-RPC/Metriken	eigene Node	alle beobachtbaren	keine Erfindungen, „nicht erreichbar“
App-Hash und Abweichungen	verifizierte Status-/Block-Daten	optional	besonders wichtig	Alarm ohne falsche Ursache
TPS/Blockrate, Transaktionsfehler	beobachtete bestätigte Blöcke/Node-Metriken	Netzwerk	Netzwerk	Datenlücke markieren
Supply/minted/burned/fee allocation	bestätigter Potatium-App-State	Netzwerk	Netzwerk	„nicht verfügbar“ bis implementiert
Registrierte Operator/Mining-IDs, aktive Tickets, Runden	bestätigter Potatium-App-State	zulässige Übersicht	Aggregate/Registry	fehlende Chain-Funktion markieren
Wallet Balance/Transfers	signierte Wallet-Adresse + echte Chainabfrage	nur freigeschaltete Wallet	kein privater Wallet-Zugriff	nicht verbunden statt Fake-Balance
Hub/Worker CPU/RAM/Temperatur/Status	jeweiliger freigegebener Agent/OS	eigene Geräte	nur opt-in Metriken	nicht beobachtbar
Fehler/Logs/Alerts	Node-API, dedizierter Telemetriedienst	eigene Node	freigegebene Ereignisse	Zeitstempel und Quelle anzeigen

Erste UI-Runde: Lese-Dashboard vor vollständigem Mining, per minimaler /status-Schnittstelle mit gesundem Fehlerverhalten, kein Warten bis zur Multi-Host-Phase. „Online“ bedeutet nur eine erfolgreich geprüfte Quelle, niemals implizit, dass die ganze Chain gesund ist. Chain-Daten und hostbezogene Monitoringdaten getrennt beschriften.

Architektur des Network Admin read-only

• Eigenständiger kleiner Go-Prozess/Service und statisches Browserfrontend, zunächst auf potatium-dev, später optional auf separater Management-VM. Kein Validator, keine Full Node und keine Konsensdatenbank erforderlich; verbindet sich als Client mit bereits vorhandenen geschützten Node-Statusdiensten.
• Inventar enthält Beobachtungsendpunkte und optional rollenbezogene Labels. Speicherung anfänglich kleine lokale Konfiguration, optional SQLite/Zeitreihen-DB für Graphen/Historie. Niemals zentrale Source of Truth für den Ledger.
• Status-Zugriff gegen lokale 127.0.0.1-Endpoints oder über VPN/SSH-Tunnel/geschützte Monitoring-Agenten. Keine generisch ungesicherten Public-RPC/Prometheus-Endpunkte; kein Remote-Exec/SSH-Root durch das Dashboard.
• Trennung zwischen Chain-beobachtbaren Nodes/Mining-IDs und maschinenbezogenen Kennwerten, die nur Betreiber mit Opt-in teilen. Der Admin kann nicht alle VMs einer fremden Node automatisch erkennen oder steuern.
• Kein Blockieren des Netzwerks durch Monitoring-Anfragen; Cache/Rate-Limits/Timeouts, Lese-only Konfig, keine privaten Walletdaten im Log. Statuszeitpunkte und Staleness transparent.

Sicherheits- und UX-Anforderungen

• Hub-/Wallet-Endpunkte auf 127.0.0.1, Zugriff im Entwicklungs-LXC via SSH-Forward; andere Hosts erst per explizit autorisiertem privatem Tunnel, HTTPS und Authentifizierung.
• Browser-Wallet: verschlüsselte lokale Speicherung, signierte Ausgaben ohne Seed-Exfiltration, Backup/Recovery, nicht automatisch auf andere Hub-Browser kopieren.
• Node-/Worker-Kopplung mit zeitlich begrenzter Einladung und gegenseitigem kryptografischem Besitznachweis, nicht nur Fingerprint. Getrennte Operator-/Wallet-/Mining-/Validator-Schlüssel.
• Gebührenreserve und Nutzerlimit für unbeaufsichtigte Worker-Mining-Gebühren erst nach expliziter Autorisierung; read-only Admin kann nie Gebühren abbuchen.
• Ein Hub darf mehrere Workerdatenansichten und mehrere eigene Hubs in seiner Clusteransicht zeigen, aber nicht die privaten Daten fremder Betreiber.

Akzeptanztests je Ausbaustufe

• UI vor Chain: Beide Dashboards starten/anzeigen klar „nicht verbunden“, keine Fake-Daten.
• M2 erster Devnet-Kern: echte Chain-ID, Höhe, Header/Blockstatus; Hub und Admin melden konsistente Werte; Wallet integriert echte Daten, sobald Signaturformat verfügbar.
• M3 Validatoren: 1- und 4-Validator-Szenario; Down/Restart, Peer-Status, >2/3 Quorum, AppHash, Stale-Alerts; Admin aus => Chain läuft weiter.
• M4 Worker: mehrere Mining-IDs, Worker-Pairing, Hub-/Worker-Mining, Freigaben/Budgets, Gebühren und Gewinne mit echten Chain-Daten.
• M5/M6: Multi-Hub-Cluster UX und Mehrhost-Überwachung, Monitoring-Lücken, Recovery, Sicherheitsgrenzen.

Keine Produktivitätsbehauptung: vorhandene web/wallet bleibt reine Vorschau. Noch keine Backend-Schnittstellen, GUI/DB/Chain/Minerdienste für die oben beschriebenen Funktionen implementiert.

Betreiberansichten und Identitätsverwaltung (ADR 0008)

Ab erstem funktionsfähigem Devnet: Nur für den Projektbetreiber read-only Network Admin mit tatsächlichen Chain-/Validator-/Peerwerten. Anzeige für bestätigte Coin-Emission, aktuelles Supply, kumulierten Burn (0 für PoP-/Workergebühren), Fondsbestand/-Ein-/-Ausgänge, Gebührenparameter, Betreiber-/Mining-Registrierungsstatus, Freigaben/Widerrufe, beobachtbare Peers und PoP-Runden soweit schon implementiert. Jede Kennzahl enthält Chain-ID, Blockhöhe/Messzeit, Datenquelle und Stale-/Fehlerstatus. Für fehlenden Ledger/Registry-State „nicht verfügbar“ statt Mockzahlen.

Identitätsaktionen: Anzeige und Filter von operator_id, node_id, mining_id, zugehöriger Reward-Adresse sowie Genehmigungs-, Sperr- und Auditstatus. Einzige frühen Schreibaktionen: Neue Betreiber-/Mining-IDs signiert freigeben, sperren/widerrufen (Key-Rotation später nach separater Spezifikation). Bis sichere Signatur-/Protokollfunktionen existieren: read-only, keine Scheinfreigaben. Der Admin-Webserver enthält keinen privaten Admin-Signaturschlüssel; getrennte CLI/Signaturkomponente mit 2-Stufen-Bestätigung, Replay-Schutz und On-chain-Finalisierung.

Aktive Nodes: Die globale Gerätezahl ist nicht allein aus einem lokalen Peer-Set beweisbar. registriert, kürzlich beobachtet, signiert meldend und PoP-aktiv getrennt mit Datum/Abdeckung anzeigen. Optional signierte Heartbeats über freiwilligen, geschützten Monitoring-Empfänger; SQLite-Historie optional, keine zentrale Registrierungsdatenbank-Pflicht.

Vertraulichkeit: Nur die Admin-GUI und eigene Off-chain-Telemetrie sind zugriffsbeschränkt. On-chain-Fonds, Gebühren und ggf. Registry-Informationen sind über Full Nodes prinzipiell abfragbar. Private Betreiber-Kontakte/Geräte-IP nicht auf replizierten Chain-State schreiben. ADR 0008, Netzzugang.