# Potatium: Protokollentwurf v0.2 (nicht implementiert)

**Stand 25.10.2026.** Die Grundrichtung des Mining-Modells ist abgestimmt. Sämtliche konkreten Zahlen und konsenskritischen Details sind bis zur Simulation, Pi-Messung und einem bestätigten ADR **offen**. `docs/decisions/0003-pop-fenster-und-gebuehren.md` hält den Grundsatzentscheid fest.

## Beschlossene Produktprinzipien

1. Potatium ist eine eigenständige Hobby-L1 mit nativen PTM (Ticker vor externer Nutzung prüfen), Go-Kern, Web-Wallet ab erstem funktionalem MVP. Kein Ethereum-Token.
2. Blockchain-Validatoren (geplant: CometBFT + eigene ABCI++-App) bestätigen Blöcke; PoP-Miner bestimmen weder Blockreihenfolge noch Validator-Konsens.
3. **Eine Mining-Runde hat drei nacheinander freigegebene Mining-Fenster.** Die Zahl der Consensus-Blöcke je Runde/Fenster ist noch offen; alte Beispiele „12 Blöcke/120 Sekunden“ sind keine Entscheidung.
4. **Fenster 1 ist kostenfrei.** Fenster 2 und 3 sind freiwillig, kosten jeweils eine **fixe Grundgebühr plus progressive Komponente** und werden nur solange kein gültiges Ticket angenommen wurde gebraucht.
5. Die Gebührenbasis ist die **nachweisbare, einer registrierten Mining-Identität/Betreiberzuordnung zugerechnete PoP-Gewinnsumme der zurückliegenden ca. 90 Tage**, **nicht** das gerade sichtbare Wallet-Guthaben. Genaues Zeit-/Höhenfenster und Verbundidentitäten noch spezifizieren. Langjährige Aktivität an sich darf keinen permanenten Bonus/Malus auslösen.
6. Progression: Fenster 3 soll teurer sein und zugleich **deutlich geringeren zusätzlichen Nutzen** als Fenster 2 bieten. **Keine unlimitierten Zusatzchancen, kein Kauf einer weiteren Identität.** Konkrete Tarife und Erfolgswahrscheinlichkeiten erst nach Simulation entscheiden.
7. Ein qualifizierter Miner erhält **maximal ein Ticket** je Runde. Nur vollständig gültige Proofs aus zulässigen Fenstern zählen. Nach dem ersten gültigen Proof endet die Teilnahme dieser Identität für diese Runde.
8. **ADR 0007 gilt:** 100 % der Zusatzfenster- und Worker-Gebühren werden dem On-chain-Community-Fonds gutgeschrieben, 0 % Burn dieser Gebühren. Normale Transaktionsgebühren und Fondsauszahlungen bleiben offen.
9. Ohne PTM kann jede zugelassene Identität an Fenster 1 teilnehmen. Gebühren und Mining-Erfolg dürfen keine Gewinnergarantie erzeugen.
10. Registrierte Identität ≠ nachweislich einzigartige physische Maschine oder Person. Für das kleine private Netzwerk zunächst manuelle Freigabe, Audit und Sperrmöglichkeit. Mehrere Geräte/Identitäten und gemeinsamer Betreiber müssen gesondert geregelt werden.

## Ablauf einer Mining-Runde (logisches Zustandsmodell)

```text
Runde R beginnt; Identitäten / Regeln / Gebührenbasis werden eingefroren
  Fenster 1: kostenlose, identitätsgebundene PoW-Challenge
       | gültiger Proof? -> 1 Ticket; fertig
       | andernfalls
  Fenster 2: vorher autorisierte, bestätigte Gebühr in den On-chain-Community-Fonds buchen (ADR 0007)
       | neue, zuvor unbekannte PoW-Challenge; Proof? -> 1 Ticket; fertig
       | andernfalls
  Fenster 3: höhere Gebühr vorab in den On-chain-Community-Fonds buchen (Fenster 2 muss zuvor freigeschaltet sein)
       | neue PoW-Challenge; Proof? -> 1 Ticket; fertig
       | andernfalls kein Ticket
  Fristende: akzeptierte Tickets endgültig fixieren
  Später: unabhängige, überprüfbare Zufallsquelle belegen
  Gewinner deterministisch bestimmen und regelgerecht PTM erzeugen
```

