From 1c061228a74aa40238bd2a9ec7699ef4d5f190ad Mon Sep 17 00:00:00 2001 From: Codex Bot Date: Sat, 21 Mar 2026 23:31:51 +0100 Subject: [PATCH] Add one-parent multi-aux future note --- Pool-Merge-Mining-Notes.md | 49 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/Pool-Merge-Mining-Notes.md b/Pool-Merge-Mining-Notes.md index 120865a..ac6948e 100644 --- a/Pool-Merge-Mining-Notes.md +++ b/Pool-Merge-Mining-Notes.md @@ -783,3 +783,52 @@ Taki fork może być natomiast: - łatwiejszy do dodania do schedulera parentów ale nadal jako osobny parent, nie jako drugi równoległy cel tego samego joba. + +### 20.7. Jeden parent, wiele aux chainów + +Osobnym i dużo bardziej realistycznym wariantem niż „wiele parentów jednym jobiem” jest: + +- jeden parent +- wiele aux chainów + +Przykładowy przyszły układ: + +- `Monero` jako parent +- `Tari` jako jedna aux chain +- `Peya` jako druga aux chain + +To nie byłby model: + +- wiele parentów naraz + +tylko: + +- jeden parentowy job +- kilka niezależnych aux ścieżek budowanych z tego samego parentowego wysiłku + +To jest architektonicznie bliższe klasycznemu merge miningowi niż jakiekolwiek próby wspólnego template dla `Monero`, `Zephyra` i `Salvium`. + +### 20.8. Kiedy taki wariant miałby sens dla Peyi + +Dziś najbardziej realistyczne parenty dla Peyi to: + +- `Salvium` +- `Zephyr` + +Jeśli jednak w przyszłości Peya urosłaby na tyle, że: + +- `Salvium` byłby zbyt małym parentem +- a nawet `Zephyr` przestałby być wystarczającą bazą bezpieczeństwa + +to wejście w bardziej dojrzały tor: + +- `Monero -> Peya` + +mogłoby mieć sens. + +W takim scenariuszu rozbudowa o: + +- `Monero -> Tari + Peya` + +stałaby się ciekawym wariantem strategicznym. +To nadal wymagałoby nowej warstwy integracyjnej, bo obecny `peya-merge-mining-proxy` obsługuje tylko jedną aux chain. Nie byłby to jednak problem wspólnego template dla wielu parentów, tylko problem obsługi wielu aux chainów nad jednym parentem.