potatium/docs/PROJEKTPLAN.md

Potatium: Projektplan v0.2

Stand: 25.10.2026. Maßgeblich sind Repositorydateien/ADRs; Änderungen durch Codex oder Git in deinem LXC haben Vorrang. Die neue PoP-Richtung ist als Prinzip akzeptiert, Zahlen sind weiter offen.

Ziel

Potatium (PTM, vor öffentlicher Nutzung Name/Ticker prüfen) ist eine eigene, kleine Hobby-Layer-1-Blockchain, kein ERC-20-Token und keine Anlageempfehlung. Geplant sind ressourcensparsame Miner auf Raspberry Pi 4/5 und älteren PCs sowie eine browserbasierte Wallet bereits im ersten funktionalen MVP. Das gewählte Logo bleibt assets/logo/potatium-ptm-logo.png (goldenes abstraktes P/Kartoffelzeichen auf Schwarz).

Entwicklungsumgebung und Git

• Proxmox unprivilegierter Ubuntu Server 26.04 LTS LXC potatium-dev (Basis 4 vCPU, 4 GB RAM, 40 GB Speicher, bei Bedarf mehr).
• Benutzer potatium, einziger Arbeitsordner /home/potatium/src/potatium. Keine Duplikate in ~/workdir.
• IDE: VS Code auf dem lokalen Rechner via Remote-SSH, OpenAI Codex, Go-Plugin; keine GUI im Container.
• Monorepo auf privatem Gitea-Remote; main plus kleine Feature-Branches, kleine nachvollziehbare Commits. Keine Zugangsdaten, Wallet-Keys oder Chain-State in Git.
• Ubuntu-Go-Skripte und Tests bereits als Gerüst vorhanden; aktuelle Remote-/Push-/Codex-Zustände vor Aussagen oder Änderungen prüfen.
• Keine PostgreSQL- oder Docker-in-LXC-Voraussetzung. Alle API-Server zunächst nur 127.0.0.1, Zugriff über SSH-Portweiterleitung.

Technisches Modell (Plan, noch nicht vollständig bestätigt)

• Go (linux/amd64, linux/arm64) für potatiumd, potatium-miner und potatium-cli.
• Konsenskandidat: CometBFT als Validator/P2P mit eigener deterministischer ABCI++-Applikation, zunächst ohne Cosmos SDK; echte Versionen prüfen. Validatoren betreiben Blockkonsens, Miner qualifizieren sich für PTM-Lotterie; Rollen getrennt.
• Eigenständiger eingebetteter konsensdeterministischer Zustand, jedes Validatorgerät speichert selbst; keine geteilte zentrale SQL-Datenbank.
• Konten/Transaktionen/Schlüssel-/Adressschema einschließlich Nonce und Wallet-Backup noch präzise zu definieren.
• Web-Wallet-MVP: Browser-Keygenerierung/-Signatur, verschlüsselter lokaler Speicher, Erstellen/Import/Export/Backup, Adresse/Balance, Senden/Empfangen, Gebühren, History/Status, Sperren/Entsperren; keine Private Keys an Backend, immer echte Chain-Daten oder „nicht verbunden“.
• Startgerüst beinhaltet nur statischen Web-Wallet-UI-Entwurf, CLI/Node/Miner sind nicht produktive Programme.

Proof of Potato: Richtungsentscheid v0.2

Neue verbindliche Produktprinzipien stehen in docs/decisions/0003-pop-fenster-und-gebuehren.md und docs/PROTOKOLL_ENTWURF.md.

Eine PoP-Runde enthält drei hintereinander liegende Aufgabenfenster mit einer neuen, pro Identität/Chain/Runde/Fenster gebundenen, begrenzten PoW-Aufgabe. Fenster 1 ist kostenlos, Fenster 2 und 3 freiwillig und solange kein gültiges Ticket vorliegt gegen vorherige bestätigte Gebühren nutzbar. Die Gebühren enthalten jeweils fixe Kosten und eine progressive Komponente. Als Maßstab dienen finalisierte PoP-Gewinne der letzten ungefähr 90 Tage pro registrierter Identität/Betreibergruppe, nicht die aktuelle Wallet-Balance; alter Erfolg fällt aus der Bemessung heraus, kein permanent fortschreitender Langzeitvorteil.