*In einzelnen Fenstern darf ein Miner innerhalb eines **begrenzten Nonce-Raums** leichte SHA-256-Arbeit leisten. Der Node kann gültige Treffer und Zeitfenster prüfen, **nicht**, wie viele erfolglose Hashes tatsächlich gerechnet wurden; das Protokoll kann nur „kein Ticket angenommen“ kontrollieren. Für Fenster 3 ist vorherige kostenpflichtige Freischaltung von Fenster 2 nötig, nicht ein technisch unmöglich beweisbarer Misserfolg. Neue Fensterchallenges müssen beim vorigen Fenster nicht im Voraus berechenbar sein.*

## Gebühren und Emission: Sicherheitsregeln

- Jede Gebühr besteht aus einer **ganzzahligen Basis-Einheiten**-Berechnung, mit expliziten Rundungs- und Überlaufregeln. Keine Float-Werte in konsenskritischen Funktionen.
- **Gebühren-Snapshot vor der Runde** aus finalisiertem Chain-State; exakt definierte Zuschreibung von Mining-Belohnungen zu Identitäten und bei Bedarf gemeinsamer Betreibergruppe. Wallet-Transfers dürfen die Zuschreibung nicht zurücksetzen.
- Fenster-Freischaltung nur nach bestätigter, replaygeschützter **Gebührenautorisierung**. Falls keine gültige Zahlung vorliegt: kostenloses Fenster bleibt nutzbar, das kostenpflichtige Fenster nicht.
- Keine Rückerstattung bei erfolglosem Fenster. Ob nach einem bereits gewonnenen Ticket überhaupt Gebühren mehr eingereicht werden dürfen: **nein**.
- Kein Miner-/Validatorprozess erhält ungefragt den privaten Browser-Wallet-Schlüssel. Spätere Komfortzahlung nur über eingeschränkte, widerrufbare, runden- und betragsbegrenzte Signaturfreigabe mit definierten Nonces; **nicht implementiert**.
- `minted_total`, `burned_total` und verfügbare Guthaben getrennt, deterministisch und integerbasiert führen; Versorgungslimit und Gebührenbehandlung festlegen.
- Gewinnerauswahl erst nach Commitment der Ticketmenge, mit **später bekannt werdender verifizierter** Zufallsquelle, etwa nachweisbarem drand-Beacon. Beacon-Ausfälle, Reorgs, Verzögerung und Manipulation definieren.
- Wenn niemand qualifiziert ist: **kein Gewinner**; Emission/Carryover und Timeout weiterhin offen.

## Sicherheitsgrenzen und zu prüfende Angriffe

- **Sybil:** mehr echte Geräte oder zugelassene Zweit-Identitäten verschaffen mehr Chancen; Geräteerkennung ist keine beweisbare Personenprüfung.
- **Identity-Splitting:** Betreiber könnte Gewinne/Identitäten aufteilen und Progression umgehen. Registry und Betreiber-Zusammenfassung nur organisatorisch für Hobby-Testnet, nicht mathematisch perfekt.
- **Zeitfenster/HW:** Schnelle CPUs können den begrenzten Nonce-Raum früher fertigstellen. Nur reale Pi-4-Benchmarks und großzügige Fristen können einen merklichen Vorteil klein halten, nicht ausschließen.
- **Zensur:** ein Validator darf nicht unbemerkt rechtzeitig gesendete Gebühren/Proofs verdrängen; konkrete Gegenmaßnahmen und Finalitätsfristen fehlen noch.
- **Anreize:** progressive Gebühren können für manche Nutzer wirtschaftlich unvernünftig werden, bei kleinem Netzwerk kostenpflichtige Fenster aber dominieren. Simulation für 5/10/20/50 Miner und verschiedene Vermögens-/Erfolgsklassen nötig.
- **Recht:** Zahlungen für höhere Chancen auf zufallsabhängige Gewinne können Glücksspiel-/Finanzrecht berühren. Vor öffentlicher Nutzung juristisch prüfen; vorerst nur privates Testnet ohne wirtschaftlichen Wert.

## Nicht beschlossene Parameter

