This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Pool Merge Mining Notes

Ten dokument zbiera robocze założenia dotyczące kolejnej warstwy nad działającym merge miningiem:

integracji poola z peya-merge-mining-proxy
UX dla minerów
modeli podziału nagród
użycia whitelist signerów
możliwej przyszłej roli oracle

To nie jest jeszcze spec finalna. To jest uporządkowana mapa decyzji i ograniczeń.

1. Punkt Wyjścia

Warstwa bazowa działa:

Monero -> Peya
Zephyr -> Peya
Salvium -> Peya

Adaptery parent chainów są już zaimplementowane po stronie Peyi.
Proxy umie zwrócić parentowy blocktemplate, przyjąć parentowy submit i równolegle spróbować zbudować aux block dla Peyi.

To oznacza, że następna warstwa nie jest już problemem konsensusu, tylko problemem:

pool integration
accounting
UX
polityki payoutów

2. Rola Proxy Wobec Poola

Najważniejsza zasada:

proxy zachowuje się wobec poola jak parent daemon

To znaczy:

pool pobiera z proxy parentową templatę
pool liczy parentowy PoW
pool submituje parent-style block/share do proxy
proxy dopiero po swojej stronie próbuje zrobić z tego aux block dla Peyi

Praktyczne konsekwencje:

getblocktemplate z proxy jest parent-centric
difficulty, seed_hash, blockhashing_blob, blocktemplate_blob, height są parentowe
adres podawany przez pool do parentowego getblocktemplate powinien być adresem parent chaina
adres aux chaina nie jest podawany per share, tylko siedzi statycznie w proxy jako --aux-wallet-address

3. Co Pool Może Udawać, A Czego Nie

Pool może częściowo ukryć przed minerem, że pod spodem chodzi o parent chain, ale nie wszystko da się bezpiecznie zaspoofować.

3.1. Rzeczy, które można spoofować lub opakować UX-owo

branding poola jako pool Peyi
payout account oparty o adres Peyi
identyfikator użytkownika/minera w bazie poola
prezentacja statystyk, sald i payoutów w Peyi
warstwa frontendowa i opisy coinów

3.2. Rzeczy, których nie należy spoofować

realny mining blob
seed_hash
faktyczna share difficulty
parent context potrzebny do hashowania
pola joba używane przez minera do składania wejścia PoW

W praktyce oznacza to:

pool <-> proxy musi gadać parentowo
pool <-> miner może wyglądać bardziej „Peya-like”, ale sam job nadal jest parentowy

Czyli z perspektywy technicznej miner nadal kopie parenta.
Z perspektywy UX można mu jednak pokazać, że uczestniczy w kopaniu Peyi i dostaje rewardy w Peyi.

4. Adresy I Tożsamość Minera

W poolu adres minera nie musi być tym samym co parent mining address.

Możliwy model:

miner łączy się do poola podając adres Peyi
pool używa tego adresu jako:
- identyfikatora użytkownika
- celu payoutów
- klucza statystyk
parentowy adres miningowy może być trzymany po stronie poola lub proxy

To jest ważne, bo pozwala zbudować UX:

„kopiesz Peyę”
„saldo masz w Peyi”
„wypłaty dostajesz w Peyi”

nawet jeśli realny job pod spodem jest jobem parent chaina.

5. Jaki Typ Bloków Widać Na Chainach

Rozróżniamy trzy klasy wyników:

aux-only
parent-only
dual

5.1. Aux chain

Na Peyi widać każdy blok wydobyty przez merge mining, bo aux block zawiera aux header.

To dotyczy:

aux-only
dual

5.2. Parent chain

Na parent chainie zwykle nie widać osobnego znacznika, że blok był równolegle użyty do aux miningu.

Praktycznie:

parent-only wygląda jak zwykły parent block
parentowa część dual też zwykle wygląda jak normalny parent block

Wniosek:

aux chain wie, które bloki są merge-mined
parent chain zwykle nie rozróżnia tego jawnie

6. Model Poola Zorientowany Na Peyę

Sensowny model produktowy:

