Do you agree with ECC's decision to not prioritize having a large number of active validators in choice of PoS consensus algorithm?

not sure if those details have been released, but I’d be surprised if there won’t be an optional “token needed” for stakers.
I hope it will allow for an auxiliary set of validators, i.e. ETH-staking nodes producing blocks alongside potentially higher yielding & naturally less capital-intensive ZEC-staking nodes.

ETH-staking nodes would be fine with less yield-per-node as for them it’s just an additional commitment, yet ZEC’s economic security backing would grow disproportionally.
Here some speculative numbers to illustrate further:

  • ETH currently has close to 500k validators running, much more after Shanghai
  • if just 0.5% were to co-validate ZEC, that would be an additional 2500 validators in our set
  • let’s assume minimum stake for a ZEC validator to be 210 ZEC
  • that would mean network security just became 525k ZEC more resilient; from an arguably biggest capital pool, but considering that ETH nodes have a much higher stake-per-node, their incentives remain sound
1 Like

On the speculation about “what bad game”(?) validators, I point to the same people spamming the Zcash blockchain perpetually. Whoever that cohort is I’d say we should assume that they’re at some point in the future (if not already) capable of attempting to hurt the network using node deployment as their attack vector.

4 Likes

:eyes:

In my opinion, Zcash should use Avalanche consensus, but not become an Avalanche subnet and thus not get the interop benefits. Zcash and the Avalanche ecosystem faces different security risks, and our incentives might not align properly when it comes to stuff like deciding the minimum stake needed to become a validator node, and Zcash is thus better off as a sovereign chain and just copy the consensus mechanism. Interop with either the Avalanche or Cosmos ecosystem should not come at the expense of the resiliency of the Zcash network. I would even support using PoS Nakamoto consensus (I think Cardano uses this) over using Tendermint or becoming an Avalanche subnet.

I think the best path forward for Zcash would be to use Snowman consensus as a sovereign chain. Then in the future we can add a second blockchain which implements private smart contracts with trusted execution environments and require validators to validate both chains just like how in Avalanche you have to validate both the X-chain and C-chain (and P-chain). We could also convert the standard Zcash blockchain to a DAG and use the faster Avalanche consensus like the X-chain does.

2 Likes

Another thing I would like to see discussed is the effect PoS has on the size of shielded pool. All voting based PoS protocols like Tendermint and Avalanche requires the stake to be visible because your voting power needs to be visible. Some cryptocurrencies have like 80% of coins staked, which would severely limit the amount in shielded pools. I think maybe this is not the case if we use PoS Nakamoto like Cardano as I think all coins are automatically entered into a lottery and thus can remain in the shielded pool, but I am not sure if this is correct.

Also the number of validator nodes will have privacy implications for mobile users, because it gives some economic incentive to host your own full node which you can connect your lightwallet client to instead of trusting a third party server.

3 Likes

There has been some research into the impact of PoS on privacy:

We expect that further research into the practicalities of privacy-preserving proof of stake will be published later this year, likely including an examination of the trade-offs between safety, liveness and privacy.

5 Likes

Can you recommend the best way to monitor the count of active and current block height network nodes?

I have used blockchair in the past but found out their information is not correct. (displaying Total nodes: 7,132 at the moment)

1 Like

Just count the v5.4.1, 5.4.0, 5.3.2, 5.3.1, 5.2.0 maybe and zebras

Versions that are deprecated shouldn’t be included in the count.

2 Likes

I didnt check the actual halt dates but yes if theyre deprecated then don’t include them

Thanks HanH, that is my point here. A lot of confusion abounds related to accurately tallying the true active/ up-to-date/ current block height node count for the network.

Does the Electric Coin Company website or Z.cash have correct information?

The current node count is somewhat a red herring since the value prop of running a node changes with staking.

Mining hash rate is currently the metric I watch to get a feel for the network. Asics dominate equihash so you could do some rough math to come up with how many nodes are out there. Each asic costs about as much as staking would i assume based on eths transition.

Zec’s current miner distribution is a way worse problem than the node count being low.
ViaBTC mines 60 out of every 100 blocks. ie One company controls >51% of the network today.