| ID | Parameter / Festlegung noch nötig |
|---|---|
| P-01 | Maximale Gesamtmenge, Basis-Einheit/Dezimalstellen, Genesis-Zuteilung |
| P-02 | Emission/Belohnung pro Ziehung, Emissionsobergrenze, leere Runden, Halving |
| P-03 | Blockzeit, Anzahl Consensus-Blöcke je PoP-Runde und je Fenster |
| P-04 | PoW-Hash-Vorlage, Nonce-Raum, Schwierigkeitsziel/Erfolgsrate, Pi-4-Benchmark |
| P-05 | Finale Gebührenformel, Fixbetrag, Marginalstufen, Multiplikator Fenster 3, Mindest-/Maximalbetrag und Rundungsregel |
| P-06 | Exakte Bestimmung „letzte 90 Tage“ (Zeitstempel vs. Blockhöhen) und Zuordnung der Gewinne zu Betreibergruppen |
| P-07 | Signierte Gebührenfreigabe, Zahlungsreihenfolge, Ablauf/Nonce, Fallback, Verwahrung und Gebühren bei Reorg |
| P-08 | Signatur-/Adressformat, Wallet-Recovery und Tx-Serialisierung |
| P-09 | Proof-Einreichungs- und Finalitätsfristen, RNG-Quelle/Fallback, Ticket-Commit, Auszahlung |
| P-10 | Registry-Administration, Zweitgeräte-Regel, Validator- und normale Gebührenverteilung |

**Wichtig:** Zahlen aus älteren Diskussionen wie 70/91/97,3 %, 1 PTM Belohnung, 10 Mio. PTM, 10-s-Blockzeit oder 0,001-PTM-Grundkosten bleiben ausschließlich **Rechenbeispiele**. Sie sind nicht implementiert, beschlossen oder für öffentliche Nutzung freigegeben.

## Ergänzung v0.4: Betreibergruppe, Mining-IDs und Cluster

Die zulassungsfähige Mining-Einheit ist eine `mining_id` mit zugehöriger `operator_id`, Signaturschlüssel und Rollenmerkmal (`hub_miner`, `worker`). **Jede genehmigte Mining-ID erhält maximal ein Ticket je Gesamtrunde**, unabhängig vom Gerätetyp oder Hub-Prozess. `operator_id` aggregiert sämtliche PoP-Belohnungen für die progressive ca. 90-Tage-Fee-Basis; eine registrierte Auszahlungsadresse empfängt alle Rewards. Wallet-/Hub-Wechsel erzeugt keine neue Betreiberhistorie. Pro Betreiber nur **ein** kostenloser Hub-Mining-Platz; weitere miningfähige Hubs zählen bei Worker-Kosten wie Workerslots. Registry-Aufnahme und Revocation bleiben manuell auditierbar.

**Zusätzliche Worker-Aktivierungsgebühren** werden als Konzept weiter untersucht (nicht final). Falls eingeführt, ist eine Teilnahmefreigabe **je PoP-Gesamtrunde** im finalisierten Zustand vor Veröffentlichung der neuen Challenge zu bezahlen/reservieren; sonst könnte die Node zuerst rechnen und nur bei Treffer zahlen. Fenster-2/3-Gebühren sind davon separat und ebenfalls vor Bekanntgabe der neuen Fenster-Challenge fällig. Die Bedienoberfläche muss beide Kostenarten sichtbar trennen. Festzulegen: exakte Gebührenformel in Integer-Basiseinheiten, Snapshot, fee allowance/reserve, Kosten bei Hub-Ausfall, Verbindlichkeit des Aktivierungszeitpunkts, eindeutige Workerzahl und Höchstzahl. **Keinerlei vorgeschlagene Zahlen als endgültige Konsensregeln implementieren.** Siehe ADR 0005.

## ADR 0007: On-chain-Fonds statt PoP-Burn und zentrale Aufnahme

PoP-Fenster-2-/3-Gebühren sowie zulassungs-/rundenbezogene Worker-Aktivierungsgebühren fließen **zu 100 % in den On-chain-Fonds** und werden **nicht verbrannt**. Fonds ist Teil des umlaufenden Supply, nicht zusätzliche Emission; deterministische `fund_balance`-/`fund_collected_total`-/`fund_spent_total`-Buchungen und eine eindeutig definierte Gebührenreservierung/Refund-Regel müssen vor Implementierung festgelegt werden. Normale Transaktionsgebühren und Fonds-Ausgaberechte bleiben offen. Frühere Burn-Angaben in ADR 0003 werden für diese Kategorien durch ADR 0007 ersetzt; Burn-Zähler bleibt für echte eventuelle Burns erhalten.

**ADR 0008 gilt:** Keine verpflichtende zentrale Registrierungsplattform. Hubs synchronisieren per CometBFT-P2P anhand konfigurierter/verifizierter Genesis-/Chain-/Peer-Daten. PoP-Zulassung nur nach autorisierter On-chain-Freigabe, Widerruf signiert/auditiert. Siehe `docs/NETWORK_ZUGANG_UND_IDENTITAETEN.md` und ADR 0008.