potatium/docs/POP_CLUSTER_SIMULATION.md

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.

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

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:

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:

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

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.