potatium/docs/ARCHITEKTUR.md

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, Gebühren, Burn, 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/Burn 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.
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.