docs: update Proof of Potato model to v0.2
This commit is contained in:
1 parent
e2d0be22fd
commit
7397045a54
19 files changed
+588
-813
No files matched your search
@@ -9,3 +9,5 @@ Name Potatium/PTM und abstraktes goldenes P-Logo. Hobby-L1 mit PoW-qualifizierte
|
||||
## Folgen
|
||||
|
||||
Konkrete Mint-/Konsens-/Schlüsselparameter werden nicht aus Beispielzahlen abgeleitet. Sicherheit und reproduzierbare Entwicklung haben Vorrang vor Features.
|
||||
|
||||
**Fortschreibung 25.10.2026:** PoP-Details aus diesem frühen ADR sind durch den Produktentscheid [ADR 0003](0003-pop-fenster-und-gebuehren.md) (drei Fenster, optionale progressive Gebühren, Burn, ein Ticket pro Runde) teilweise überholt. Sonstige Grundentscheidungen bleiben erhalten.
|
||||
@@ -0,0 +1,33 @@
|
||||
# ADR 0003: Drei PoP-Fenster mit erfolgsabhängigen Zusatzgebühren
|
||||
|
||||
**Status:** Accepted (Produktprinzip), **Parameter weiterhin Proposed**
|
||||
**Datum:** 25.10.2026
|
||||
**Ersetzt teilweise:** Grundidee in ADR 0001 und frühem Protokollentwurf (ein einmaliges Rätsel ohne Gebühren)
|
||||
|
||||
## Kontext
|
||||
|
||||
Eine einzelne sehr leichte Aufgabe qualifiziert fast jeden; dadurch wirkt die Rechenarbeit bedeutungslos. Unbegrenzte Hash-Versuche würden starke CPUs bevorzugen. Kaufbare Zusatzlose würden Besitzer hoher PTM-Guthaben bevorzugen. Potatium soll echte, aber Pi-taugliche Rechenarbeit mit freiwilligen Risiko-/Kostenentscheidungen verbinden.
|
||||
|
||||
## Entscheidung: Richtungsentscheid, keine fertige Tokenomics
|
||||
|
||||
- Jede PoP-Runde besteht aus **drei seriellen Mining-Fenstern** mit erst zum Fensterstart nutzbarer Herausforderung und begrenztem erlaubtem Nonce-Raum.
|
||||
- Fenster 1 **kostenlos**. Fenster 2/3 nur optional solange noch kein gültiges Ticket angenommen wurde, nur nach **vorher bestätigter** fixer **plus progressiver** Mining-Zusatzgebühr. Fenster 3 wird teurer und soll geringeren Zusatznutzen bieten.
|
||||
- Maßstab der Progression: der Miner-Identität bzw. zugeordneten Betreibergruppe zurechenbare **PoP-Belohnungen eines gleitenden Zeitfensters von ungefähr 90 Tagen** statt des aktuellen Wallet-Guthabens. Kein automatisch kumulierender lebenslanger Erfolgsbonus/-malus.
|
||||
- Zusatzgebühren **verbrennen**; normale Transaktionsgebühren für Validator-Finanzierung separat behandeln.
|
||||
- **Maximal ein gültiges Ticket pro freigegebener Miner-Identität und PoP-Runde**, keine mehrfachen Lose/Losgewichte für zusätzliche Fenster nach Erfolg.
|
||||
- Offene P-Parameter siehe `docs/PROTOKOLL_ENTWURF.md`. Simulation und Raspberry-Pi-Tests sind Voraussetzung für endgültige Zahlen und Konsensimplementierung.
|
||||
|
||||
## Abgewogene Alternativen
|
||||
|
||||
- Freie, unbegrenzt wiederholbare Hash-Aufgaben: HW-Vorteil zu groß.
|
||||
- Ein leichter Proof mit garantierter Qualifikation: kaum relevante Mining-Entscheidung.
|
||||
- Pauschale zusätzliche Lose pro Gebühr: vermögensabhängiger Vorteil.
|
||||
- Prozentuale Gebühr auf aktuelle Wallet-Balance: leicht durch Transfer auf andere Adressen umgehbar.
|
||||
- Lebenslang kumulierte Miner-Belohnungen: dauerhafter Nachteil für langjährige Miner.
|
||||
- Reine Zeit-/Online-Herzschläge: kaum beweisbare reale Arbeit, leicht zu automatisieren.
|
||||
|
||||
## Konsequenzen und offene Risiken
|
||||
|
||||
Die Node muss gefensterte Challenges, vorher bestätigte und replaygeschützte Gebühren, historische PoP-Gewinne, identitätsgebundene Tickets und spätere verifizierbare Ziehung deterministisch verwalten. Betreiber-/Sybil-Identität bleibt organisatorisch; ein Wallettransfer ändert die Mining-Historie nicht, eine ungenehmigte neue Identität könnte sie jedoch umgehen. Zahlungen für zusätzliche Zufallschancen bergen rechtliche Risiken, auch bei Hobby-Projekten. Vorerst nur wertlose Test-PTM; kein öffentliches Angebot.
|
||||
|
||||
**Noch NICHT festgelegt:** 70-%-Erfolgsrate, 10/12 Blöcke, Coin-Reward, 90 Tage exakt vs. deterministische Blockhöhen, progressive Stufen/Prozentsätze, Fixbeträge, Rundungen, Verlustrisiken, Wallet-Freigabeformat oder drand-Konfiguration.
|
||||
Reference in new issue
Block a user