# Architekturentwurf v0.2 **Nur Zielarchitektur, nicht laufende Blockchain.** ```text Web-Wallet (clientseitige Schlüssel) Raspberry Pi / alter PC | potatium-miner signierte Transaktionen / beschränkte Fee-Autorisierung | | potatiumd RPC/API (lokal) | deterministic Go State Machine: Konten, Nonces, PoP-Runden/Fenster, Fonds-Gebühren, Tickets, Ziehung | eigene CometBFT ABCI++ App | CometBFT Validator weitere Validatoren | eigener persistenter State ``` ## Verantwortlichkeiten - **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/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 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. ## 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`.