If there is no way to ensure a large distributed PoW consensus, PoS validator size feels moot.

ref: Zcash (ZEC) Equihash | Mining Pools

5 Likes

I don’t understand what you mean by red herring. A blockchain’s full node network is the backbone of its decentralization posit. If a blockchain is sitting atop 15 full nodes all running on hardware-servers in a bunker in Montana, we couldn’t call it a decentralized network, and questioning such a precarious distribution of full nodes should not be marginalized as a red herring.

Dogecoin has 5,010 full nodes running globally (at a variety of builds), and a cute website to let me visualize the global footprint.
Dogecoin Nodes Map! (what-is-dogecoin.com)

Can anyone here tell me how many current block height, non-deprecated full nodes are keeping Zcash alive right now? I’m a non-technical graduate educated community member and I don’t have the capability to sift through all of the technical RPGs that some have provided as a way to maybe if i’m lucky determine what the actual number is.

Knowing how many nodes are running for Zcash is not a red herring. The change to PoS is highly speculative and in a material context will not be completed for 4-5 years. We need a means to know that the network is secure via decentralization and a sufficient layout of full nodes.

2 Likes

It is a red herring because full nodes do not secure the network or provide anything other than the ability for their owners to send their transactions to miners without trusting lightwalletd. Right now the cost of running a full node is a tradeoff between the ever growing hardware and how much a person values helping pass tx through the mempool to miners.

With staking, node operators will earn a reward to run a node. All the pain of having redundant hardware and high uptime becomes worthwhile because the node brings in money. Running a validator is like running a miner where instead of paying for electricity and asics you pay for stake coins.

Today, the only full nodes that matter are the ones run by miners. They earn money to offset hw costs, control which transactions can be put in blocks, and they secure the network. Everyone else running a node is doing it for either the love of the concept of zcash (and could shutdown with no impact to the network) or are ones supporting a service and get money somewhere else to offset the costs.

I dont think knowing the number of hobbyists nodes is necessary when discussing the number of validators, which is why i said it is a red herring. The hobbyists, services, and businesses will still run their nodes after the switch and may or may not be validators.

The nodes on the chart you shared with magic bean 6.x.x is a pos fork of zec and that is why there are so many more nodes.

1 Like

It likely isnt helpful for me to just say ‘trust me, full nodes are a vanity metric’ and hope you take my word for it. This diagram may be helpful in understanding why the node count isn’t helpful to me. This is what I am running on my system, and I fall into the hobbit category I mentioned above. I don’t mine, don’t run a zcash related business, and I don’t let strangers use my endpoints.

Lite Node Front Door
I have between 3-5 zcashd nodes running with pruning on to keep their size to 1gb. They are what connects to the outside zcash network. No RPC, no wallet, no persistent storage. I can scale the number up or down as needed. These nodes are visible to node counters.

Zcashd Pod
I run 2 full nodes that connect only to each other, lightwalletd pod, and lite node front door instances. These would not show up on a node counter. They are what I use for… whatever I need to do.

Lightwalletd Pod
This stack is where my wallets connect. It gives a cool dashboard using grafana.

Storage
I have (8) 4TB HDD and a few SSD for caching. I’m using ZFS for mirroring and can lose a few disk drives with out worrying too much. Off site archives happen nightly so I can spin a new zcashd node when needed.

4 Likes

The effect on the size of shielded pool is an important question. I am an author on the work “On the Anonymity Guarantees of Anonymous Proof-of-Stake Protocols” pointed to by Dodger. From my perspective, there is an inherent relationship between safety, liveness, and privacy properties for any PoS-based protocol, i.e., this implies to finality-preferring designs (e.g., Casper FFG, Tendermint) as well as dynamic availability-preferring designs (e.g., Nakamoto consensus).

