Network of Momentum Phase 1

[Nostromo]

Sentinel is a full node that is tasked with relaying messages a minimum of 3 hops and adds PoW links to each message

Wow, I just had a look at that paper, and it goes way above my head. Very complicated and needs study to understand.

But from what I can gather, this three-hop path creates Sybil resistance and causes nodes to act in a certain way.

This is pure speculation, but we have an anti-Sybil mechanism implemented that isn’t described in the whitepaper at all: Plasma. Could it be that Plasma superseded the PoW link idea for Sybil resistance?

Or maybe the PoW links are used for the Sentinels to keep each other in check and honest? I don’t know; that paper was too advanced to make heads or tails of it for me.

[0x3639]

@Nostromo

Or maybe the PoW links are used for the Sentinels to keep each other in check and honest? I don’t know; that paper was too advanced to make heads or tails of it for me.

“ the PoW link will serve an additional objective in the consensus algorithm, representing an eliminatory criteria to select between two conflicting transactions in case of a double spend. ”

[Chadass]

@aliencoder

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

I’d totally disagree with the Undelegate cost. It’s often about moving from Pillars changing their rewards politic or going offline so why the delegate should bear that cost?

[Nostromo]

That is curious indeed because the whitepaper also states that Sentinels don’t participate in the consensus algorithm. However, it then adds that they create PoW links for transactions, as mentioned on the bottom of page 7.

This is somewhat contrary to your quote. It does make conceptual sense to have it like this to settle a double spend, though.

The question is, how are double spends settled now, without PoW links? Perhaps because it’s currently all very sequential, it eliminates the possibility of double spends?

Perhaps this comes into play in a more asynchronous environment.
Reading the initial lite paper Sharding was mentioned but that seems to now have shifted to Narwhal and Tusk.

I find the Pow links difficult to understand.

[aliencoder]

@0x3639

Are you proposing that 1% of 5000 znn 1% of 50,000 QSR divert to AZ upon revoke

It’s just an example.

@0x3639

We might consider increasing the percentages / amounts initially

I agree, but let’s see what others have to say. Should be kept at reasonable levels.

@Nostromo

Is it worthwhile to devise an incentivization process for remote full node operators if this Sentinel and Sentry dynamic will be implemented?

Sentinels cannot sustain the whole network. They also serve other own purpose: crafting PoW links.

Full nodes can take the role of Sentries. In NoM’s architecture a full node is actually a node participating in the p2p layer. It doesn’t need to store the meta-DAG (consensus layer), that’s why in the whitepaper they are described as “lightweight”. They also service end users (via RPCs).

@Nostromo

And along the same line of reasoning, does the fee lane proposal for dynamic plasma make sense to implement under this circumstance?

@0x3639

We need to reconcile Alien’s latest thinking with the work on Dynamic Plasma.

It does, because there are no incentives for the p2p layer that is critical for any decentralized network.

@Nostromo

where the longest chain is what individual nodes accept as the valid version of the blockchain

@Nostromo

which is separated from the consensus layer.

Good observations. The consensus layer is indeed separated and this is intentional: the transactional ledger gets its weight from PoW that clients (and eventually miners) will generate. In Bitcoin you have the longest chain with the most proof-of-work (created by miners with PoW) invested into it. In NoM, you have the meta-DAG (created by Pillars with PoS) and the heaviest ledger (created by clients and miners with PoW).

@Nostromo

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

Even if 20% of the current number of Sentinels will still exist during Phase 1, I think it will still be OK.

@Nostromo

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.

You’ll need 500k ZNN and 5M QSR (locked capital) and you still need some PoW for the PoW links if you don’t want to incentivize RandomX miners at all.

@Chadass

moving from Pillars changing their rewards politic or going offline so why the delegate should bear that cost

