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

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.
Blockchain-Validatoren (geplant: CometBFT + eigene ABCI++-App) bestätigen Blöcke; PoP-Miner bestimmen weder Blockreihenfolge noch Validator-Konsens.
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.
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.
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.
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.
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.
Zusatzfenster-Gebühren werden verbrannt (aus dem spendierbaren Umlauf entfernt). Normale Transaktionsgebühren sollen die Validatoren finanzieren; Zuteilungsmechanik ist noch offen.
Ohne PTM kann jede zugelassene Identität an Fenster 1 teilnehmen. Gebühren und Mining-Erfolg dürfen keine Gewinnergarantie erzeugen.
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 verbrennen
       | neue, zuvor unbekannte PoW-Challenge; Proof? -> 1 Ticket; fertig
       | andernfalls
  Fenster 3: höhere Gebühr vorab verbrennen (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.

7.9 KiB Raw Blame History