docs: update Potatium v0.6 architecture and PoP research

docs/ARCHITEKTUR.md

@@ -10,7 +10,7 @@ Web-Wallet (clientseitige Schlüssel)           Raspberry Pi / alter PC
                       potatiumd RPC/API (lokal)
                                    |
            deterministic Go State Machine: Konten, Nonces,
-           PoP-Runden/Fenster, Gebühren, Burn, Tickets, Ziehung
+           PoP-Runden/Fenster, Fonds-Gebühren, Tickets, Ziehung
                                    |
                      eigene CometBFT ABCI++ App
                                    |
@@ -24,13 +24,13 @@ Web-Wallet (clientseitige Schlüssel)           Raspberry Pi / alter PC
 - **Validatoren:** CometBFT legt Blöcke und Reihenfolge fest; die Go-State-Machine lehnt ungültige Transfers, Burn, Proofs und Mint ab. Kein Coin-/Mining-Bezug zur Validator-Blockerzeugung.
 - **Miner:** separates Go-Programm für Linux amd64/arm64, ressourcenschonende Arbeit, Node-ID-Signatur, bis drei Fenster pro **einer** Runde, höchstens ein gültiges Ticket. Kann rein kostenlos betrieben werden.
 - **Wallet:** browserlokale Schlüssel-/Backupverwaltung und Signatur, kein Key-Export an Backend. Bezahlte Zusatzfenster nur nach enger runden-/fenster-/betrags-/noncegebundener Autorisierung, niemals pauschale Miner-Keyfreigabe.
-- **State:** jeder Validator hält eigenen deterministischen Ledger inklusive Fensterzustand, signierter Proofs, Mining-Gewinnhistorie der letzten ca. 90 Tage, Betreiberzuordnung, Gebühren/Burn und Ticketlisten-Commit. Der 90-Tage-Begriff benötigt deterministische finale Fensterdefinition (Blockzeit versus Blockhöhe).
+- **State:** jeder Validator hält eigenen deterministischen Ledger inklusive Fensterzustand, signierter Proofs, Mining-Gewinnhistorie der letzten ca. 90 Tage, Betreiberzuordnung, Gebühren/Fonds und Ticketlisten-Commit. Der 90-Tage-Begriff benötigt deterministische finale Fensterdefinition (Blockzeit versus Blockhöhe).
 - **Transport:** localhost-only für Entwicklungs-RPC, SSH-Forwarding, sichere später explizit freigeschaltete P2P-Verbindungen.
 
 ## Verifikationskette
 
 1. Runde/Fenster mit finalisiertem Startzustand und identitätsgebundener Challenge.
-2. Fenster 1 ohne Zahlung; Fenster 2/3 nur nach bestätigter, integergenau berechneter fixer plus progressiver Burn-Gebühr.
+2. Fenster 1 ohne Zahlung; Fenster 2/3 nur nach bestätigter, integergenau berechneter fixer plus progressiver Gebühr an den On-chain-Fonds (ADR 0007).
 3. Fristgerechter Proof mit Hash und erlaubter Nonce; max. ein Ticket pro Mining-ID pro Gesamtrunde.
 4. Tickets endgültig festschreiben, anschließend fremden unbekannten verifizierbaren Beacon-Wert erhalten und Winner/Mint deterministisch berechnen.
 5. Gegen Identitätswechsel, Replay, Zensur, RNG-Manipulation, fehlende Tickets, Down-/Restart und Differenzen zwischen Validatoren testen.
@@ -38,3 +38,21 @@ Web-Wallet (clientseitige Schlüssel)           Raspberry Pi / alter PC
 ## Kritische Unbekannte
 
 Coin-Einheit, Adress-/Tx-/Signaturformat, Fee-Formel und Rundung, Fenstertiming, Staking/Validator-Gebührenanteile, PI-Benchmark, RNG-Quelle/Fallback, Registry-Gruppierung und persistente Datenbank bleiben offen. Dafür ADRs; keine willkürlichen Defaults.
