docs: update Proof of Potato model to v0.2
This commit is contained in:
1 parent
e2d0be22fd
commit
7397045a54
19 files changed
+588
-813
No files matched your search
+33
-27
@@ -1,35 +1,41 @@
|
||||
# Roadmap / Definition of Done
|
||||
# Potatium-Roadmap: aktueller Plan v0.2 (25.10.2026)
|
||||
|
||||
## M0 – Übergabe & Entwicklungsgerüst (Startpaket)
|
||||
- [x] Logo, ChatGPT-Anweisungen, Protokollentwurf, Codex-AGENTS und Roadmap archiviert.
|
||||
- [x] Ubuntu-26.04-Setup-Skripte, Bootstrap, lokale UI-Vorschau und prüfbares Go-Gerüst bereitgestellt.
|
||||
- [ ] Skripte im echten LXC ausführen und tatsächliche Ergebnisse bestätigen.
|
||||
- [ ] VS Code, Codex, Git-Remote/SSH und erste Push-Verbindung herstellen.
|
||||
**Status der Umsetzung:** Starter-Scaffold vorhanden, Blockchain/PoP/Web-Wallet noch **nicht** funktionsfähig. Lokale `doctor.sh`-Prüfung auf dem Benutzer-LXC wurde am 24.10.2026 berichtet; aktuelle Git-Commits und Änderungen aus Codex hier nicht einsehbar. Haken nur bei nachgewiesenen Ergebnissen setzen.
|
||||
|
||||
## M1 – Architektur & Protokollentscheidungen
|
||||
- [ ] Offene P-01 bis P-14 priorisiert; erste ADRs über Accountmodell, Kryptosuite, Coin-Einheiten, Genesis, Block-/Rundenzeiten, PoP/RNG.
|
||||
- [ ] Typspezifikationen und Testvektoren dokumentiert, Verantwortungsgrenzen fixiert.
|
||||
## M0: Repo + Umgebung
|
||||
|
||||
## M2 – Ledger/Accounts + erste funktionale Web-Wallet
|
||||
- [ ] Genesis, deterministischer Chain-State, Transaktionen, Signaturen, Nonce, Mint-Check, Wiederanlauf.
|
||||
- [ ] Sichere Wallet im Browser erstellen/importieren/sichern/entsperren, echtes Guthaben, signierte Zahlung, echte Historie.
|
||||
- [ ] Browser-/Backendsicherheits- und Signaturtests, keine Seeds an Backend.
|
||||
- [x] Starterkit-Dateien mit Go- und Browser-UI-Gerüst bereitgestellt.
|
||||
- [x] Ubuntu 26.04.1, Go 1.27.3, Bootstrap/Doctor mit erfolgreichen `go test`/`go vet`/`gofmt`-Prüfungen laut Nutzerkonsole bestätigt.
|
||||
- [ ] Git-Remote, Push und VS-Code/Codex-Verbindung am tatsächlichen Repo-Stand prüfen (nicht blind als abgeschlossen markieren).
|
||||
|
||||
## M3 – Validator-Netz
|
||||
- [ ] ABCI++/CometBFT-Anbindung, ein Validator, danach 4 Nodes.
|
||||
- [ ] Zustandskonsistenz, Neustart, Verlust von Verbindungen, Synchronisation nachgewiesen.
|
||||
## M1: Konsens- und Coin-Regeln **zuerst**
|
||||
|
||||
## M4 – Proof of Potato
|
||||
- [ ] Registrierung, signierte Herausforderung, leichte Hash-Aufgabe, Ticketlimit, Rundenabschluss, verifizierte Auslosung, Emission.
|
||||
- [ ] Negativtests zu Mehrfachlosen, Manipulation, Verzögerung, Timeout, Beacon-Ausfall und Emissionsobergrenze.
|
||||
- [ ] Messungen am Raspberry Pi 4 und Intel-Alt-PC: Zeit/CPU/RAM/Strom, sinnvolle Qualifikation.
|
||||
- [x] Produktprinzip für **3 Mining-Fenster**, kostenloses Fenster 1, optionale fixe + progressive Zusatzgebühren für Fenster 2/3, 90-Tage-Mininggewinn als Basis, Burn, max. 1 Ticket dokumentiert (`ADR 0003`).
|
||||
- [ ] Tokenomics mit Coinsupply, Genesis, Belohnung, Basis-Einheiten, Gebührensystem, Signatur-/Adressschema entscheiden.
|
||||
- [ ] PoP-Runden/Fenster/Schwierigkeit/Nonce-Räume und Zahlungs-/Finalitätsbedingungen spezifizieren.
|
||||
- [ ] Rein analytische, ausdrücklich nicht konsenskritische Simulation (5/10/20/50 Miner), Fairness- und Kostenvergleich.
|
||||
- [ ] Raspberry-Pi-4-Leistungsmessung, Gebühren- und Protokollparameter in weiterem ADR konkret akzeptieren.
|
||||
- [ ] CometBFT/ABCI++-Versionen, deterministische State Machine und Datenbank verbindlich prüfen.
|
||||
|
||||
## M5 – Bedienung und Auslieferung
|
||||
- [ ] Web-Wallet und Mining-/Chain-Status aufgeräumt; CLI; verständliche Fehler und Backups.
|
||||
- [ ] Binaries linux/amd64 und linux/arm64; reproduzierbarer Build und CI; erste private Releases.
|
||||
## M2: Ledger + frühzeitig echte Web-Wallet
|
||||
|
||||
## M6 – Privates Mehrhost-Testnet
|
||||
- [ ] Separate Hosts, Netzunterbrechungen, Wiederherstellung, Schlüsselrotation, Dokumentation und Monitoring.
|
||||
- [ ] Explizite Bewertung der Grenzen zentraler Registrierung und kleiner Validatoranzahl.
|
||||
- [ ] Key-/Account-/Tx-Format, Nonce, Replay-/Double-Spend-Schutz, Genesis, persistenter Zustand und deterministische Tests.
|
||||
- [ ] Browserseitige sichere Wallet-Erstellung, Import/Backup, Verschlüsselung, Sperren, Senden/Empfangen, tatsächliche Guthaben, History.
|
||||
- [ ] Fee-Preview und später sichere, begrenzte Freigabe für Zusatzfenster planen; Miner bekommt keinen privaten Wallet-Schlüssel.
|
||||
|
||||
**Gate:** Keine Phase als abgeschlossen markieren, ohne tatsächliche Tests. Dieses Paket erfüllt nur die Bereitstellung des Startgerüsts, nicht die Ausführung im Nutzer-LXC.
|
||||
## M3: Validatorennetz
|
||||
|
||||
- [ ] 1, später 4 CometBFT-Validatoren, ABCI++-Integration; echte Blocksynchronisation, Neustarts und Ausfalltests.
|
||||
|
||||
## M4: Proof of Potato
|
||||
|
||||
- [ ] Registry/Betreibergruppen-Audit, Challenge je Fenster, Gebühren-Snapshot, Proof-Verifikation, gebührenpflichtige Freischaltung, Ticketcommit, Zufallsbeweis, Gewinner-Auszahlung.
|
||||
- [ ] Negative Tests für Mehrfachlose, Proof-Replay, Fee-Replay, Identitätswechsel, State-Divergenz, Beacon-Ausfall, Reorgs, Zensur, Rundenwechsel und Überläufe.
|
||||
- [ ] Pi-4/Office-PC-Benchmarks unter CPU-/Speicher-/Netzwerklast.
|
||||
|
||||
## M5–M6: Bedienung und privates Mehrhost-Testnet
|
||||
|
||||
- [ ] UX, Explorer/Status, Dokumentation, Linux amd64/arm64-Releases, Sicherung/Recovery.
|
||||
- [ ] Hosts über mehrere Geräte, Restart/Fault-Tests, Monitoring und Warnungen zur verbleibenden zentralen Registrierung.
|
||||
|
||||
**Keine Implementierungs- oder Testergebnisse behaupten, die nicht tatsächlich ausgeführt wurden.**
|
||||
Reference in new issue
Block a user