miner UI/UX-owo widzi Peyę
pool rozmawia z proxy parentowo
payouty dla usera są w Peyi
reward z parenta jest traktowany jako dodatkowa warstwa ekonomiczna

To rozdziela:

protokół kopania
prezentację produktu
mechanikę wypłat

7. Proponowany Model Podziału Nagród

Poniżej zebrany został model, który wydaje się spójny ekonomicznie i technicznie.

7.1. `aux-only`

reward z Peyi idzie normalnie do minerów
podział według udziału hashrate/share w poolu

7.2. `dual`

część rewardu z Peyi idzie normalnie do minerów
reward z parenta może:
- w całości iść do treasury
- albo być częściowo zamieniany na Peyę i rozdzielany do minerów jako bonus

7.3. `parent-only`

naturalny kandydat do zasilania treasury Peyi
może finansować:
- rozwój
- listingi
- marketing
- infrastrukturę
- buybacki lub airdropy w Peyi

7.4. Efekt UX

Miner:

kopie „Peyę”
dostaje bezpośrednie wypłaty w Peyi
może też dostawać dodatkowe bonusy w Peyi wynikające z monetyzacji rewardów parentowych

To jest spójna narracja, o ile accounting jest jawny.

8. Warunek Krytyczny: Pełna Przejrzystość

Taki model będzie działał tylko wtedy, gdy pool nie zrobi z tego czarnej skrzynki.

Trzeba jasno raportować:

które rewardy pochodzą z aux-only
które z dual
które z parent-only
ile rewardów parentowych trafiło do treasury
ile sprzedano/zamieniono na Peyę
ile wróciło do minerów jako bonus

Jeśli tego zabraknie, minerzy łatwo uznają treasury capture za ukrytą opłatę.

9. Czy Jeden Pool Może Przełączać Parent Chain W Locie

Teoretycznie można by próbować, praktycznie nie warto.

Powody:

parent chain to nie tylko inny endpoint RPC
zmienia się:
- parser blocktemplate
- składanie blobów
- hashing semantics
- address validation
- helper library (node-cryptonote-util)

Najzdrowszy model:

jedna instancja poola = jeden aktywny parent

Czyli:

pool-peya-salvium
pool-peya-zephyr
pool-peya-monero

10. Rozdzielenie Mining Source Od Chain Observer

W obecnym peya-nodejs-pool została już zrobiona pierwsza potrzebna zmiana architektoniczna:

stary moduł daemon został rozdzielony na:
- miningSource
- chainObserver

To jest celowe przygotowanie pod merge mining.

10.1. `miningSource`

miningSource odpowiada tylko za:

polling getlastblockheader
pobieranie getblocktemplate
dostarczanie jobów do workerów poola
submit ścieżki miningowej przez aktywny backend kopania

Docelowo ten moduł ma gadać z:

peya-merge-mining-proxy dla trybu MM
albo zwykłym daemonem dla trybu solo

10.2. `chainObserver`

chainObserver odpowiada za obserwację chaina, który pool raportuje użytkownikowi.

W modelu MM ma on dalej patrzeć na lokalny peyad, bo to aux chain jest produktem widocznym dla użytkownika:

height
block history
payout context
stan sieci Peyi

To oznacza, że w docelowej architekturze:

mining path idzie przez proxy/parent backend
reporting path zostaje na lokalnym peyad

11. Nowy Model Konfiguracji Backendów Kopania

Pool ma teraz przygotowany cienki resolver aktywnego backendu kopania.

Nowy model konfiguracji:

daemon pozostaje obserwowanym chainem
chainObserver może jawnie wskazać endpoint obserwacji
mining wybiera aktywny backend do jobów i submitu

Przykładowa struktura:

{
  "mining": {
    "active": "solo",
    "backends": {
      "solo": {
        "enabled": true,
        "type": "solo",
        "host": "127.0.0.1",
        "port": 37777
      },
      "salvium": {
        "enabled": false,
        "type": "merge-mining",
        "parentCoin": "salvium",
        "host": "127.0.0.1",
        "port": 37777,
        "walletAddress": "SC1T_PARENT_POOL_ADDRESS_HERE"
      }
    }
  }
}