+
+## Erweiterung: Hub, Worker und Betreibergruppe (ADR 0005)
+
+Die bisherige Darstellung „Node und Miner“ wird als **Rollen und Prozessgrenzen** präzisiert. Ein eigenständiger **Hub** ist eine vollwertige Node mit Web-Cockpit, Browser-Wallet und optionalem lokalen Miner. Ein **Worker** ist ein an den Hub gekoppelte Lightweight-Miner ohne Ledger und ohne Geld-Wallet. Jeder registrierte Mining-Prozess erhält eigene `mining_id` und signiert Nachweise. Ein physischer Rechner kann mehrere isolierte Prozesse, Ports und Datapaths ausführen, aber zusätzliche Mining-IDs müssen in der Registry erlaubt sein.
+
+Ein `operator_id` gruppiert Hub/Worker, zugelassene Mining-IDs, jüngste Mining-Belohnungen und Kosten unabhängig von Wallet-Transfers. **Ein** kostenloser Hub-Mining-Platz pro Betreiber; sonstige Mining-IDs (auch extra Hubs) sind wirtschaftlich zusätzliche Worker. Wallet-Seed nur im Browser; UI/Cluster-Verwaltung ersetzt keine Besitzer-/Wallet-Signatur. Hub-Worker-Verbindung authentifizieren, kein reines Fingerprint-Trust. Selbstständige Validatoren bleiben von Worker/PoP getrennt.
+
+Details und Bedrohungsmodell: `docs/HUB_WORKER_CLUSTER.md`, `docs/WORKER_GEBUEHREN_FORSCHUNG.md`, `docs/decisions/0005-hub-worker-cluster-und-betreiber.md`. Keine bestätigte Datenbank-/CometBFT-Version oder Implementierung.
+
+## Präzisierung v0.5: Validatoren, Admin und Datenbanken
+
+Die obige Grafik ist nur eine reduzierte Zielskizze. Die vollständige Deployment-Architektur steht in `docs/INFRASTRUKTUR_UND_DEPLOYMENT.md` und ADR 0006. Jede CometBFT-Full-Node hält lokal ihren CometBFT- und Go-App-State; **ein Hub ist nicht zwangsläufig Validator**. Ohne aktive Validator-Stimmmacht keine Finalisierung. Potatium-Worker halten keine Blockchain-/Wallet-Spend-Keys. Es gibt keinen globalen Master-Ledger in einer zentralen Datenbank.
+
+Ein dedizierter **read-only Network Admin** gehört schon zum ersten lauffähigen Devnet, als reiner Beobachtungsdienst ohne Konsens-, Wallet- oder Registry-Schreibrechte. Monitoring-DB optional und nicht konsenskritisch. Das lokale Hub-Web-Cockpit zeigt ebenfalls schon früh echten Chainstatus. Die vollständigen Verwaltungsrechte bleiben getrennt und folgen signierten Konsensaktionen. Siehe `docs/COCKPITS_UND_MONITORING.md`. Gebührenverwendung wird separat evaluiert, nicht durch diesen Architekturhinweis geändert.
+
+## Aktuelle Vereinfachung durch ADR 0008: Keine Pflicht-Control-Plane
+
+Der separate Dienst `potatium-network` als obligatorisches Registrierungs-/Bootstrap-Portal ist **aufgehoben**. Ein Hub synchronisiert anhand verifizierter lokaler Genesis-/Chain-ID-/Peer-Konfiguration selbst per CometBFT P2P. Mining-Rechte werden ausschließlich über die signierte On-chain-Betreiber-/Mining-Registry vergeben. Nur der Projektbetreiber erhält das separate, ab Devnet lesende Network Admin mit Supply-/Burn-/Fonds-/Validator-/Identitätsstatus; Freigabe und Sperre sind später gezielt signierte Schreibaktionen. Optionales Telemetrie-Backend darf keinen Konsens-/Mining-Pfad blockieren. 100 % PoP-/Worker-Gebühren gehen weiterhin in den On-chain-Fonds, 0 % Burn. Siehe ADR 0008, `docs/NETWORK_ZUGANG_UND_IDENTITAETEN.md` und `docs/INSTALLATIONSPLAN_HOMELAB.md`.