Network of Momentum Phase 1

[Nostromo]

If these Sentry nodes existed though the IBD concepts Kaine discussed in TG, why do user need 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.

Yes, if it were possible this way, it would seem preferable in my view and arguably more decentralized.

if the Sentry existed, why would a user ever need to query a Sentinel?

I would think that maybe the Sentry would query the Sentinel on behalf of the user for certain things, the IBD being one of them.

Curiously I just looked up the classical definitions for Sentinel and Sentry
A Sentinel is somebody that stands guard and keeps watch.
A Sentry is somebody that keeps guard and controls access to a place.

[0x3639]

@Nostromo

I would that maybe the Sentry would query the Sentinel on half of the user for certain things, the IBD being one ot them.

Makes sense. How does a Sentry know which Sentinel to query for the IBD or can that be handled on a P2P layer where it’s randomized. I’m looking for that BTC IBD website.

Found these. Messages from Kaine on TG seem to align with your thoughts here

[0x3639]

Found it https://zerosync.org/demo/

[Nostromo]

How does a Sentry know which Sentinel to query for the IBD

I assume that, since all the Sentinels have the same version of the ledgers due to being in consensus, any Sentry could acquire it from any of them. I’m not sure about the protocol’s method for selecting the Sentinel; randomization seems like a good approach.

[aliencoder]

@Nostromo

How would the incentive be distributed?

Check this.

@0x3639

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

Feeless paradigm => Plasma paradigm (credits to @Zyler)

@0x3639

why do users need access to full nodes?

Not every user will be able to run a (public) full node. Even if it’s the lightest node possible. That’s why we have the Sentry concept.

In my opinion a public (full) node is a Sentry.

@0x3639

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.

Because we also need public nodes. And again, not every client will be able to run a node.

[0x3639]

@aliencoder

In my opinion a public (full) node is a Sentry.

Kaine talks about solving the IBD issue in Phase I. He has been talking about that over and over. @aliencoder where does your Roadmap address IBDs? My guess is that solving the IBD issue is more than just allowing public nodes to sync fast. The idea of running an embedded Sentry in any device is appealing. It could serve as the entry point to the network for individual users. Why rely on another public node when you can rely on yourself?

Why can’t something like zerosync be used to run a Sentry node on any device that syncs in 2 seconds. Or Helios from A16Z - a light client that can sync and verify an RPC in seconds.

I dont think a Sentry is defined as a public node in the whitepaper. @Nostromo references the relevant sections of the whitepaper above.

@aliencoder take a look on TG and search for IBD and kaine.

[Stark]

@Nostromo

A Sentinel is somebody that stands guard and keeps watch.
A Sentry is somebody that keeps guard and controls access to a place.

The definitions are probably meaningful. Same as your finding, just different wording:

A sentinel is a lookout, a watchman on the city wall who sounds alarm.
Sentries are guards, boots on the ground.

[aliencoder]

@0x3639

The idea of running an embedded Sentry in any device is appealing

I agree. We should have a light client design. And I have some ideas, but I’ll share them after we have on-chain PoW and the anchoring of the consensus that I’ve talked about. We have many things to accomplish until then.

@0x3639

Why rely on another public node when you can rely on yourself?

Why can’t something like zerosync be used to run a Sentry node on any device that syncs in 2 seconds. Or Helios from A16Z - a light client that can sync and verify an RPC in seconds.

Don’t get me wrong - we should have a light client like Helios. But public full nodes are not light clients. Public full nodes are the p2p infrastructure and we need proper incentivization for its maintenance.

[Chadass]

@aliencoder

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.

There’s no discussion about growing the blocks size for BTC? There’s no forks with bigger blocks ?

@aliencoder

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.

Pillars can set their rewards to 0 or even lower them, pushing the delegator to move, or not. Don’t make it a closed market. Also, I never talked about Pillars disassembling. It seems you don’t read my posts, or ignore them.

[Chadass]

@aliencoder

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.

How is the incentives you’re proposing sufficient for that many nodes?

[0x3639]

@aliencoder

Public full nodes are the p2p infrastructure and we need proper incentivization for its maintenance.

I’m not convinced the White Paper anticipates incentivized public nodes beyond Sentinels and introducing a completely new incentivized pubic node that was not originally anticipated will be difficult and maybe impossible to get consensus on.

[0x3639]

[0x3639]

[aliencoder]

@Chadass

There’s no discussion about growing the blocks size for BTC? There’s no forks with bigger blocks ?

There was a lot of discussion and one solution emerged victorious. A rational solution.

@Chadass

Pillars can set their rewards to 0 or even lower them, pushing the delegator to move, or not.

Here I agree with you. We need to take this into account: setting the reward percentage as a Pillar will burn 100 ZNN, so Pillars will also think twice before enforcing a new payout scheme.

@Chadass

Don’t make it a closed market

How is the market closed? I want a free market more than anyone.

@Chadass

Also, I never talked about Pillars disassembling.

@Chadass

going offline

Going offline can also mean disassembling. If you meant that Pillars go offline aka they’re not producing momentums, delegators should think twice before supporting such a Pillar.

@Chadass

How is the incentives you’re proposing sufficient for that many nodes?

