59 lines
6.0 KiB
Markdown
59 lines
6.0 KiB
Markdown
# 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 <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
|
|
|
|
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`.
|