docs: update Proof of Potato model to v0.2
This commit is contained in:
Michael Böhmländer committed
1 parent
e2d0be22fd
commit
7397045a54
19 files changed
+588
-813
No files matched your search
+31
-43
@@ -1,52 +1,40 @@
|
||||
# Architekturentwurf
|
||||
# Architekturentwurf v0.2
|
||||
|
||||
**Nur Zielarchitektur, nicht laufende Blockchain.**
|
||||
|
||||
```text
|
||||
Lokaler Browser Raspberry Pi / Office-PC
|
||||
Web-Wallet (Keys clientseitig) potatium-miner
|
||||
| |
|
||||
+--------- signierte API Calls --------+
|
||||
|
|
||||
potatiumd API/RPC
|
||||
|
|
||||
+------------------------+--------------------+
|
||||
| Potatium Core (Go) |
|
||||
| Transaktionen, Ledger, PoP-Registry, |
|
||||
| Tickets, Ziehung, Emission, State |
|
||||
+------------------------+--------------------+
|
||||
| ABCI++
|
||||
CometBFT Validator
|
||||
| P2P
|
||||
weitere Validatoren (zunächst 4)
|
||||
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
|
||||
```
|
||||
|
||||
Diese Skizze ist eine **Zielarchitektur**, nicht bereits implementiert.
|
||||
## Verantwortlichkeiten
|
||||
|
||||
## Prozess- und Verantwortungsgrenzen
|
||||
- **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.
|
||||
|
||||
- Konsens/Blockreihenfolge: CometBFT (vorläufig ausgewählt). Validierungsregeln: Potatium Core.
|
||||
- Mining: leichte Hash-Aufgabe sichert **Teilnahmeberechtigung**, nicht die Validator-Konsensmehrheit. Die Mining-Lotterie darf nicht rückwirkend die Blockreihenfolge wählen.
|
||||
- Persistenz: jeder Validator speichert seine **eigene** Blockchain und seinen Zustand, kein gemeinsamer Postgres-Server.
|
||||
- API: nur überprüfte öffentliche Daten herausgeben, Eingaben strikt validieren. Localhost-Default und später explizite Netzfreigabe/TLS.
|
||||
- Browser: Private Keys und Seeds nie als Plaintext via API übertragen. Der Server sieht nur signierte Transaktionen.
|
||||
## Verifikationskette
|
||||
|
||||
## Netzwerk & Reihenfolge
|
||||
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.
|
||||
|
||||
1. Wallet signiert Transaktion -> Node prüft grundlegende Eigenschaften -> Mempool.
|
||||
2. Validatoren legen Block fest -> Core wendet deterministische Änderungen an -> Zustand committen.
|
||||
3. Registrierter Miner löst auf eine eindeutige Runde gebundenes Hash-Rätsel -> Ticket wird nach Konsens final akzeptiert.
|
||||
4. Nach verbindlichem Rundenabschluss und später verifizierbarem Zufallswert wird Gewinner ermittelt und Minting über konsensvalidierten Zustandsübergang verbucht.
|
||||
## Kritische Unbekannte
|
||||
|
||||
**Offen:** keine `wall-clock`-Zufallszahlen im konsenskritischen Code; Runden-/Endzeit soll auf Height/Finalität oder präzise finalisierten Zeitregeln basieren. Verzögerungen, Beacon-Ausfälle und Transaktionszensur explizit prüfen.
|
||||
|
||||
## Repositorystruktur
|
||||
|
||||
`cmd/` Programme, `internal/chain` Ledger, `internal/transaction` Formate, `internal/crypto` Schlüssel-/Signaturverifikation, `internal/mining` Proof, `internal/lottery` Ziehung, `internal/registry` Identitäten, `internal/consensus` ABCI, `internal/storage` Persistenz, `internal/api` RPC, `web/wallet` UI, `tests/integration` End-to-End, `deploy` spätere Systemkonfiguration, `docs/decisions` ADRs.
|
||||
|
||||
## Bedrohungsmodell (für Designreviews)
|
||||
|
||||
- Erfundene Identitäten / ein PC mit vielen VMs; manuelle Registrierung schützt nur gegen unbefugte Teilnehmer.
|
||||
- Schneller Miner gewinnt vor Fristende eine bessere Qualifikationschance.
|
||||
- RNG/Beacon-Last-Look, Vorabkenntnis, Validator-Zensur, Ausfall oder Verzögerung.
|
||||
- Replay/Double-Spend/Überlauf; State-Divergenz durch nichtdeterministische Go-Maps oder Uhrzeiten.
|
||||
- Verlust / Exfiltration von Browser-Wallet-Schlüsseln; Backups, Browser-Extensions, XSS.
|
||||
- Kleiner Validator-Kreis und zentrale Registry: begrenzte Dezentralität, bewusst für ein Hobby-Testnet.
|
||||
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.
|
||||
Reference in new issue
Block a user