Usually delegators are “reward” hopping. As a delegator, you will do your DYOR twice if you know that undelegation has a cost. It’s not even an upfront cost, so it’s reasonable because you make rewards in the meantime. A Pillar going offline is a rare event, we can treat it as a special situation where the 1 ZNN burn fee won’t apply (because we can check if the Pillar is disassembled or not).

@0x3639

They are a full node and they are incentivized.

There won’t be enough of them. There can be up to several hundred Sentinels in the network (even less because it won’t be profitable to operate one because the rewards are fixed). Bitcoin has tens of thousands of full nodes in the p2p network.

@0x3639

I guess I did not fully appreciate that nodes really don’t offer network security like BTC

Of course full nodes offer security. But not “direct” security like miners. It’s more “political” in the sense that miners can fork Bitcoin, but full nodes can only accept a particular version as the canonical chain. Anyone remembering #UASF during the fork wars? It’s a separation of powers between miners that control the hashrate and full nodes that control chain “vetting”. The same separation of powers in NoM is between Pillars that control consensus and clients - including Sentinels, merge-miners, etc. that control ledger weight.

[Chadass]

@aliencoder

It does, because there are no incentives for the p2p layer that is critical for any decentralized network.

It’s not critical for BTC.

[Chadass]

@aliencoder

Usually delegators are “reward” hopping. As a delegator, you will do your DYOR twice if you know that undelegation has a cost. It’s not even an upfront cost, so it’s reasonable because you make rewards in the meantime. A Pillar going offline is a rare event, we can treat it as a special situation where the 1 ZNN burn fee won’t apply (because we can check if the Pillar is disassembled or not).

You can’t predict pillars missmanagement or suddenly going MIA.

[Shazz]

I suggest we dont tinker with emissions before there’s any usability that can drive growth. Lets focus on stuff that actually matters and finally allows zenon to escape this bubble. The AZ contract is well funded. Demand will offset emissions. Diverting emissions into AZ prematurely is just procrastiation to actually building usability.

[Nostromo]

@aliencoder thanks for answering questions; I understand that this can be time-consuming, so I really appreciate it.

I have been doing a bit of reading, and I’d like to drill a bit further into the Sentries and Sentinel dynamic. I will describe some topology related only to the transactional layer as I understand it, and I’d appreciate it if you could point out errors or add anything of note.

So we have a peer-to-peer layer; Sentry nodes facilitate communication and data propagation. When a Sentry joins the network, it needs to discover other Sentries to establish connections and exchange handshakes. Sentries maintain multiple connections with other Sentries, and the P2P layer creates a dynamic network allowing nodes to join or leave without disrupting overall functionality.

A Sentry node does not require a copy of the entire ledger, as it may reference a pruned version or use a zk proof to reference a ‘checkpoint’ of the ledger. This allows a user to run a Sentry and join the network, bypassing the need to sync and download the entire ledger.

When a user initiates a transaction, their Sentry broadcasts it to the network of Sentries, where it is propagated to all other connected Sentries. They check whether the transaction adheres to the prescribed format and verify the digital signatures.

Sentinels, on the other hand, store the entire ledger and are the source of truth for the transactional ledger. Sentries acquire their pruned ledger from the Sentinels or query the Sentinels via zk proofs for the ledger.

Once a transaction has propagated sufficiently via the Sentries, the Sentinels then add PoW links to the transaction, which guards against a double spend. Once the transaction has sufficient weight, it may be forwarded to the consensus layer to be included in a block.

This is my understanding so far. Is it somewhat accurate? I have some more in-detail questions, but I just want to make sure I haven’t made any huge errors and solidify a baseline of understanding.

[0x3639]

I know this is a question to Alien, but you seem to have some ideas into how Sentries could work. I’ve looked at the white paper trying to understand how Sentries works and it’s pretty vague. Seems like a Sentry is different than a Public node.

What is the purpose of running a node for specific account only? Maybe faster and lighter to run? Seems like we have three actors running similar information: Sentry, Public Node, and Sentinels.

