88 lines
9.3 KiB
Markdown
88 lines
9.3 KiB
Markdown
# Potatium-Roadmap: Kernphasen M0–M6 und Zukunftsvision (25.10.2026)
|
||
|
||
**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.
|
||
|
||
## M0: Repo + Umgebung
|
||
|
||
- [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).
|
||
|
||
## M1: Konsens- und Coin-Regeln **zuerst**
|
||
|
||
- [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 und max. 1 Ticket dokumentiert; **Gebührenverwendung durch ADR 0007 auf 100 % Fonds statt Burn geändert** (`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.
|
||
|
||
## M2: Ledger + frühzeitig echte Web-Wallet
|
||
|
||
- [ ] 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.
|
||
|
||
## 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 Ausfallprüfungen des optionalen Admin-Dienstes.
|
||
|
||
## F1–F4: Zukunftsvision, erst nach stabilem M6
|
||
|
||
Die folgenden Erweiterungen sind **als spätere Produktideen aufgenommen**, aber weder terminiert noch implementiert. Sie verändern keine geltenden PoP-/Ledger-Regeln. Details und offene Entscheidungen: [`ZUKUNFT_OEKOSYSTEM.md`](ZUKUNFT_OEKOSYSTEM.md), [`ADR 0004`](decisions/0004-zukunftsvision-internes-oekosystem.md).
|
||
|
||
- [ ] **F1 · Sammlerstücke:** Einzigartige/limitierte interne Kartoffel-Objekte, verifizierbares Eigentum, Ausstellungs- und Transferregeln, Wallet-Galerie. Keine Mining-Vorteile.
|
||
- [ ] **F2 · PTM-Marktplatz:** Angebote/Käufe/Verkäufe digitaler Sammlerstücke in PTM, sichere atomare Abwicklung, Gebühren/History, Schutz vor manipulierten Angeboten.
|
||
- [ ] **F3 · Interne Asset-Börse:** Handel fiktiver interner Assets gegen PTM mit Orderbuch, PTM-Kursen, Kursverläufen, Volumen und Portfolio; keinerlei Euro-/Krypto-Umtauschpflicht und keine erfundenen Marktdaten.
|
||
- [ ] **F4 · Börsenlabor:** Optionales Paper-Trading mit klar getrennten Testbeständen und als Simulation gekennzeichneten Kursen.
|
||
|
||
**Abhängigkeit:** erst funktionsfähige Chain, sichere Web-Wallet, PoP, Mehrhost-Testnet und verifizierte Transaktionssignaturen. Vor jedem F-Schritt: neues ADR, Datenmodell, Sicherheits-/Risikobewertung und eigene Akzeptanztests. Kein Börsenlisting, keine Wert-/Gewinngarantie.
|
||
|
||
**Keine Implementierungs- oder Testergebnisse behaupten, die nicht tatsächlich ausgeführt wurden.**
|
||
|
||
## Ergänzende Arbeitspakete: Hub/Worker und Cluster (ADR 0005)
|
||
|
||
- [ ] **M1:** `operator_id`, Hub-/Worker-/Mining-Identitäten, Zweckreserve, Gebühren-Snapshot, 1 freier Hub-Mining-Platz/Operator und Mehridentitätsrisiken präzise spezifizieren; Worker-Preise/Obergrenze simulieren; Pi-4-Benchmark.
|
||
- [ ] **M2:** Vollständiger eigenständiger Hub inklusive **echter browserseitiger Wallet** und lokalem Status-Cockpit (keine serverseitigen Wallet-Keys), Devnet/Test-PTM.
|
||
- [ ] **M3:** Full-/Validator-Node-Status und sichere API, 1 dann 4 Validatoren. Worker sind keine Validatoren.
|
||
- [ ] **M4:** Hub-eigener PoP-Miner; Hub-gebundene Worker mit eindeutiger Registrierung, widerrufbarer Pairing-Autorisierung, Pre-Paid-Gebührenfreigabe, fristgerechten Proofs und 1 Ticket/ID/Runde.
|
||
- [ ] **M5:** Multi-Node-/Cluster-Ansicht für eigene Hubs/Worker, native amd64/arm64-Releases; optional später Docker, nicht im Entwicklungs-LXC.
|
||
- [ ] **M6:** Betreiber-/Worker-Recovery, Ausfall/Failover, Mehrhost, Registry-Audit und Admin-CLI/Web nach tatsächlichem Bedarf. Kein öffentlicher Adminzugang.
|
||
|
||
**Status:** Planung, nichts davon als implementiert markieren. Phase F1–F4 bleibt unverändert nach stabilem Testnet.
|
||
|
||
## Prioritätsanpassung v0.5: Infrastruktur und echte Cockpits ab Devnet (ADR 0006)
|
||
|
||
**Diese Aufgaben konkretisieren und priorisieren die Phasen M0–M6; sie ändern keine Emissions-, Mining- oder Gebührenwerte.**
|
||
|
||
- [ ] **M0/M1:** Systemrollen und klare Datenverantwortung dokumentieren, Protokoll von zentraler Admin/DB-Abhängigkeit freihalten. Read-only Network Admin und Teilnehmer-Hub-GUI als feste frühzeitige Lieferbestandteile festhalten. Bei Gerüstbetrieb ausschließlich „nicht verbunden“, keine simulierte Live-Chain.
|
||
- [ ] **M2, erstes lauffähiges Devnet:** Ein realer Validator/Go-App-Kern, eigenständiger synchronisierender Hub, Web-Wallet sobald sichere Transaktionsschnittstelle definiert, **lokales Hub-Status-Cockpit und separater read-only Network Admin** für Chain-ID, Blockhöhe, letzte Bestätigung, Sync/Fehleranzeige. Noch nicht implementiert.
|
||
- [ ] **M3:** Vier getrennte Validatoren und Netzwerkstatus in beiden Cockpits, AppHash-/Quorum-Überwachung, Restart-/Mehrprozess-Tests. Einheitliche echte Datenquellen und Stale/Offline-Erkennung.
|
||
- [ ] **M4:** Operator-/Mining-Registry, PoP, Gebührenreserve/Worker, Hub-Mining, sichere Pairing- und Fee-Freigabe, Monitoring aller echten Runden und Worker. Schreibende Admin-CLI nur mit Autorisierung.
|
||
- [ ] **M5/M6:** Multi-Hub-Clusteransicht und Mehrhost-Monitoring/Alerting vervollständigen, optionale Admin-Web-Schreibfunktionen *erst danach* nach Rechteprüfung. Native VM/Pi zuerst, Docker optional später. Sicherheits-, Backup-/Recovery-Tests.
|
||
|
||
Spezifikation: `docs/INFRASTRUKTUR_UND_DEPLOYMENT.md`, `docs/COCKPITS_UND_MONITORING.md`, ADR 0006. In der ursprünglichen M5-Phase ist der **Ausbau** von Status/Explorer gemeint, nicht erst der Start der Cockpits.
|
||
|
||
## Prioritätsanpassung v0.6: Vereinfachter Netzzugang, Identity Admin und Forschung (ADR 0008)
|
||
|
||
- [x] **M1 Forschung:** 36 Szenarien (1×/3×/5× Workergebühren, fix/dynamisch, Fonds halten/hypothetisch rückverteilen) in `docs/POP_DYNAMIK_FONDS_AUSWERTUNG_2026-10-25.md` dokumentiert. **Kein** Ergebnis als verbindliche Coin-/Gebührenregel kodiert.
|
||
- [ ] **M1:** On-chain-Identitäts-/Zulassungs- und Widerrufsmodell, Operator-/Node-/Mining-/Wallet-Schlüsseltrennung, Gebührenreserve und Fonds-Übertragungen in Integer-Basiseinheiten definieren. Bootstrap über überprüfbare lokale Chain-ID/Genesis/Peer-Liste, keine zentrale Benutzer-Registrierung.
|
||
- [ ] **M2:** Ein Validator mit Go-App, eigenständig synchronisierender Hub, funktionsfähige Web-Wallet und **read-only Network Admin ab dem ersten lauffähigen Devnet** mit echten Chain-/Validatorwerten und ehrlichem `nicht verfügbar` für künftige Statistiken. Alle Dienste initial gemeinsam auf `potatium-dev` in getrennten Prozessen möglich.
|
||
- [ ] **M3:** Vier separat konfigurierte Validatoren, AppHash-Tests, physische Hosttrennung später; Admin zeigt Peers/Quorum/Status.
|
||
- [ ] **M4:** On-chain-Operator-/Mining-Registry, manuell genehmigte signierte **Freigabe-/Sperraktionen im Admin** (getrennte Schlüssel/Signatur), Worker-Pairing, PoP und deterministische Fondsbuchung. Kein Backdoor-Guthaben, keine zentrale SQL-Freigabe.
|
||
- [ ] **M5/M6:** Native ARM64/AMD64-Distribution, Multi-Hub-Cluster, reale Pi-/Alt-PC-Mining-Last, optional geschützter `ptm-admin`-LXC und Heartbeat-Historie. Bootstrap-Fallback und Admin-Ausfall ohne Konsensabbruch testen.
|
||
- [ ] **M1 vor Tariffestlegung:** Pi-4-Hashmessungen, mindestens 10 Seeds und heterogene Betreiber-/Sybil-Szenarien, Definition zulässiger Fonds-Ausgaben. Erst danach neues Gebühren-/Emission-ADR.
|
||
|
||
Die frühere Pflicht-`potatium-network`-Registrierung nach ADR 0007 ist **durch ADR 0008 aufgehoben**. 100 % PoP-Fenster-/Workergebühren für den On-chain-Fonds bleiben beschlossen, 0 % Burn dieser Gebühren. Alle WebGUI-/Ledger-/Admin-Funktionen sind weiterhin **nicht implementiert**.
|