Architekturentwurf v0.2

Nur Zielarchitektur, nicht laufende Blockchain.

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 <P2P> 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

Runde/Fenster mit finalisiertem Startzustand und identitätsgebundener Challenge.
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).
Fristgerechter Proof mit Hash und erlaubter Nonce; max. ein Ticket pro Mining-ID pro Gesamtrunde.
Tickets endgültig festschreiben, anschließend fremden unbekannten verifizierbaren Beacon-Wert erhalten und Winner/Mint deterministisch berechnen.
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.

6.0 KiB Raw Permalink Blame History