If Sentinels are public full nodes, why run a Sentry? Maybe because they are light and fast and quick. Maybe something that can be run on a phone for my account chain only to send and receive TXs. So why do we need public nodes assuming we have a sufficent number of Sentinels? @aliencoder thinks the public node provides security. But you seem to be questioning that assertion. @Nostromo I think it would be helpful to agree on the function of a public node and their role in providing security.

[Nostromo]

I also thought that it might be something low-impact that users can run. Just now, I have been reading about block lattice structures as I was trying to understand the PoW Link topic a bit better and how it relates to double spends.

I found two interesting points:

1. Block lattice structures inherently prevent double spending as each account chain maintains its own chronological order of transactions. Since transactions are confirmed by the account owner, there is no need for a global consensus mechanism to prevent double spends.
2. Nodes in a block lattice network need to stay synchronized with the state of each account-chain. This can be achieved through a gossip protocol or other mechanisms to ensure that all nodes have a consistent view of the ledger.

Maybe the Sentry nodes are dedicated to account chains, and the Sentinels are dedicated to the overall coherence of all account chains?

Phew, complicated stuff to wrap your head around.

[Nostromo]

This section of the whitepaper spells out the transaction flow and node properties (at the bottom of page 9):

"The flow of issuing a transaction is as follows: a user will have assigned some representative nodes, sentinel nodes that will process their transactions and that can be queried in order to pull new information regarding the account chain or the state of the ledger.

However, in order to prevent denial of service attacks, the queries can require a fee that needs to be applied in order to return a valid response: for example, a user can use the sentinel nodes for querying the state of the ledger or sentry nodes to get updates regarding its account chain.

As we highlighted earlier in the Definitions subsection, not all network participants are also consensus
nodes; only full nodes (i.e. pillar and sentinel nodes) keep both the transactional ledger and consensus ledger"

The language here is quite opaque, but the phrasing of, “query sentry nodes to get up updates regarding its account chain”. That sounds like the account is paired/belongs to the sentry.

*edit: actually I think I misinterpreted that - when saying it’s account chain I think it’s referring to the account chains of the ledger and not the Sentry.

[aliencoder]

@Chadass

It’s not critical for BTC.

@aliencoder

Bitcoin survived because it chose the path of small blocks to safeguard the peer to peer network.

Small blocks represent the trade-off made to preserve the status-quo of the current peer-to-peer network that relies on volunteers around to world to operate and maintain it.

Again, you either don’t read my posts or simply you ignore them. I won’t answer you anymore if you totally ignore what I say.

@Chadass

You can’t predict pillars missmanagement or suddenly going MIA.

I don’t want to predict anything. If a Pillar is disassembled, we can check that and remove the undelegation fee for this particular case.

@Shazz

I suggest we dont tinker with emissions

I agree. We don’t change emissions. We just align all network participants and operations to create a self-sustainable network. This should be the main objective for Phase 1.

@Shazz

I agree this makes absolutely no sense. We need EXTERNAL DEMAND, not additional taxes on existing holders ffs

This is not a “tax on holders”. It is a mechanism to deter spam and create long term sustainability. External demand will come after we finish the main components that will drive utility and continuous growth.

@Nostromo

They check whether the transaction adheres to the prescribed format and verify the digital signatures.

In my opinion Sentries were initially envisioned as light nodes. But they should definitely act as public full nodes that support the p2p network.

@Nostromo

which guards against a double spend

The consensus nodes guard against double spends. The PoW link only represents an eliminatory criteria used by honest consensus nodes to deterministically select which transaction should be included into the meta-DAG for ordering.

@0x3639

So why do we need public nodes assuming we have a sufficent number of Sentinels?

Because we won’t have a sufficient amount of Sentinels. I’ve calculated earlier a maximum number. We need tens of thousands of public nodes for a truly decentralized network.

@Nostromo

Since transactions are confirmed by the account owner, there is no need for a global consensus mechanism to prevent double spends.