Nach dem ersten erfolgreichen Nachweis erhält diese Identität maximal ein Ticket und stoppt bis zur nächsten Runde. Lose müssen vor Bekanntwerden eines später verifizierbaren Zufallswerts unwiderruflich feststehen. Die Gebühren für Zusatzfenster und Worker werden laut ADR 0007/0008 zu 100 % in den On-chain-Fonds gebucht und nicht verbrannt; normale Transfergebühren und Validator-Finanzierung sind noch offen.

Die Schwelle, Nonce-Raum, Rundendauer, Fensterlängen, Gebührenhöhe, PTM-Emission, Coin-Maximum, Zufallsbeacon und Validatoranzahl sind weiter unentschieden. Alle genannten Zahlen aus früheren Beispielen bleiben hypothetisch. Pi-4-Benchmark, Simulation und ein neues ADR sind Pflicht vor Implementierung konsenskritischer PoP-Regeln.

Sicherheitsgrenzen

• Eine zugelassene Node-ID ist kein kryptografischer Beweis für ein physisches Gerät. Anfangs manuelle Registry; Betreibergruppen und mehrere Geräte auditiert verwalten. Verschieben von Coins soll die Gebührenbasis nicht zurücksetzen, Identitätswechsel bleiben Sybil-Angriffsfläche.
• Starke CPUs können endliche Nonce-Räume schneller durchsuchen. Gleichheit nur bei rechtzeitig vollständig bearbeiteter erlaubter Aufgabe, nicht mathematisch hardwareunabhängig.
• Keine lokalen Uhrzeit-, Betriebssystem-, Zufallsgenerator- oder Float-Operationen in der State-Machine, die zwischen Validatoren abweichen können.
• Mining-Fenster-Gebühren und Zufallsgewinne können regulatorische Pflichten auslösen. Vorerst ausschließlich private Test-PTM ohne wirtschaftlichen Wert.
• Kein automatisches Bezahlen durch den Miner mit privaten Wallet-Schlüsseln. Die Wallet autorisiert später separat, begrenzt und widerrufbar.

Entwicklungsreihenfolge

1. M1: Architektur-/Coin-/PoP-Parameter dokumentieren, Gebühren-/Fairness-Simulation, Pi-4-Benchmark, ADRs akzeptieren.
2. M2: Ledger, Accounts, deterministischer State, Signaturen, Genesis, Nonce, Tests; parallel funktionale Web-Wallet nach festgelegter Schnittstelle.
3. M3: CometBFT anbinden (1, danach 4 Validatoren), Synchronisation/Ausfalltests.
4. M4: PoP-Registry, Fenster, signierte Proofs/Fondsgebühren, Ticketcommit, nachweisbare Ziehung, Mint-/Fonds-Buchungen und Negativtests.
5. M5–M6: Pi-/Office-PC-Builds, Web-Wallet vervollständigen, private Mehrhost-Tests, Doku/Release.

Jeder Schritt: erst Akzeptanzkriterien, dann kleinste sinnvolle Implementierung, Tests inkl. gofmt, go test ./..., go vet ./..., kurze Dokumentation und Git-Review. Keinen Fortschritt erfinden.

Zukunftsperspektive nach dem privaten Testnet (neue Produktvision, kein aktueller Arbeitsauftrag)

Erst nach M6 dürfen wir getrennte Erweiterungsphasen erwägen: F1 digitale Sammlerstücke, F2 interner PTM-Marktplatz, F3 Handelsplattform für fiktive interne Assets mit PTM-Orderbuch, Kursen und Portfolio, optional F4 separat gekennzeichnetes Paper-Trading/Börsenlabor. Diese Phasen sollen PTM als geschlossene interne Währung einen zusätzlichen spielerischen Nutzwert geben, nicht einen angeblichen Fiat-Kurs oder einen Mining-Vorteil erzeugen. Keine implizite Echtgeld-Einlösung, Börsennotierung oder Renditeversprechen.

Verbindliche Projektgrenze: Kein F1–F4-Code vor funktionierender Chain, sicherer Wallet und bestandenem Mehrhost-Testnet. Eigentum/Transaktionen müssen kryptografisch überprüfbar sein, Sammlerbesitz beeinflusst die PoP-Lotterie nicht. Für Asset-Minting, sichere Marktorders, Matching, Gebühren und Rechtliches sind vor Implementierung gesonderte Entscheidungen und ADRs nötig. Details in docs/ZUKUNFT_OEKOSYSTEM.md und docs/decisions/0004-zukunftsvision-internes-oekosystem.md.

v0.4-Ergänzung: Installationspakete, Cluster und Betreiberidentität

