# Potatium | Hub-Worker-Ökonomie: Offline-Forschung v0.1

**Kein Konsenscode, keine realen PTM, keine Netzwerkzugriffe.** Reproduzierbare Monte-Carlo-Tests mit der Python-Standardbibliothek. Diese Ergänzung ersetzt keine bestehenden Simulationsskripte.

## Ziel

Verschiedene Clustergrößen (1 eigenständiger Hub plus 0–10 zusätzliche Mining-Worker) auf eine **gemeinsame Betreiberidentität und Wallet** buchen und Kosten vs. Gewinnchance vergleichen. Jede aktive Mining-ID, inklusive Hub, kann **maximal ein Los je PoP-Runde** erarbeiten. Nur ein registrierter Hub-Platz je Betreiber ist von der Worker-Gebühr befreit. Zusätzliche Hub-Mining-IDs wären wirtschaftlich wie Worker zu zählen, ihre physische Hardware kann das Modell nicht erkennen.

## Modellierte Regeln und Forschungsparameter

- **Fenster 1:** Bei jeder aktivierten Mining-ID kostenlos, Bernoulli-p je Node; p = 0,55 im Profil `balanced`.
- **Fenster 2/3:** Nur nach bisherigem Qualifikationsfehlschlag derselben ID; jeweils kostenpflichtig und erfolgreich mit p=0,30 bzw. p=0,20. Bei Erfolg keine dritte Aufgabe. Die Fensterwahrscheinlichkeiten bleiben **Forschung**, keine PoP-Konsensparameter.
- **Gewinnauslosung:** Eine Bruttobelohnung je Runde, sofern mindestens ein Los akzeptiert wurde. Jedes Los einer ID ist gleichwertig. Bei mehreren Losen desselben Betreibers kann dieser mehrfach vertreten sein, aber pro Runde höchstens die *eine* Bruttobelohnung erhalten.
- **Betreiber-Wallet:** Alle Worker und der Hub teilen Guthaben, Gebührenbudget und die rollierende **90-Tage-PoP-Gewinnhistorie**. Fensterprogression und Gebührenzahlung werden pro Betreiber zusammengefasst. Wallet-Transfers sind nicht simuliert.
- **Worker-Aktivierung:** Vor der Challenge bezahlt, auch bei Misserfolg. Ist das Guthaben unzureichend, werden weniger Worker aktiviert. Ein Offline-Worker wird im Modell nicht simuliert.
- **Worker-Tarif:** `marginal` (pro Worker: 1–3 je 0,001 PTM, 4–7 je 0,003 PTM, 8–10 je 0,005 PTM) vs. `tier` (pauschal 0,001/0,003/0,005 PTM je Betreiber und Runde). Die Skala kann mit `--worker-fee-scale` geändert werden. **Kein endgültiger Tarif.**
- **Fenster-Tarif:** Fixe F2/F3-Grundgebühr (0,001 / 0,003 PTM) + progressive Abgabe nach PoP-Gewinnen der letzten 90 Tage. `original` = 100 % der v0.2-Progression, `mild` = 10 %, `low` = 1 %. Ausschließlich die Progression wird skaliert, fixe Grundkosten bleiben.
- **Zahlungsstrategie:** `free` stoppt nach F1, `always` kauft erlaubte weitere Fenster soweit finanzierbar, `rational` verwendet eine *vereinfachte* Grenzertragsschätzung mit eigener bereits erreichter Ticketzahl und einer F1-Schätzung fremder Tickets. Es ist **keine optimal spieltheoretische Strategie**.
- **Wettbewerb:** Jedes weitere registrierte Betreiberkonto ist ein eigenständiger Konkurrent; optional besitzen auch die Konkurrenten Worker. Optional kommen neue Betreiber ab einem festgelegten Simulationstag hinzu.
- **Emission:** Beispielhaft 1 PTM pro Runde mit Sieger; Gebühren werden verbrannt. Kein Sieger bedeutet keine Emission. `--rounds-per-day 720` entspricht dem früheren **unverbindlichen** Vorschlag von ca. 2 Minuten je PoP-Runde.

## Installation im bestehenden Git-Repository

Das ZIP enthält ausschließlich drei **neue** Pfade, die noch nicht vorhanden sein sollten:

```
scripts/simulate_pop_cluster.py
tests/test_pop_cluster.py
docs/POP_CLUSTER_SIMULATION.md
```

Vor dem Entpacken mit `unzip -l` prüfen. Mit `unzip -n` werden bestehende Dateien niemals überschrieben. Der Befehl führt selbst noch keine Blockchain-Funktionen aus.

```bash
cd ~/src/potatium
unzip -n ~/Potatium_PoP_Cluster_Simulation_v0.1.zip -d .
python3 -m unittest discover -s tests -p 'test_pop_cluster.py' -v
```

## Schritt 1: Kurzer Funktionstest

```bash
python3 scripts/simulate_pop_cluster.py \
  --operators 20 --days 7 --rounds-per-day 720 \
  --workers 0 1 3 5 10 --replicates 1
```

## Schritt 2: 180 Tage, Worker-Sweep

Vergleich von 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Workern mit gemeinsamem Betreiber-Wallet, `balanced`-Fenstern und `low`-Progression:

```bash
python3 scripts/simulate_pop_cluster.py \
  --operators 20 --days 180 --rounds-per-day 720 \
  --workers 0 1 2 3 4 5 6 7 8 9 10 \
  --profile balanced --window-fee-model low \
  --worker-fee-model marginal --worker-fee-scale 1 \
  --target-policy rational --others-policy free \
  --replicates 3
```

