From the XMR Decentralized P2P pool linked above, it’s a trustless and permissionless design, so:
Suppose I have a state-of-the-art last generation ASIC Bitcoin miner or HIgh-end server CPU, couldn’t I just split my hashrate to give the impression I’m a bunch of smaller “old” miners and take advatange of the lower difficulty share-chain(s)?
As basic/majority users, I want to send zts token, then i want feeless trx, so i can generate pow mini RandomX share-chain. It can generate pow automatically, just send trx, generate Pow via CPU main RandomX share-chain. Righ?
Then I confuse with fused qsr lane, its basically fusing qsr is a process to generating pow, and we dont need generate pow in future to send trx?
We will have small miners to merge-mine both BTC and any RandomX minable coins on their respective mini share-chains.
User transaction flow:
Feeless lane: proof-of-work generation for transactions
The user computes a RandomX PoW on the mini share-chain to meet the required threshold and broadcasts the transaction.
The tx is propagated throughout the network. It needs to satisfy the PoW links requirement to be valid and accepted by the consensus protocol.
The Sentinel node will pick up this transaction and attach a PoW that can be outsourced to a RandomX miner and sign it.
After that, another Sentinel node will do the same thing until the overall PoW link has sufficient weight (the difficulty target > a minimum threshold computed based on the main RandomX share-chain) and can be included in a momentum by a Pillar node.
Feeless lane: fused QSR for transactions
Instead of computing a RandomX PoW, the user fuses (locks) a minimum number of QSR.
The rest of the flow is similar to 1
Fee lane: burn/consume ZNN for transactions
The user can optionally burn/spend ZNN to issue a transaction