At a high-level, here is where the tension between the properties appear. In a privacy-preserving proof-of-stake protocol, stake is used for two different purposes. First, transactions shared on the chain update a parties’ stake (already hidden to other parties by protocols like Zcash). Second, the stake is used to elect “leaders” to participate in the protocol. In fact, to provide Sybil resistance, in PoS protocols, the number of times a party is elected is directly proportional to its stake and thus can end up revealing a parties’ stake. The other two works pointed out by Dodger attempt to hide the leader by making the leader election process anonymous. In our work, we observed that, despite these measures, there are ways in which a parties’ stake can actually be learnt. If an adversary can control a party p’s view at the network layer for a long enough time such that only the party has access to a specific transaction created by the adversary, then the adversary can identify whether party p has created a block. This information can consequently be used to learn the stake of a party.

We are currently working on exploring the attack in more detail as well as potential defenses through techniques such as differential privacy. We will write a blog post soon explaining the details; will post on this thread then. In the meanwhile, here is a preliminary talk explaining our result: CESC 2022 - Day 2 AM Session - Nov 1, 2022 - YouTube

2 Likes

Helping set terminology for this discussion.

You are referring to an important property called dynamic availability. At a high level, it says that the protocol “makes progress”, i.e., it keeps adding blocks to the chain even if a large fraction (say 99%) of the validators shut down. Nakamoto consensus, and consequently, Bitcoin, Ethereum (both PoW version and Eth 2), and Zcash have this property.

On the other hand, finality-preferring designs, e.g., Casper FFG, Tendermint, HotStuff, all require a threshold of parties (> 67%) to participate and make progress and commit blocks. The advantage you get, though is that you will have safety even under network partitions (not something that Bitcoin/Zcash have today) but will not have liveness if a large fraction of nodes goes offline.

A discussion of how both properties can be obtained simultaneously is described in this paper: https://arxiv.org/pdf/2009.04987.pdf

1 Like

While dynamic availability makes a blockchain more resilient from shutdown for sure, I was not only referring to dynamic availability in my comment (unless you count the social layer as part of the protocol). In the comment you referenced, I also meant that I think hard-forking out compromised validators in a finalizing protocol would benefit from a large number of nodes, because the new fork needs a new and robust validator set to validate it, and the more validators the original chain has with hardware already up and running, the more validators the new fork is likely to get.

What about leaderless protocols? Is that where the liveness tradeoff comes in?

Here are my thoughts:
Fundamentally, if a protocol has a leader selected proportionally by stake for each block, then an attacker can just spin up their own validator with a small stake and measure how often they are selected as leader to find out the total amount of stake held by validators. This would separate the ZEC held by validators from the rest of the shielded pool without even attacking specific validators.

The only way around this would either be no leader or selecting the leader not proportional to stake, but by some other mechanism.

Thank you for this details, I have a broad question about node distribution in PoW vs PoS systems. Is it fair to presume that PoS (controlling for all other factors) would yield greater node distribution than PoW? Is this outcome simply the result of ease of access (PoS requiring capital only to acquire stakeable coins, whereas PoW requires both capital, hardware, and favorable energy access).

In its lifetime Zcash has struggled to grow its node base and to create robust node distribution. As @dontpanicburns noted above, Zcash as it currently is relying entirely on the good faith and participation of its PoW ASIC miners. In the future, we would all like to see a Zcash with PoS and a undeniably greater node count, greater distribution footprint, and best aligned material interests (among ZEC owners and Zcash stakers).

That’s fair. Though, at a technical level, the question is whether that is the best measure of security. If yes, how much is good enough? 10? 100? 10000? Perhaps if we view this from an economic standpoint in a PoS setting, where we can argue along the lines of “if there is a safety or liveness violation, then some parties would lose 1B worth of staked coins”, that seems to provide a concrete sense of security (to me).

Meta comment: My response wasn’t necessarily just to that comment, but the entire thread, although, yes, I did end up picking that one.

What about leaderless protocols? Is that where the liveness tradeoff comes in?

What we argued should work for all privacy-preserving stake-based protocols. The intuitive statement we make is: “For any deterministic anonymous SMR protocol that satisfies (1-f, t)-liveness, there exist executions where the parties cannot obtain better than (1-2f)-anonymity” where f is the fraction of malicious stake, and t is the time within which transactions are accepted on the chain. While we prove this for deterministic protocols, unless we use randomization primarily to provide privacy/anonymity, the idea should apply there too.

In general, while we intuitively categorize protocols are leader-based or not, I am not sure of the technical definition.