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