docs: update Potatium v0.6 architecture and PoP research

docs/PROTOKOLL_ENTWURF.md

@@ -11,7 +11,7 @@
 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. Zusatzfenster-Gebühren werden **verbrannt** (aus dem spendierbaren Umlauf entfernt). Normale Transaktionsgebühren sollen die Validatoren finanzieren; Zuteilungsmechanik ist noch offen.
+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.
 
@@ -22,10 +22,10 @@ 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
+  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 verbrennen (Fenster 2 muss zuvor freigeschaltet sein)
+  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
@@ -71,3 +71,15 @@ Runde R beginnt; Identitäten / Regeln / Gebührenbasis werden eingefroren
 | 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.