11.1. Znaczenie pól

active:
- nazwa aktywnego backendu
enabled:
- prosty kill-switch dla danego profilu
type:
- solo albo merge-mining
host / port:
- endpoint używany przez miningSource i submit bloków
walletAddress:
- adres przekazywany do getblocktemplate dla parent chaina
- przydaje się w MM, gdy pool pozostaje Peya-centric, ale parent template wymaga parentowego adresu

11.2. Własność Architektoniczna

To rozdzielenie pozwala zachować dwa tryby pracy bez kolejnej przebudowy:

solo
merge mining przez wybrany parent

I robi to bez mieszania:

obserwacji aux chaina
z endpointem, z którego pobierane są joby do kopania

12. Zakładany Model Operacyjny Dla MM

Pool ma kierować na już istniejącą infrastrukturę, a nie sam ją składać.

Oznacza to:

osobny lokalny peyad
osobne parent daemony
osobne instancje peya-merge-mining-proxy

Sama konfiguracja poola wybiera tylko aktywny backend:

solo
salvium
monero
zephyr

Logika walletów:

payout address Peyi pozostaje w poolu
parentowy walletAddress może być podany w backendzie kopania
proxy nadal może mieć własny --aux-wallet-address i własny signer key

To utrzymuje pool jako cienką warstwę nad gotową infrastrukturą MM.

13. Pierwszy Runtime `pool -> proxy -> Salvium -> Peya`

Pierwszy realny run peya-nodejs-pool -> peya-merge-mining-proxy -> salviumd + peyad został już potwierdzony lokalnie.

Setup testowy:

parent:
- lokalny salviumd testnet, height 1605+
aux:
- świeży lokalny peyad testnet z --fixed-diff 10, podniesiony ponad aktywację MM
mining path:
- pool mining.active = salvium
- mining.backends.salvium.host/port -> peya-merge-mining-proxy
observer path:
- chainObserver i daemon dalej na lokalnym peyad
miner:
- xmrig w trybie stratum przeciwko poolowi

Wynik:

miningSource pobiera parentowy template z proxy
pool przyjmuje share od minera
pool submituje blok przez proxy
rośnie parent height
rośnie aux height

W jednym z potwierdzonych punktów runtime:

Salvium:
- 1605 -> 1606
Peya:
- 203 -> 205

To jest pierwszy potwierdzony działający tor:

xmrig -> peya-nodejs-pool -> peya-merge-mining-proxy -> Salvium + Peya

13.1. Co realnie trzeba było poprawić

a) Proxy RPC nie jest pełnym daemon RPC

peya-merge-mining-proxy nie implementuje getlastblockheader, ale implementuje /get_height.

Skutek:

miningSource musiał dostać fallback:
- najpierw getlastblockheader
- potem /get_height

To jest różnica interfejsu proxy względem pełnego daemon RPC, ale na ten moment wygląda na lokalną różnicę pollingową, nie na szerszy problem kompatybilności.

b) Parent backend musi mieć pełne własne parametry miningowe

Samo przełączenie endpointu na proxy nie wystarcza.

Backend parenta musi mieć własne:

coin
symbol
cnAlgorithm
cnVariant
cnBlobType
includeHeight
isRandomX
opcjonalny walletAddress

Bez tego pool dalej próbuje traktować parent job jak job Peyi, co rozwala parser i hashing path.

c) Dla Salvium właściwy `cnBlobType` to `15`

W praktyce to był ważny runtime blocker:

Salvium parent backend ustawiony na cnBlobType = 0 idzie ścieżką monerową i kończy Failed to parse block 2
po przestawieniu na cnBlobType = 15:
- convert_blob(...) działa
- construct_block_blob(...) działa
- pool runtime przechodzi

Wniosek:

konfiguracja MM backendu nie może dziedziczyć ślepo aux-chainowych parametrów Peyi
parent backend musi być traktowany jak pełny coin adapter

Zmiana parenta powinna oznaczać restart instancji lub uruchomienie innej instancji.

10. Problem `node-cryptonote-util`

Na dziś istnieją co najmniej dwa praktyczne warianty utila:

wersja MoneroOcean obsługująca XMR i Zephyr
wersja Salvium obsługująca Monero i Salvium

To oznacza, że pool support dla różnych parentów nie jest tylko kwestią configa.

W praktyce rozsądne są dwa modele:

10.1. Jeden fork poola + jedna warstwa adapterów

jeden fork poola
własna warstwa adaptera nad różnymi utilami
jedna instancja poola per parent

To jest najbardziej elastyczne, ale wymaga więcej roboty inżynierskiej.

10.2. Jeden fork poola + osobne build/profile per parent

jedna wspólna baza kodu poola
osobny build lub config profile dla:
- Monero
- Zephyra
- Salvium

To jest prostsze operacyjnie.

Na start to wygląda rozsądniej niż runtime hot-switching.

10.1. Updated Practical Direction

Po pierwszym wejściu w kod poola kierunek został doprecyzowany:

nie robimy osobnego utila dla Peyi
aktywny cel to wspólny util Salvium + Peya
util ma być rozwijany już teraz jako warstwa adapterów, a nie jako zbiór doraźnych ifów

Dlaczego:

Peya jest dużo bliżej Salvium niż Zephyr jest Monero
obecne rozjazdy między SAL i PEY okazały się punktowe
najważniejszy dotąd rozjazd był konkretny:
- aktualny Peya blocktemplate_blob po HF13 zawiera ogon blokowy z has_aux_header
- stary util Salvium tego nie parsował
to jest typ różnicy, który dobrze pasuje do wspólnego utila z adapterami per coin family

Wniosek roboczy:

node-cryptoforknote-util-salvium powinien ewoluować w util salvium-family
później można dołożyć kolejne adaptery, w tym ewentualnie Zephyr
nie należy zakładać, że blobType 15 oznacza dokładnie jeden format bloku

10.2. Solo Pool Baseline Is Done

Warstwa poolowa ma już osiągnięte minimum bazowe bez merge miningu:

local Salvium -> pool -> xmrig
public Salvium testnet -> pool -> xmrig
local Peya -> pool -> xmrig

To daje dobry punkt startowy przed osobnym branch-em pod:

integrację poola z peya-merge-mining-proxy
klasyfikację parent-only / aux-only / dual
politykę payoutów dla merge miningu

11. Czy Wiele Pooli Może Jednocześnie Kopać Różne Parenty Dla Peyi

Tak.

Możliwy jest układ:

pool A: Monero -> Peya
pool B: Zephyr -> Peya
pool C: Salvium -> Peya

Wszystkie jednocześnie karmią tę samą aux chain, czyli Peyę.

W praktyce:

każdy pool ma własny parent
każdy pool ma własny proxy/signer
wszystkie konkurują o kolejne bloki Peyi

To jest naturalny multi-parent merge mining ecosystem.

12. Restricted Merge Mining I Zaufane Poole

Obecny model restricted MM bardzo dobrze pasuje do dopuszczania zaufanych pooli.

Schemat:

operator poola dostaje swój mm-auth-key
odpowiadający pubkey trafia na whitelistę w Peyi
proxy tego operatora podpisuje aux headery
Peya akceptuje MM tylko od signerów z whitelisty

To pozwala:

selekcjonować operatorów
dopuszczać tylko poole rozliczające w Peyi
wykluczać podmioty, które psują UX lub accounting

To jest model permissioned merge-mining operators.

13. Ograniczenie Dzisiaj: Statyczna Whitelista

Na dziś whitelista pubkeyów jest statyczna.

To oznacza:

łatwo dodać whitelistę w kodzie
trudno ją zmieniać operacyjnie bez releasu
brak prostego mechanizmu deautoryzacji istniejącego poola

To nie blokuje startu, ale ogranicza elastyczność operacyjną.

14. Przyszła Rola Oracle

Jeśli oracle ma i tak rozprowadzać pricing_record, może w przyszłości przenosić też whitelistę MM signerów.

To jest naturalne rozszerzenie, ale trzeba pamiętać:

whitelista signerów staje się wtedy danymi konsensusowymi
musi być równie rygorystyczna i deterministyczna jak pricing_record

