112 lines
13 KiB
Markdown
112 lines
13 KiB
Markdown
# Potatium: Gesamthandbuch (aktueller Stand v0.2)
|
||
|
||
*Stand: 25.10.2026. Dieses Dokument ersetzt die frühere v0.1-Beschreibung; es dokumentiert den abgestimmten Produktentwurf, **keine** fertig implementierte Kryptowährung.*
|
||
|
||
## 1. Ziel und Identität
|
||
|
||
**Potatium (PTM)** ist eine eigenständige Hobby-Layer-1-Blockchain. Das Symbol ist das gewählte abstrakte goldene P/Kartoffellogo auf schwarzem Grund: `assets/logo/potatium-ptm-logo.png`. Der Mining-Arbeitstitel lautet **Proof of Potato (PoP)**. Raspberry Pi 4 und alte Büro-PCs sollen mit kleinen echten kryptografischen Aufgaben teilnehmen können, ohne GPU-/ASIC-Wettrüsten. Es gibt keine Absicht zu ICO, Börsenlisting oder Renditeversprechen. Nur wertlose private Test-PTM verwenden, bis Sicherheit und rechtliche Fragen geklärt sind.
|
||
|
||
## 2. Entwicklungsstand und Umgebung
|
||
|
||
- Fertig ist das **Projektgerüst** mit Go-Paketen, `doctor.sh`, lokaler statischer Wallet-Vorschau und Documentation; **keine** echte Blockchain, Wallet-Funktion, Miner-/Validatorlogik.
|
||
- Nutzer meldete erfolgreichen `scripts/bootstrap_workdir.sh`/`scripts/doctor.sh` unter Ubuntu 26.04.1, Go 1.27.3, Git 2.53.0 mit `go test ./...`, `go vet ./...` und Syntaxprüfung. Zustand des tatsächlichen Gitea-Repos/Codex-Fortschritts muss vor Änderungen eingesehen werden.
|
||
- Infrastruktur: unprivilegierter Proxmox-Ubuntu-26.04-LTS-LXC `potatium-dev`, 4 vCPU, 4 GB RAM, 40 GB Disk initial. Benutzer `potatium`, **verbindlicher Workdir `/home/potatium/src/potatium`**.
|
||
- IDE: VS Code lokal über Remote-SSH + Go/Codex. Git-Monorepo (privates Gitea), keine IDE/kein Docker-in-LXC erforderlich.
|
||
|
||
## 3. Zielarchitektur
|
||
|
||
```text
|
||
Browser Web-Wallet (lokales Signing, nur signierte Tx an API)
|
||
| Raspberry Pi/Alt-PC
|
||
Potatium RPC/API <-------------- potatium-miner
|
||
|
|
||
Go State Machine: Accounts, Transfers, PoP, Mint/Burn, Gebühren
|
||
|
|
||
ABCI++ Anwendung (eigene Go-Implementierung)
|
||
|
|
||
CometBFT Validator / P2P Netzwerk
|
||
|
|
||
weitere Validatoren mit je eigener Datenbank
|
||
```
|
||
|
||
**CometBFT + ABCI++ ohne Cosmos SDK** ist eine bewusst gewählte Startpräferenz, noch gegen aktuelle APIs zu verifizieren. PoP-Miner erzeugen keine CometBFT-Blöcke. Weitere Programme: `potatiumd` (Node), `potatium-miner` (eigener Miner), `potatium-cli` (CLI), `web/wallet` (Web-GUI). Erst ein lokales Testnet, dann ein privates Mehrhost-Testnet; keine öffentlichen API-Ports.
|
||
|
||
## 4. PoP v0.2: Prinzip wurde abgestimmt
|
||
|
||
**Eine Mining-Runde ist nicht ein Blockchain-Block.** Sie enthält **drei hintereinander freigegebene Fenster**. Die genaue Block-/Zeitplanung ist noch offen. Erst zum Fensterstart wird die zugehörige Rechen-Challenge nutzbar; Belege sind an Chain-ID, Fenster, Runde und Miner-ID gebunden.
|
||
|
||
- **Fenster 1:** Jeder zugelassene Miner darf kostenlos eine kurze, wirklich zu lösende PoW-Aufgabe mit endlichem zulässigen Nonce-Raum bearbeiten.
|
||
- **Fenster 2:** Wenn der Miner noch keinen Proof gefunden hat, darf er nach bestätigter Zahlung **fix + progressiv** eine neue unabhängige Herausforderung bearbeiten.
|
||
- **Fenster 3:** Ohne bisheriges Ticket und nach Freischaltung von Fenster 2 kann er für höhere fixe und progressive Kosten eine dritte neue Aufgabe bearbeiten.
|
||
- **Ein Ticket pro freigegebener Mining-Identität je Runde maximal.** Nach einem erfolgreichen Proof ist Schluss; weitere Zahlungen/Hochleistung bringen kein weiteres Ticket. Keine Garantie auf ein Ticket nach drei Versuchen.
|
||
- **Spätere Ziehung:** Die akzeptierte Ticketmenge wird zuerst bindend festgeschrieben; nach Kenntnis einer späteren überprüfbaren Zufallsquelle (drand als Kandidat) bestimmt jeder Validator denselben Gewinner und nur der regelkonforme Mint ist erlaubt.
|
||
|
||
### Erfolgschancen (bloßes Rechenbeispiel)
|
||
|
||
Bei völlig unabhängigen vollständigen Fenstern mit je `p = 70 %` auf einen gültigen Hash beträgt `P(mindestens ein Erfolg)` nach 1/2/3 Fenstern 70 / 91 / 97,3 %. Der Mehrwert nimmt ab (+21 bzw. +6,3 Prozentpunkte). Dies ist **nicht** die finale Gewinnauslosung und **kein beschlossener Schwierigkeitswert**. Tatsächliche Pi-/Desktop-Zeit, Cache, Netz und Einreichungsfristen beeinflussen die praktische Chance.
|
||
|
||
### Gebühren und Fairness
|
||
|
||
Die abgelehnte Idee „Gebühr pro aktuellem Wallet-Guthaben“ lässt sich durch Wegüberweisen von PTM manipulieren. **Stattdessen:** gebührenrelevant sind die PoP-Gewinne der **zugeordneten Mining-Identität/Betreibergruppe** über ein gleitendes Fenster von ungefähr **90 Tagen**. Langjährige Miner haben keinen lebenslangen Malus; alte Gewinne fallen mit der Zeit heraus.
|
||
|
||
`Fenster 2 = Basisbetrag2 + Progressive(90-Tage-Ertrag)`; `Fenster 3 = Basisbetrag3 + stärkerer progressiver Anteil`. **Alle exakten Prozentsätze, Stufen, Beträge und Rundungsregeln sind offen**. Bei Erfolg in Fenster 1 oder 2 fallen spätere Gebühren nicht an; Zusatzgebühren im Misserfolgsfall werden nicht erstattet.
|
||
|
||
**PoP-Fenster-/Workergebühren gehen laut ADR 0007/0008 zu 100 % an den On-chain-Fonds, 0 % Burn dieser Kategorien**; normale Überweisungsgebühren und deren mögliche Validatorfinanzierung sind noch offen. Mining funktioniert kostenlos mit 0 PTM über Fenster 1. Die Wallet gibt kostenpflichtige Fenster einzeln oder per eng begrenzter, widerrufbarer Autorisierung frei. Der Miner erhält niemals Browser-Wallet-Secrets.
|
||
|
||
### Wichtige Grenzen
|
||
|
||
- **Sybil-Problem:** eine kryptografische Node-ID beweist keine eigene physische Maschine oder Person. Anfangs manuell freigegebene Registrierungsidentitäten und Betreiberzuordnung. Mehrfachidentitäten müssen organisatorisch kontrolliert werden.
|
||
- **Kein Nachweis erfolgloser Arbeit:** Validatoren sehen gültige Hash-Treffer, nicht echte CPU-Minuten ohne Treffer. Endliche Nonce-Räume begrenzen erlaubte Treffer pro Identität.
|
||
- **Hardware:** schnellere Rechner sind früher fertig; beim Pi 4 müssen endliche Aufgaben in ihrem Fenster zuverlässig bearbeitbar sein. Vollkommene Hardwaregleichheit lässt sich nicht beweisen.
|
||
- **Zufall/Zensur:** Validatoren könnten Aufnahme von Proofs/Gebühren behindern, Beacon-Ausfall kann Ziehung verzögern. Fristen und Fallback vor Mainnet präzisieren.
|
||
- **Budget:** Gebühren für zusätzliche zufallsabhängige Chancen sind kein harmloses Detail, mögliche Glücksspiel-/Finanzrechtsfolgen. Vorläufig ausschließlich Privat-/Testnet ohne echten Wert.
|
||
|
||
## 5. Coin und Transaktionen: offen
|
||
|
||
Coin-Menge, Genesis-Verteilung, kleinste Einheit/Dezimalstellen, Belohnung, Halbierungen/Emission, Standardgebühren, Blockzeit, RNG-Beacon, Signatur-/Adressformat und Datenbank müssen **vor konsenskritischem Code** entschieden werden. Zahlen aus Chat-Beispielen (`10 Mio`, `1 PTM je Runde`, `12 Blöcke`, `10 Sekunden`, Gebührenstaffel oder `70 %`) nicht als Default übernehmen. Saldos ausschließlich in ganzen Basis-Einheiten, Replay-Schutz mit Nonce, Signatur und Chain-ID, deterministische Aufträge.
|
||
|
||
## 6. Web-Wallet ab erster funktionaler MVP-Version
|
||
|
||
- Wallet lokal und sicher erstellen/importieren/verschlüsselt exportieren und entsperren/sperren.
|
||
- Korrekte PTM-Adresse anzeigen/kopieren, Balance/Netzwerkverbindung, PTM senden inkl. Fee-Preview und Bestätigung, empfangen, Verlauf mit echtem Tx-Status.
|
||
- Privater Schlüssel und Seed **niemals** an API, Node, Miner oder Logs; Browser-signierte Transfers; sichere, getestete Kryptobibliotheken und eindeutig definierte signierbare Bytes.
|
||
- Für kostenpflichtige Fenster: gültigen Gebührenmaßstab, Spend-Limit, Maximalpreis und explizite Freigabe anzeigen. Solange die sichere Autorisierung nicht implementiert ist: Zusatzfenster deaktiviert.
|
||
- Keine erfundenen Guthaben, Fake-Transaktionen oder als sicher deklarierte ungetestete Wallet-Demos. Aktuelles `web/wallet` ist **nur statisches UI-Gerüst**.
|
||
|
||
## 7. Repository und Verfahrensregeln
|
||
|
||
`AGENTS.md` ist Codex-Leitlinie; `docs/PROJEKTPLAN.md`, `docs/PROTOKOLL_ENTWURF.md`, `docs/POP_FAIRNESS_UND_GEBUEHREN.md`, `docs/ROADMAP.md` und `docs/decisions/` sind der aktuelle Stand. Git-Branches klein halten, Änderungen nicht ungefragt pushen oder echte Schlüssel committen. Alle wichtigen Protokollentscheidungen als ADR mit Gründen, Alternativen und Folgen; die letzte akzeptierte ADR hat Vorrang gegenüber älteren Entwurfsbeispielen.
|
||
|
||
## 8. Nächste Schritte
|
||
|
||
1. Update anwenden und Repo-Änderungen prüfen, testen, committen.
|
||
2. Mit Codex den **M1-Parameterblock** bearbeiten: Tokenomics und Tx-Signaturen, dann Gebühren-/Fairness-Simulation für mindestens 5/10/20/50 Miner samt Erwartungswert/Kosten, Benchmark auf Pi 4.
|
||
3. Finale konsenskritische Regeln einzeln per ADR bestätigen, erst dann implementieren.
|
||
4. Ledger und funktionale Web-Wallet **parallel**, danach CometBFT-Integration und PoP-Logik.
|
||
|
||
## 9. Nicht vorspiegeln
|
||
|
||
Ein sauberes Go-Gerüst und eine HTML-Oberfläche sind **noch keine nutzbare Blockchain oder Wallet**. Der neue Gebührenentwurf ist **dokumentiert und simulationsbedürftig**, nicht implementiert.
|
||
|
||
## 10. Langfristige PTM-Nutzung: Sammlerstücke und virtuelle Handelsplätze (Vision)
|
||
|
||
Die im Oktober 2026 ergänzte Vision sieht **nach stabiler Kern-Chain und Web-Wallet** digitale Sammelobjekte (F1), einen in PTM abgewickelten internen Marktplatz (F2), eine Handelsoberfläche für fiktive interne Assets mit Orderbuch, Kursen, Charts und Portfolios (F3) und optional einen strikt getrennten Paper-Trading-Modus (F4) vor. Diese Szenarien sollen PTM einen internen Nutzwert geben. Sie begründen **keinen externen Euro-Kurs**, keine Börsenlistung und keine Anlage- oder Renditeaussage.
|
||
|
||
Asset-Kauf, Sammelgegenstände oder Bestandshöhen dürfen die PoP-Lotterie nicht zusätzlich bevorteilen. Die technischen Details (Assetmodell, Emission, Marktdaten, atomare Trades, Ordermatching, Gebühren und Schutz gegen Wash Trading) sind absichtlich offen. Keine Funktionen sind implementiert. Maßgeblich: `docs/ZUKUNFT_OEKOSYSTEM.md`, `docs/ROADMAP.md` und ADR 0004. Die Arbeiten an M1–M6 behalten Vorrang.
|
||
|
||
## Architekturergänzung v0.4: Hub, Worker, Cluster
|
||
|
||
Potatium Hub ist die autonome Full-Node mit Client-Wallet, eigenem Mining und lokalem Cockpit. Ein Worker ist ein schlanker an den Hub gebundener Miner ohne eigenständiges Coin-Wallet. Eine Betreiber-Identität gruppiert diese Instanzen und deren Kosten/PoP-Gewinne, auch bei mehreren Hubs/Wallets. Es gibt einen kostenfreien Hub-Mining-Platz je Betreiber; zusätzliche genehmigte Mining-IDs zählen wirtschaftlich als Worker. Jeder zugelassene Miner max. ein Ticket je Runde. Worker-Gebühren zusätzlich zu PoP-Fenster-2/3 sind noch Forschungsmodell. Priorität Node-/Cluster-Cockpit, später separate Admin-WebGUI. Für Details sind `docs/HUB_WORKER_CLUSTER.md`, `docs/WORKER_GEBUEHREN_FORSCHUNG.md` und ADR 0005 maßgeblich.
|
||
|
||
## Infrastruktur und Cockpits (Ergänzung v0.5)
|
||
|
||
Die Betriebsrollen, Datenspeicherung und Deployment-Stufen werden in `docs/INFRASTRUKTUR_UND_DEPLOYMENT.md` vollständig erklärt. Ab dem ersten funktionalen Devnet werden **beide lesenden Ansichten** umgesetzt: lokaler Potatium-Hub mit Wallet- und Node-Status sowie separater **Network Admin read-only** für Blockchain-/Validatorüberblick. Die administrative Schreibverwaltung kommt später. Begründung und Grenzen dokumentiert ADR 0006; UI-/Metrikkriterien stehen in `docs/COCKPITS_UND_MONITORING.md`. Kein zentraler Chain-Datenbankserver und keine Abhängigkeit der Blockchain vom Monitoring.
|
||
|
||
## Netzwerkzugang und Betreiberverwaltung (aktueller ADR 0008)
|
||
|
||
**Keine zentrale Benutzerplattform oder Pflichtregistrierung für den P2P-Sync.** Authentische Chain-ID, Genesis und CometBFT-Seed-/Persistent-Peers werden pro Node konfiguriert. Nur PoP-Mining erfordert autorisierte On-chain-Registry und operatorbezogene Gebühren-/Gewinnhistorie; Freigabe/Sperre im geschützten Network Admin über gesonderte signierte Aktionen. Der Network Admin ist ab erstem lauffähigem Devnet zunächst lesend mit echter Supply-/Burn-/Fonds-/Gebühren-/Registry-/Validatorübersicht, inaktiv markierten Freigabeaktionen bis zum vollständigen Signatur-Workflow. Optionales Monitoring-Inventar ist nicht konsenskritisch. Hub und Worker sind die beiden Teilnehmerpakete; Auszahlungs-Wallet-Schlüssel bleiben lokal im Browser. **100 % PoP-/Worker-Gebühren fließen in den On-chain-Fonds**, keine Burns dieser Gebühren. `docs/INSTALLATIONSPLAN_HOMELAB.md`, `docs/NETWORK_ZUGANG_UND_IDENTITAETEN.md` und ADR 0008 sind aktueller Stand.
|
||
|
||
## Erkenntnisse der Dynamik-/Fonds-Simulation vom 25.10.2026
|
||
|
||
36 Forschungsdurchläufe zeigen, dass dynamische Worker-Steuerung mit höheren Gebühren aktive große Cluster bremst, zugleich aber die Fondsbindung stark ansteigen kann: 3× dynamisch 40,59 % des erzeugten Supply, 5× fix 70,20 % bei gehaltenem Fonds. Die hypothetische Rückverteilung ist ohne Sybil-Schutz nicht als Governance-Beschluss geeignet. **Keine Workergebühr, Rundenlänge, Rewardhöhe oder Fonds-Auszahlung beschlossen.** Siehe `docs/POP_DYNAMIK_FONDS_AUSWERTUNG_2026-10-25.md`.
|