The block-lattice can’t prevent double spends on its own, it needs the meta-DAG for consensus (ordering).

Some parts of the whitepaper are a little vague, but remember it is just a draft version. Even Mr Kaine pointed into this direction, especially with the incentivization of the p2p layer.

I have another insight to share about the meta-DAG related to the accumulation of PoW in the transactional ledger: the meta-DAG will be transient, as it will get garbage collected.

“To this end, Narwhal leverages the properties of a consensus protocol (such as the one we discuss in the previous section) to agree on the garbage collection round. Blocks from earlier rounds can be safely be stored off the main validator and all later messages from previous rounds can be safely ignored.” from Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus.

[Nostromo]

In my opinion Sentries were initially envisioned as light nodes. But they should definitely act as public full nodes that support the p2p network.

My question here is, if they don’t possess a copy of the ledgers and don’t participate in consensus per se, can they still be considered full nodes?

In my perhaps idealized view, a Sentry could be so lightweight that it could be incorporated into nearly every type of client, partially eliminating the need for infrastructure providers as every user would have their ‘embedded node’ serving as a gateway to the network.

I understand your perspective in incentivizing public nodes to address the issue of centralized node providers. However, if we had thousands of public full nodes as you propose, how would you devise a system for users to connect to the most appropriate node for them?

Looking at Ethereum, for example, most users simply use centralized node providers. Many may be unaware of it, choosing this option because it’s the default setting provided by their wallet.

How can we ensure that we don’t face the same fate?

[aliencoder]

@Nostromo

if they don’t possess a copy of the ledgers and don’t participate in consensus per se, can they still be considered full nodes

Yes, in Bitcoin full nodes don’t participate into the consensus protocol either - miners do. I don’t know yet if they need to store the entire dual-ledger or only the transactional ledger as the whitepaper states.

@Nostromo

partially eliminating the need for infrastructure providers

Totally eliminating*

@Nostromo

how would you devise a system for users to connect to the most appropriate node for them?

@Nostromo

How can we ensure that we don’t face the same fate?

By incentivizing public full/light nodes with transaction fees as described in the beginning. This way the market forces will keep Infura type businesses out of monopolizing (and centralizing) the p2p layer and ensure QoS for end users.

[Nostromo]

By incentivizing public full/light nodes with transaction fees as described in the beginning

That’s definitely a very interesting idea. How would the incentive be distributed? Would the transaction fee go directly to the node?

[0x3639]

@Nostromo

However, in order to prevent denial of service attacks, the queries can require a fee that needs to be applied in order to return a valid response: for example, a user can use the sentinel nodes for querying the state of the ledger or sentry nodes to get updates regarding its account chain.

In this context, do you think a “fee” represents PoW, Plasma, and/or a fee paid. Maybe you read our discussion on Dynamic Plasma and the extended discussion on fees.

if this includes a fee paid, how do we reconcile that with our marketing efforts of a “feeless” L1?

[Nostromo]

Yeah I think the fee in this context is plasma, as it prevents the denial service attacks.

[0x3639]

@Nostromo

In my perhaps idealized view, a Sentry could be so lightweight that it could be incorporated into nearly every type of client, partially eliminating the need for infrastructure providers as every user would have their ‘embedded node’ serving as a gateway to the network.

If these Sentry nodes existed though the IBD concepts Kaine discussed in TG, why do users need access to full nodes? As questioned here, how do users know which node to select? Why create a new incentive for full nodes if a user can download and confirm their ledger and access the network with a 2” IBD.

Maybe no one is thinking about Sentry nodes because there is very little about them in the WP and they are mostly dismissed.

If I understand this concept correctly, users only need a Sentry to make TXs. And if the Sentry existed, why would a user ever need to query a Sentinel?

[0x3639]

Kaine or someone posted links to BTC IBDs that can be run in a browser take 2 seconds to verify .