**Hinweis:** Ein Modell mit 19 anderen Betreibern, die nur ihren eigenen kostenlosen Hub nutzen, begünstigt den Ausbau des einen getesteten Clusters. Das ist ausdrücklich ein Extrem-Szenario, kein realistisches Marktgleichgewicht.

## Schritt 3: Höhere Worker-Gebühren untersuchen

Gleiche Randbedingungen wie oben, aber beispielsweise fünffache Worker-Gebühren:

```bash
python3 scripts/simulate_pop_cluster.py \
  --operators 20 --days 180 --rounds-per-day 720 \
  --workers 0 1 2 3 4 5 6 7 8 9 10 \
  --profile balanced --window-fee-model low \
  --worker-fee-model marginal --worker-fee-scale 5 \
  --target-policy rational --others-policy free \
  --replicates 3
```

## Schritt 4: Alle Betreiber besitzen Worker, Neulinge kommen hinzu

```bash
python3 scripts/simulate_pop_cluster.py \
  --operators 20 --days 180 --rounds-per-day 720 \
  --workers 0 1 3 5 8 10 \
  --others-workers 2 --others-policy rational \
  --newcomers 5 --join-day 90 \
  --worker-fee-model marginal --worker-fee-scale 1 \
  --target-policy rational --replicates 3
```

## Schritt 5: Immer alle Fenster vs. kostenbewusst

Den gleichen Aufruf jeweils mit `--target-policy always` bzw. `rational` durchlaufen lassen. Bei `always` wird eine Fenstergebühr nur gezahlt, wenn die jeweilige Node zuvor noch kein Ticket erhalten hat und das Wallet genug Guthaben besitzt.

## Interpretation der Kennzahlen

- `Gewinn%`: **Betreiberchance auf den Rundengewinn**, nicht nur Qualifikation.
- `Brutto PTM`: Summe seiner erhaltenen PoP-Belohnungen.
- `Netto PTM`: Brutto minus Worker- und Fenstergebühren. Bei `initial_balance=0` identisch mit Endguthaben.
- `Ø aktive`: tatsächlich finanzierte Worker je Runde, ggf. kleiner als beantragt.
- `ΔNetto/Worker`: Unterschied des durchschnittlichen Nettoertrags zwischen zwei *getesteten* Worker-Zahlen, geteilt durch deren Abstand; bei fehlenden Zwischenwerten **nicht** der exakte marginale Wert eines einzelnen Workers. Bei wenigen Seeds statistisch verrauscht. Negativ bedeutet nur: In den simulierten Szenarien hat mehr Worker-Zahl einen geringeren Nettoertrag geliefert.
- `Gini`: Ungleichheit der Wallet-Guthaben **je registrierter Betreiberidentität**, kein Beweis für menschliche Fairness.
- `Burn`: Summe tatsächlich gezahlter Gebühren, keine Token-Pauschale oder einmaliger Gebührenabzug.

## Ergebnisdateien

Standardziel: `~/potatium-simulation/`. Das Skript erzeugt:

| Datei | Inhalt | Senden? |
|---|---|---|
| `pop_cluster_....txt` | Kurzer Szenarienvergleich | **Ja** |
| `pop_cluster_..._comparison.csv` | Alle Kennzahlen je Workerzahl | **Ja** |
| `pop_cluster_..._daily.csv` | Tagesverlauf, Einnahmen und Burn | Bei Rückfragen |
| `pop_cluster_..._operators.csv` | Endzustand je Betreiber | Bei Rückfragen |
| `pop_cluster_....json` | Vollständige reproduzierbare Simulation | Für tiefe Analyse |

Ein Hash über alle CLI-Parameter im Dateinamen vermeidet das Überschreiben verschiedener Vergleichsläufe mit ähnlichen Namen. Identischer Aufruf überschreibt seine alten Ausgabedateien.

## Bekannte Grenzen und offene Konsensfragen

- **Keine Sybil-Sicherheit:** Ein Betreiber mit mehreren künstlichen Betreiberkonten könnte mehrere freie Hubs und separate Gebührentöpfe bekommen. Diese Angriffsstrategie wird **nicht modelliert**. Eine manuelle Betreiber-Registry schließt Doppelanmeldungen nicht kryptografisch aus.
- Keine überwachbaren *fehlgeschlagenen* PoW-Aufwände. Jede Fensteraufgabe wird als unabhängiger Zufall mit angenommener Wahrscheinlichkeit modelliert; echte Pi-4-Zeiten fehlen.
- Keine realistische Übertragung von Gebührenmandaten aus dem Browser, keine verlorenen Schlüssel oder Netzwerkausfälle, keine Validator-Zensur, kein Peer-Latenzmodell.
- Die Bedingung, dass Zahlungsmandate/Worker-Freischaltungen vor der jeweiligen Challenge bindend feststehen, wird **logisch modelliert**, nicht kryptografisch implementiert.
- Keine Preisbindung an EUR/andere Kryptowährungen; PTM hat hier keinen externen Marktpreis und damit keinen externen Ertragswert.
- Gleichzeitige Entscheidungen der Miner, Fee-Scaling nach Anzahl Teilnehmern und strategisch variable Anzahl aktivierter Worker sind nicht optimiert. Der Zielbetreiber versucht stets, so viele der angefragten Worker zu aktivieren, wie sein Wallet finanzieren kann.
- Die Beispiele 1 PTM je Runde, 720 Runden pro Tag und bis zu zehn Worker sind **Forschungswerte, keine beschlossenen Protokollparameter**.
- Für eine echte On-chain-Implementierung ausschließlich ganzzahlige PTM-Basiseinheiten, konsenskritische Negativtests, feste Rundengrenzen, reproduzierbare Zufallsquelle und überprüfbare Signaturen verwenden.