Network of Momentum Phase 1

Development
1

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:

  1. Feeless PoW lane with dynamic difficulty adjusted based on a weighted average of the CPU-friendly share-chain.
  2. Feeless QSR fusing lane.
  3. 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”.

7 Likes
2

How does the fee solve the public nodes incentives problem? At which volume of tx VS number of nodes it becomes an actual incentives so you can pay 30$ per month and run a nodes on a VPS? Let’s say there’s 10 times the amount of tx we have now per day and all uses fee VS 1 node to incentive, is that 30$ or is the node operator actually losing money?

Also is Narwal and Tusk part of the Phase 1?

3

Check my previous post.

Do you even read posts? I’ve already answered this here.

Yes. The more I read about DAG consensus, the more I’m impressed with Zenon’s whitepaper: “We construct DAG-Rider in two layers: a communication layer and a zero-overhead ordering layer.”. The consensus protocol will run on the meta-DAG.

4

How much time you think will be needed for the implementation part?

5

Once I finish the architecture and specs, I hope we can shift most dev effort into it.

NoM Phase 1 will be a game changer for the L1 landscape. It will obsolete all “scalable” L1s.

5 Likes
6

Do you have an estimate of time needed ? I’m simply curious here.

7

Can you summarize the “how” for this in 1-2 sentences for Hypergrowth efforts?

8

I can give you once we are all on the same page.

I want to finish the post and then you can feed the content into ChatGPT. The key takeaway is that the majority of L1s are based on inferior proof-of-stake consensus and broken incentives - that’s why even Ethereum with near unlimited funding and support wasn’t able to scale. They realized that scaling on L1 is a mirage by moving the problem on the shoulders of L2s.

1 Like
9

Instead of creating an architecture for fees to pillars and delegators, is there not a way to allow those with extra QSR to fuse some plasma as a service?

10

Inspired by the ZTS issuance mechanism that burns 1 ZNN in order to be able to create a new ZTS token, the bridge fee system and how the Pillar slot mechanism works (Pillars have a disincentive to disassemble their node because by doing it they basically waste all their invested QSR), I’m proposing the following operations to create long term sustainability (replenish AZ funds) and achieve mint-and-burn equilibrium for both ZNN and QSR:

Sentinel revoke => 1% rewards ZNN & QSR redirected to AZ (or fixed amounts)
Stake revoke => 1% reward ZNN redirected to AZ (or fixed amount)
LP unstake => 1% rewards ZNN & QSR redirected to AZ (or fixed amount)

Why? It creates a disincentive to abandon the network (revoking, unstaking means that you will no longer have skin in the game) and at the same time, a little part of what you’ve gained from the network will go into its long term sustainability efforts (Accelerator-Z).

Please notice that I’ve excluded Pillars because they already sacrifice a lot of QSR to create the Pillar slots in the first place and are operating critical network infra (including the bridge infra and potentially extension chains). Also miners and full nodes that have real world upfront costs in terms of electricity and hardware.

ZTS token issuance => 1 ZNN burned
Undelegate => 1 ZNN burned
QSR unfuse => 1 QSR burned

Why? Disincentivizes frequent change of delegations and potential spamming using the QSR lane.

2 Likes
11

Hi aliencoder, this is a huge thread. I’m a beginner dev who just started learning Flutter with the hopes of contributing to s y r i u s in the future.

There is a lot going on in this thread, with each area deserving a lot of thought. I have many questions, but I will restrain from bombarding you all at once.

The first question I have is: What is a Sentinel?

There is a recurring theme in your thoughts about incentivization. It seems that a portion of the minted ZNN and QSR is being dispensed by the Sentinel contract every day without tangible network contribution.

This is a peculiar situation. Either there is an intended purpose for a Sentinel yet to come, or those emissions could be used elsewhere more effectively.

An idea that seems cool to me (though I have no scope on the realities of the implementation) would be to have Sentinels as full nodes. Because of the incentive, it would be reasonable to target higher-end hardware. This could allow end users to run ‘light’ nodes as access points.

Economically, this could make sense as the price of ZNN and QSR rises against BTC and fiat, it becomes progressively more lucrative to run a Sentinel, causing more to come online to meet the demand.