@aliencoder

@Chadass

How does the fee solve the public nodes incentives problem?

Check my previous post .

@0x3639

introducing a completely new incentivized pubic node that was not originally anticipated will be difficult and maybe impossible to get consensus on.

SegWit was approved with 95% hashrate and at the time was controversial.

We should think with an open mind. May the best solution win.

[0x3639]

Our new inquisitor has raised some good questions.

---

FROM ABOVE

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).

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).

---

I don’t think we know many more Sentinels are “better”. Everything I read in the whitepaper and in telegram points to Sentinels, not public nodes, acting as a means for IDB on a “light client” or Sentry. Kaine was designing solutions to current problems in crypto. Central public nodes are a problem. He devised a solution.

Client > Sentry > Sentinel

Why introduce a new incentivized public node that replicates the problems we already have today in crypto? If pillars keep consensus, why do more public nodes provide more security? The nodes are just an entry point to the network (I think).

I cannot find a reference anywhere to an incentivized public node other than to a sentinel. Sentinels and pillars keep the full ledger and are incentivized to do so.

[Zyler]

Just to follow up, I’m saying “Plasma Paradigm” is better than “Feeless Paradigm” regardless of whether ZNN fees are added or not.
Feeless = inaccurate, because to the user it is not feeless. Initial token cost of qsr or electricity/hardware for PoW. It also sounds scammy and makes a percentage of people instantly skeptical as it’s “too good to be true”, which is technically the case tbh.
Plasma = interesting and it’s accurate. They can learn about it and then find out that QSR doesn’t spend, just locks for time … so from a network perspective there is a feeless lane.

We won’t lose any existing holders, there’s only cultists left anyway. And it’s better going forwards. But hey, we’re leaderless, so say whatever you want. But I’ll be referring to plasma paradigm and I will encourage others to do the same

[aliencoder]

@0x3639

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.

Exactly. They represent the balancing of powers within Bitcoin. Miners, full nodes and users (devs and regular users) all have equal powers.

@0x3639

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.

Yes, but Pillars are not alone: we have regular users that add PoW to the ledger.

We will also have miners (same but with more hashpower than regular users), Sentinels that craft the PoW links (with their own set of miners) and full nodes/Sentries (or a lighter version) that should store the transactional ledger that is the heaviest (similar to longest chain of most accumulated PoW).

@0x3639

Kaine was designing solutions to current problems in crypto

And he also was in favor of incentivizing the p2p layer.

I’ll think more about it and come up with my proposal regarding Sentries and full nodes.

[Nostromo]

I’ve been revisiting the lite paper, and it’s fascinating to see how the design has evolved and the functions of Sentries and Sentinels have changed.

In the lite paper, it appears that the initial paradigm was to create an asynchronous sharded network, as sharding was at the forefront of network scaling in 2017. The role of Sentinels was to facilitate inter-sharding communication and validate the integrity of shards.

A Sentry was meant to participate in the pre-approval process of transactions, presumably validating transaction formats and signatures. It needed to provide confiscatable capital to penalize dishonest behavior.

Originally, it seems like a Sentry was a more traditional type of full node, and the Sentinel was modified to be more of a meta node dedicated to the coherence and communication of shard space.

Interestingly, the lite paper also discusses fairness principles that resonate throughout all permutations of the protocol:

1. Fairness of access
2. Fairness of ordering
3. Fairness of timestamping

As we move along the timeline and get to the white paper, it seems that the sharding paradigm shifted, and a block lattice structure was selected for the transactional layer. From my limited understanding, a block lattice is far superior in terms of asynchronous behavior than sharding.

From the white paper: “Every user has its own autonomous account chain that can be updated independently from the rest. The blocks from different account chains acknowledge each other and collectively form a mesh-like structure. Because the account chains can grow concurrently, the throughput can be quickly scaled up. The block lattice has many advantages - scalability, simplicity, and it can be secure provided it is implemented with an adequate consensus algorithm. We have separated the ledger architecture to achieve better complexity and faster processing times when a user wants to query nodes for transactional data.”

With the move away from sharding and into the Block Lattice - Meta DAG paradigm, the roles for Sentries and Sentinels also changed. Sentinels are no longer needed for shard integrity but now seem responsible for the source of transactional truth and lattice integrity and transaction routing.

It also seems that the properties of the Sentry and Sentinel in the lite paper are mostly consolidated into the Sentinel of the white paper. The Sentry has evolved into a trusted node.

Another interesting area of the lite paper is where they talk about digital signatures and using Ed25519 over ECDSA.

I’m not sure what NoM currently uses, but the lite-paper states that an Intel Xeon E5620 2.4Ghz CPU can validate ~100K key pairs per second. I assume that current-day CPUs can significantly increase that number. The point being that if we can expect higher-end hardware from a full node Sentinel, they should be able to process a very large number of transactions.

[Nostromo]

By the by, having a hardware target also seems crucial to get the most out of dynamic plasma.

[0x3639]

I think this is the version you are referring to. It’s not in the main repo. @Nostromo are you looking at the Revised 5/28/18? Maybe I will submit a PR to add to the repo.

lightpaper.pdf