41 lines
2.8 KiB
Markdown
41 lines
2.8 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, 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.
|