potatium/docs/PROTOKOLL_ENTWURF.md

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)

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.