potatium/docs/ROADMAP.md

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

• Starterkit-Dateien mit Go- und Browser-UI-Gerüst bereitgestellt.
• 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

• 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, AB​CI++-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, ADR 0004.

• 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)

• 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.