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