Network of Momentum Phase 1
Solving Dynamic Plasma, merge-mining, PoW links and positive incentive feedback loops all at once.
Prepare mentally before reading this post.
Disclaimer: it’s still work in progress.
Objectives
During NoM Phase 1, we aim to attain the following goals:
- Establish a self-sustaining network by fostering positive feedback loops that will attract users and builders.
- Implement a balance between ASIC-friendly and CPU-friendly Proof of Work (PoW) algorithms as outlined in the whitepaper.
- Incorporate the recording of PoW onto the block-lattice for our fork selection algorithm.
- Encourage adoption by integrating a hybrid multi-lane fee system into the network.
The concept of peer-to-peer mining pools was introduced to decentralize the mining operations for any given proof-of-work blockchain. The concentration of hashrate into the hands of a few centralized pools is dangerous for a number of reasons.
Properties
By integrating the first decentralized, peer-to-peer (merge)-mining pool for Bitcoin & RandomX and several other algorithms, we aim to enhance the following properties that are at the core of our shared ethos:
Censorship-resistance
There is no centralized server to steal hashrate, impose a certain block template for example mining empty blocks in Bitcoin or even worse blacklisting certain transactions. We already see that centralized mining pools in certain jurisdictions can be targeted and forced to comply.
Decentralization
By communicating exclusively through the peer-to-peer network, miners coordinate by working on a share-chain. If properly implemented, it can be as efficient as a centralized pool.
There is no pool admin: attacks by rogue pool operators on Bitcoin are no longer possible.
Moreover, miners with older ASICs can turn them on even if they have a lower hashrate and contribute on a lower difficulty share-chain and still be profitable.
Merge-mining BTC & ZNN
By directing hashpower to NoM, miners will earn ZNN rewards from Pillars. We need to divert ZNN away from delegators in order to be able to properly incentivize miners and lay out the foundation for Phase 1.
Bitcoins will be generated. TSS will be leveraged for a decentralized custody of the freshly mined BTC. ZNN will be backed by physical BTC. This positive feedback loop aims to encourages participation and further decentralizes the distribution of the hashpower.
Ledger weight
In Nakamoto consensus, participants choose the heaviest chain that has the most hashpower invested into it. The share-chains obtained with PoW will be embedded contracts with account-chains that will add up to NoM’s ledger weight and be used to “anchor” the consensus as described in the whitepaper.
Dynamic difficulty
Here comes into play the CPU-friendly PoW algorithm: a separate share-chain based on RandomX (can be merge-mined with Monero) where miners can generate share-blocks. This share-chain will be used to compute a threshold for the dynamic difficulty for PoW (CPU-friendly) feeless transactions.
PoW links
Sentinel nodes relay only transactions with a minimum amount of (RandomX) PoW. Transactions (account-blocks) must have the minimum PoW threshold to be accepted by the network and further relayed to other Sentinel nodes. This creates a competition to “mine” transactions in order to be able to successfully route them through the network. Sentinels should be paid on the amount of transactions they have routed in any given epoch. Remember Sentinels generate both ZNN and QSR. Interesting design choice. (work in progress)
ZNN fee
In order to achieve global scale and global adoption, clients submitting transactions should be able to avoid computing PoW, especially if they are on battery powered devices. Fusing QSR requires PoW, so we must adopt a third option that will take into account another critical aspect of a healthy network: incentivizing the peer-to-peer layer comprised of full nodes. Therefore, clients should be able to attach a ZNN fee to their transaction that will be divided downstream between all the full nodes that propagate the transaction. Initially I’ve proposed burning the fee, but it doesn’t solve the incentive problem of full nodes that are costly to operate and much needed for a decentralized and censorship-resistant p2p layer.
Stay tuned for the next chapter: the implementation (work in progress).
Network participants
- Pillars: generate ZNN
- Sentinels: generate ZNN & QSR
- Delegators: generate ZNN
- Stakers: generate QSR
- Liquidity Providers: generate ZNN & QSR
- Miners: generate ZNN & QSR
- Full nodes: generate ZNN
In NoM Phase 1 there will be two new first class network participants:
- Miners: supply hashpower to the network. They will be rewarded in ZNN and QSR (redirected from delegators, stakers and Sentinels)
- Full nodes: the backbone of the p2p network that relay transactions. They will receive ZNN for relaying transactions throughout the network.
Open questions:
- Perpetual AZ funding: how to replenish AZ funds?
- ZNN burn: we cannot burn part of the fees because we sabotage the sybil-resistance property of the p2p layer.
Implementation
In order to actually implement those ideas we need to build upon several building blocks.
Primitives & Building Blocks
Threshold signature scheme
Required to hold and spend BTC in a trustless manner. Top Pillars will run a FROST / ROAST / Sparkle TSS ceremony to jointly create a key for the decentralized custody of the BTC. We can either integrate this directly into znnd or into the orchestrator binary.
The on-chain BTC will be used to pay for block space e.g. to create tapscripts.
The Pillars already run full znnd full nodes and must also run the bitcoind full node to communicate with the peer-to-peer Bitcoin network.
Merge-mined share-chain
A new embedded contract for the share-chain. Embedded contracts have an account-chain structure that is suited to host a share-chain.
The share-chain is basically a separate blockchain that is merge-mined with the target blockchain. In our case we have Bitcoin (ASIC-friendly, used to add weight to the ledger and Monero (CPU-friendly, used to compute the minimum difficulty for feeless transactions via PoW).
The best part is that our network already has the data structure required to build the share-chain: the account-chain of the embedded contract. Also the account-chain is guaranteed to have ordering by NoM consensus. This is important for accounting purposes, such that miners that participated and created valid shares (account-blocks) are incentivized by Pillars with delegation rewards.
- Bitcoin merge-mining: embedded contract for
SHA-256d
ZNN is backed by BTC, so it means that miners are already are paid in BTC (if ZNN will be redeemable in BTC) and also capture the potential upside of ZNN. If ZNN rewards aren’t enough, we can set a flexible payout in BTC for the top x% miners that contributed with the most hashpower to the network during a given epoch. Pillars can independently access and attest this information from the embedded contract. It really boils down to how much hashpower we can attract on the network. We have the possibility to setup two competing merge-mined share-chains and only reward extra (with BTC) the highest difficulty share-chain. From what I’ve analyzed, Monero implemented this concept (mini-share-chain) where small miners (up to x hash/s) can participate. The idea is to avoid the variance caused by miners with more hashrate and the payouts will even out on longer timeframes.
Dynamic difficulty algorithm
- Monero merge-mining: embedded contract for
RandomX; due to incentive incompatibility, I suggest implementing 2 share-chains lite and max depending on the miner’s hashpower. The difficulty algos will be computed such that all PoW transactions must satisfy the current difficulty.
Hybrid multi-lane load balancing algorithm
Load balancing algorithm that will dynamically adjust the size of transaction lanes based on ongoing user traffic:
- Feeless PoW lane with dynamic difficulty adjusted based on a weighted average of the CPU-friendly share-chain.
- Feeless QSR fusing lane.
- Fee lane with ZNN that goes into the incentivization of full node transaction routing.
Routing algorithm
We can borrow ideas from here to create a new incentives layer for the peer-to-peer network of full nodes that relay transactions.
PoW links
Sentinels must attach a PoW to every transaction and relay it to another Sentinel node before reaching a Pillar. This PoW can be outsourced to miners. Sentinels will compete for RandomX miners, creating a new economy around this model. Sentinel operators will be able to setup off-chain reward mechanisms for miners adding weight to the PoW links. We must also take into account the additional data that is added to every transaction. Sentinels should use an aggregate signature scheme - “reducing message size in secure routing protocols such as SBGP”.