Document long-term multi-parent pool considerations

Pool-Merge-Mining-Notes.md

@@ -672,3 +672,114 @@ Kolejna faza to nie jest już „czy da się to technicznie wykopać”, tylko:
 - jak zachować kontrolę nad operatorami MM
 
 To jest przejście z warstwy protokołu do warstwy produktu i ekonomii.
+
+## 20. Odległe Rozważania: Wiele Parentów I Scheduler Parentów
+
+Ta sekcja nie opisuje bieżącego planu. To tylko zapis potencjalnych przyszłych kierunków, gdyby ekosystem Peyi urósł dużo bardziej niż dziś zakładamy.
+
+### 20.1. Wiele parentów równolegle w ekosystemie
+
+To jest możliwe już teraz:
+
+- jeden pool może kopać `Salvium -> Peya`
+- drugi `Zephyr -> Peya`
+- trzeci `Monero -> Peya`
+
+Wszystkie mogą równolegle dostarczać bloki do tej samej aux chain `Peya`.
+
+To jednak nie jest to samo co „jeden miner kopie wszystkie te parenty naraz jednym jobem”.
+
+### 20.2. Dlaczego nie ma jednego wspólnego template dla wielu parentów
+
+Dla obecnych parentów (`Monero`, `Zephyr`, `Salvium`) nie ma sensownego jednego wspólnego `blocktemplate`, bo różnią się:
+
+- `blocktemplate_blob`
+- coinbase
+- dodatkowymi polami headera
+- semantyką parentowego bloba do PoW
+
+To oznacza, że jeden hash-job nie może uczciwie reprezentować wszystkich parentów naraz.
+
+W praktyce wyklucza to model:
+
+- jeden miner
+- jeden job
+- kilka różnych parentów ocenianych równolegle z tego samego realnego wejścia PoW
+
+### 20.3. Co byłoby możliwe zamiast tego
+
+Jeśli kiedyś pojawi się potrzeba bardziej złożonego sterowania parentami, sensowny byłby osobny moduł typu:
+
+- `multi-parent coordinator`
+
+Nie byłby to „super-template”, tylko scheduler / orkiestrator, który:
+
+- utrzymuje osobne template dla różnych parentów
+- wybiera aktywnego parenta dla całego poola albo dla grup minerów
+- podejmuje decyzje ekonomiczne lub operacyjne
+
+To nie oznacza łączenia parentów w jeden wspólny template. To oznacza zarządzanie wieloma osobnymi parentami.
+
+### 20.4. Przydział parenta według hashrate albo polityki
+
+Teoretycznie możliwe jest przydzielanie różnym grupom minerów różnych parentów, na przykład:
+
+- słabsi minerzy -> łatwiejszy parent
+- mocniejsi minerzy -> trudniejszy parent
+
+Nie należy jednak zakładać, że taki podział automatycznie daje lepszy wynik niż skupienie całego hashrate poola na jednym parentcie.
+
+Statystycznie zwykle lepiej:
+
+- sumować hashrate na jednym celu
+
+niż:
+
+- rozpraszać go między wiele celów
+
+Taki scheduler byłby więc raczej narzędziem:
+
+- UX
+- ekonomicznym
+- do ograniczania koncentracji
+
+a nie oczywistą optymalizacją czystej liczby bloków.
+
+### 20.5. Punkt nasycenia parenta
+
+Jest jednak jeden scenariusz, w którym podział hashrate między kilka parentów może mieć sens:
+
+- jeśli hashrate poola Peyi staje się bardzo duży względem konkretnego parenta
+- i pool zaczyna dominować znaczną część emisji tego parenta
+
+Wtedy dalsze dokładanie hashrate do jednego parenta może dawać malejący przyrost korzyści, bo:
+
+- parent i tak emituje ograniczoną liczbę bloków w czasie
+
+W takim scenariuszu nadwyżkę hashrate można rozważyć kierować do innego parenta. Byłby to problem optymalizacji marginalnego zysku z dodatkowego hashrate, a nie problem wspólnego template.
+
+### 20.6. Drobne forki Monero
+
+Jeśli w przyszłości pojawią się drobne forki Monero, które:
+
+- nie zmieniają istotnie kodu
+- zachowują zbliżony format bloku
+- pozostają `RandomX`
+
+to nadal nie oznacza to możliwości kopania ich jednym wspólnym jobem razem z Monero.
+
+Nawet przy bardzo zbliżonym kodzie zostają różnice:
+
+- inny `seed_hash`
+- inna wysokość
+- inny poprzedni blok
+- inny coinbase
+
+To wystarcza, by wykluczyć prawdziwe współkopanie jednym template.
+
+Taki fork może być natomiast:
+
+- łatwiejszy do obsłużenia adapterem
+- łatwiejszy do dodania do schedulera parentów
+
+ale nadal jako osobny parent, nie jako drugi równoległy cel tego samego joba.