Oracle-fed whitelist mogłaby przenosić:

listę aktywnych pubkeyów
wysokość aktywacji pubkeya
wysokość wygaśnięcia lub deautoryzacji
opcjonalnie metadane operatora

Bezpieczny model:

ostatnia poprawna whitelista pozostaje ważna do kolejnej poprawnej aktualizacji
chwilowy brak nowego update’u nie zatrzymuje konsensusu

15. Pomysł Anty-51% Oparty O Oracle

Padł pomysł, by oracle obserwowało także hashrate pooli i odcinało im merge mining po przekroczeniu np. 51%.

Koncepcyjnie brzmi dobrze, ale jest dużo bardziej ryzykowny niż sama whitelista.

Powody:

hashrate poola to estymacja, nie twardy fakt konsensusowy
może się szybko zmieniać
pool może rozdzielać ruch między kilka signerów lub marek
łatwo o fałszywe alarmy i nadużycia

Dlatego nie wygląda to dobrze jako automatyczny kill-switch.

Lepszy model:

oracle publikuje metryki i flagi ryzyka
whitelista jest aktualizowana ręcznie lub półautomatycznie
progi są miękkie:
- alert przy niższym poziomie
- review przy wyższym
- deautoryzacja dopiero po potwierdzeniu

16. Co Wydaje Się Dziś Najrozsądniejsze

Na obecnym etapie najbardziej pragmatyczny model wygląda tak:

jeden pool instance na jeden parent
pool rozmawia z proxy parentowo
miner UI/UX-owo widzi Peyę
miner identyfikuje się adresem Peyi
payouty idą w Peyi
rewardy parentowe zasilają treasury lub bonusy w Peyi
do merge miningu dopuszczane są tylko zaufane poole z whitelist signerów

17. Proponowana Kolejność Dalszych Prac

Najbardziej sensowna ścieżka rozwoju:

sforkować kod poola
sforkować lub zunifikować potrzebne node-cryptonote-util
uruchomić pierwszy pool instance dla jednego parenta, najlepiej Salvium -> Peya
potwierdzić accounting:
- aux-only
- dual
- parent-only
dopiero potem budować warstwę treasury bonusów i dodatkowych airdropów
dopiero na końcu wracać do tematu oracle-fed whitelist i antykoncentracji

18. Przyszły Podział Backendu Poola Dla MM

Obecny solo-pool zakłada, że jeden daemon endpoint pełni naraz dwie role:

źródło jobów do kopania
źródło stanu chaina do raportowania, statystyk i historii bloków

W warstwie merge mining to przestaje być czyste, bo:

mining path powinien iść przez peya-merge-mining-proxy
reporting i obserwacja aux chain powinny nadal iść z lokalnego peyad

To sugeruje przyszły split backendu na dwa jawne moduły:

miningSource
- gada z proxy
- pobiera parentowe joby/template
- submituje znalezione bloki/share
chainObserver
- gada z lokalnym peyad
- dostarcza height, block history, rewardy i stan chaina do UI/API

Praktyczny wniosek:

obecny daemon.js nie powinien być dalej przeciążany wszystkimi funkcjami naraz
dla MM najpewniej potrzebny będzie osobny moduł przejmujący tylko funkcje miningowe
raportowanie bloków i stan Peyi powinny nadal pochodzić z lokalnego daemona Peyi

To dobrze pasuje do modelu produktu:

miner UX-owo widzi, że kopie Peyę
job pod spodem nadal pochodzi z parent/proxy
block history i statystyki poola nadal odzwierciedlają Peyę, nie parent chain

Robocze nazwy tej przyszłej separacji:

miningSource.js
chainObserver.js

Ten split wygląda dziś bardziej jak warunek sensownej architektury MM poola niż jako opcjonalny cleanup.

19. Krótki Wniosek

Merge mining w warstwie bazowej już działa.
Kolejna faza to nie jest już „czy da się to technicznie wykopać”, tylko:

jak podłączyć pool
jak to uczciwie rozliczać
jak to dobrze sprzedać UX-owo minerom
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.

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.