Additionally, one could devise a system where the Sentinels keep each other honest and punish dishonest nodes.

From a layman’s perspective, this seems like it could work, but I’m sure there are probably some glaring flaws here.
I’m eager to read your views on this and your general thoughts on Sentinels as well.

3 Likes
12

100% for this AZ funding mechanism. Was always concerned about relying solely on the goodwill of donations.

1 Like
13

Have a look at the white paper: https://znn.link/whitepaper

14

Are you proposing that 1% of 5000 znn 1% of 50,000 QSR divert to AZ upon revoke? Seems like a small price to pay. We were talking about diverting 50% of emissions to AZ in TG a few days ago. We might consider increasing the percentages / amounts initially and then phase them down over time.

15

Hello, sir. Yes, I have read the whitepaper, and it provides a fairly vague description.

I suggested the idea above based on how nodes are described in the white paper. Sentinels are portrayed as trustless nodes that act as observers, requiring moderate resources. Additionally, there are Sentry nodes, described as basic nodes that are lightweight and store a pruned ledger. This setup closely resembles the one I described above.

All things considered it’s worth noting that the whitepaper is labeled as a draft, and there has been some deviation from it with the implementation of the alpha net.

The alphanet wiki is intriguing, as it defines a Sentinel as a full node in the “definitions” section ( znn-wiki/definitions.md at master · zenon-network/znn-wiki · GitHub ).
In the “deploy” section, it states, “The znn-controller works only for Pillars for the moment. Sentinel support will be available after Alphanet launch.”

So, the question arises: Is it worthwhile to devise an incentivization process for remote full node operators if this Sentinel and Sentry dynamic will be implemented?
And along the same line of reasoning, does the fee lane proposal for dynamic plasma make sense to implement under this circumstance?

1 Like
16

Good question. Sentinels are expensive to launch 5,000/50,000. If the goal is to have lots of them, we probably cannot rely on sentinels alone as public nodes. We discussed that here. Read that thread.

Read this post. I don’t think the fee lane is fully vetted yet. We need to reconcile Alien’s latest thinking with the work on Dynamic Plasma.

17

Sentinels are expensive to launch 5,000/50,000. If the goal is to have lots of them, we probably cannot rely on sentinels alone as public nodes.

The central question is whether the goal is to have many Sentinels, how many are considered enough? It is not immediately obvious that more equals better.

Bitcoin, which I just looked up, has an estimated 13 thousand full nodes in the network. They help create consensus, where the longest chain is what individual nodes accept as the valid version of the blockchain. At least that’s how I understand it.

However, we don’t have that design. Our Pillars agree on what the valid version of the blockchain is. As far as I can tell, our full nodes serve as a medium for the transactional layer, which is separated from the consensus layer.

So, in that sense, the question remains: how many Sentinels does one need for network stability?

The cost to launch a Sentinel is crucial as it protects from economic attacks, it makes it very difficult for an attacker to launch 100 Sentinels at once, for example.

A large benefit for prospective operators is that the cost is redeemable when a Sentinel is revoked, making a Sentinel profitable after the first day (In ZNN & QSR scope).

1 Like
18

Devs are considering this possibility.

19

@aliencoder I feel like I’m at the risk of seeming like I’m trying to throw a spanner in the works of your ideas.

I want to express that I think the BTC mining pool on the share chain or extension chain is an incredible idea! I’d love to see that fleshed out and am keen to learn about merge mining and how this could be implemented.

20

Best ideas win around here so I’m curious to see where this conversation goes.

Regarding your question about what is a Sentinel. As I understand it, a Sentinel is a full node that is tasked with relaying messages a minimum of 3 hops and adds PoW links to each message. Alien posted some recent research into this idea and why it’s valuable. Maybe you read that paper.

So my original question was, why can’t the Sentinel serve as an incentivized public node in the network. They are a full node and they are incentivized.

I guess I did not fully appreciate that nodes really don’t offer network security like BTC. So if that is the case, why are more nodes better? Why aren’t Sentinel nodes enough as the main public node in the network. And how many Sentinels are necessary to perform the message relay function and to act as a public node?

I’ll look at the white paper again to try and learn more.

1 Like