Vereinbartes Produktmodell: Hub = eigenständige Full-Node mit eigener GUI, Browser-Wallet und optionalem PoP-Miner. Worker = schlanke Mining-Instanz, Hub-abhängig und ohne separate Geld-Wallet. Multi-Hub-/Worker-Cockpit wird priorisiert; Admin-Web erst später, Admin-CLI ab Bedarf. Wallet-/Node-/Miner-/Betreiber-Identitäten bleiben getrennt. Jeder genehmigte Hub-Miner/Worker bis zu ein Ticket/Runde; alle Gewinne/Fees werden pro operator_id zusammengefasst und an registrierte Browser-Wallet-Adresse ausgezahlt. Ein gebührenfreier Hub-Mining-Platz pro Betreiber; weitere miningfähige Hubs dürfen nicht als kostenloser Ausweg dienen.

Noch zu testen: Worker-Gebühren je Mining-Runde, Tarife, progressive Stufen vs. Pauschalstufen, maximale Worker pro Betreiber (10 nur Simulationskandidat), Fee-Reserve und Failover. Keine bestehenden PoP-Parameter oder Validatorwahl werden dadurch stillschweigend entschieden. Details: docs/HUB_WORKER_CLUSTER.md, docs/WORKER_GEBUEHREN_FORSCHUNG.md, ADR 0005.

Betriebsarchitektur und frühe Beobachtbarkeit (ADR 0006, 25.10.2026)

Wer betreibt was? potatium-dev bleibt reiner Entwicklungs-/Devnet-LXC. Potatium benötigt zusätzlich aktive CometBFT-Validatoren (1 in erster lokaler Devnet-Phase, später vier für Ausfall-/Mehrhosttests), jeweils mit eigener App-DB und eigener Chain-Datenbank, nicht aber einen zentralen Blockchain-SQL-Server. Validatoren zunächst vom Projektbetreiber, später optional von anderen genehmigten Betreibern. Teilnehmer installieren eigenständig Hub-Full-Nodes und Worker; das Wallet-Keymaterial bleibt clientseitig.

Neue verbindliche UX-Priorität: Web-Hub-Cockpit und gesondertes read-only Network-Admin-Cockpit parallel zum ersten funktionalen Devnet, mit echten Messwerten und transparentem Nichtverbunden-Zustand. Node-/Validator-Aufsicht darf keine on-chain Schreib-, Coin-, Validator- oder Wallet-Schlüssel besitzen; administrative Änderungen erst per geschützten signierten Aktionen in späterer Phase. Ohne Network Admin läuft der Konsens weiter. Monitoring-Historie/Cache kann eine kleine separate Datenbank verwenden, ist aber nicht autoritativ.

Siehe docs/INFRASTRUKTUR_UND_DEPLOYMENT.md, docs/COCKPITS_UND_MONITORING.md, docs/decisions/0006-validator-infrastruktur-und-cockpits-ab-devnet.md. Gebührenverwendung nach ADR 0007: 100 % der PoP-/Worker-Gebühren gehen an den On-chain-Fonds; Höhe/Tx-Gebühren/Fonds-Ausgaben sind weiterhin offen. ADR 0003 bleibt historisch dokumentiert und wurde durch ADR 0007 gezielt präzisiert.

Netzwerkzugang, Identity Admin und Homelab (ADR 0008)

Vereinbarte Vereinfachung: kein verpflichtender potatium-network-Service, kein Nutzer-Registrierungsportal und keine zentrale Coin-DB. Ein Hub verbindet sich mit überprüfter Chain-ID/Genesis und direkt konfigurierten CometBFT-Peers. Mining-Rechte werden über On-chain-Registry mit protokollautorisierter Freigabe/Sperre verwaltet. Ab erstem lauffähigem Devnet: eigenständiges echtes Hub-Cockpit und separates Network Admin mit bestätigten Supply-/Burn-/Fonds-/Fees-/Identitäts-/Validatorwerten. Frühe schreibende Admin-Funktionen ausschließlich signierte Freigabe/Sperre, erst sobald die Register- und Signaturprüfungen implementiert sind. Monitoring-SQL optional, keine Pflicht-Control-Plane. Fonds: 100 % PoP-/Workergebühren, kein Burn. Tarife und Fonds-Ausgaben offen.

Auswertung: docs/POP_DYNAMIK_FONDS_AUSWERTUNG_2026-10-25.md, die Modelle sind keine Konsensparameter. Infrastrukturplan: docs/INSTALLATIONSPLAN_HOMELAB.md, ADR 0008.