75 lines
9.5 KiB
Markdown
75 lines
9.5 KiB
Markdown
# 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](decisions/0008-schlanker-netzzugang-admin-und-identitaeten.md), [Netzzugang](NETWORK_ZUGANG_UND_IDENTITAETEN.md).
|