I wanna know the definition of minimum voting power threshold.

fully support this, with one comment - there were never really any tests with a larger set of validators, which potentially this SIP would bring. To make sure there are not too many validators going in at once, perhaps a max validator set can also be temporarily implemented?

i realize the phased launch is supposed to guard against this as well, but unsure if its enough (in case too many join, and network becomes somehow unstable)

I wanna know the definition of minimum voting power threshold.

The proposal explains in more detail, but the tl;dr is:

• Voting power is computed by normalizing the total amount staked to 10,000 "voting power units"
• A new validator can join the protocol if their delegated stake is sufficient to earn 3 voting power units

fully support this, with one comment - there were never really any tests with a larger set of validators, which potentially this SIP would bring. To make sure there are not too many validators going in at once, perhaps a max validator set can also be temporarily implemented?

This is a fair concern. There have been some tests with larger validator sets (e.g., Mysticeti was benchmarked with 150 geo-distributed validators and continued to perform quite well), but certainly not 3000+.

At the current "market price" for a unit of voting power, I think it would be surprising for large number of validators to join right away (particularly with the phasing scheme). But we can certainly amend the phasing scheme to be more gradual or add a hard cap if folks are concerned about this.

• Note: Using SFDP as an acronym for "Sui Foundation Delegation Program" *

TLDR

Pros

1.- Having more nodes -> increased decentralisation (more resilient and secure)

Cons

2.- possible commissions race to the bottom
3.- diluted rewards for each validator (more stake -> less rewards)

• both of them impacting QoS and contributions

Concerns

4.- possible performance issues (unlimited validator set, poor performing validators)
5.- requirements for new participants in terms of performance and infrastructure (similar to SFDP ones?)

BLOCKSCOPE INITIAL THOUGHTS (Full version)

We think decentralisation is a very desirable thing to have, but needs to be done carefully in order to not end with a very stake centralised network and performance issues as happens in some networks, and thus loosing some benefits of decentralisation.

Pros

1.- Having more nodes -> increased decentralisation (more resilient and secure)

This is great to have specially on a mid/long term vision, specially if plans include competing with other networks like Solana.

The more decentralised the better, so it should be an important goal for the project.

Cons

2.- possible commissions race to the bottom

As there isn't a low commission limit constraint this could end in a race to bottom, started from new participants wanting to escalate in the stake share, specially from nodes with ~100% self stake (whales) that do not need to set a commission because the whole fees end up in node owners hand.

A race to bottom could bring some issues to the network, as other participants (including the ones in SFDP) may be forced to enter the race too, decreasing the rewards and thus bringing unwanted issues like:

- QoS decrease due to spending less on hardware
- Geolocation centralised and non crypto friendly DCs like Hetzner
- Poorer ecosystem contributions due to less budget

A possible solution would be setting a fair low commission limit, to minimise the impact of these issues and create a more fair and sustainable ecosystem for validators. Also, this wouldn't be such a problem once the network usage (fees) or external delegations are enough so validators are not mostly dependant on SFDP.

3.- diluted rewards for each validator

As rewards are yet dependant on stake subsidies and not network fees, the rewards for each validator will be diluted with the stake coming from new participants, and thus bringing the same issues as in previous point (2).

A possible solution would be setting a dilution threshold so that only a new % of total stake may be admitted to join, until a similar share of rewards coming from network usage (fees) are achieved. So that node earnings are not heavily impacted by a big increase in the number of participants.

Concerns

4.- possible performance issues (unlimited validator set, poor performing validators)

Would increasing the number of participants bring performance issues to the network?
Would be great to test and measure on testnet before implementing the increase in mainnet.

5.- requirements for new participants in terms of performance and infrastructure (similar to SFDP ones?)

Would new participants have performance requirements as SFDP participants?

- hardware requirements
- decentralisation requirements and DC constraints (like not using Hetzner)
- fast response time SLAs for upgrades

If not enforced to meet these requirements, we think some measures should be taken to tackle any possible issues. For example, implementing publicly available metrics (for performance, centralisation, etc.) to be included in wallets/explorers so that stakers can choose "healthier" nodes for the network, and thus enforcing node operators to provide optimal QoS, DC distribution and fair commissions. As an example, the Solana ecosystem explorers and Liquid Staking pools implement different scores to encourage performance and decentralisation in their validators.

Hope that this helps.

Your points are well-articulated! Thanks for sharing your insights.
I'll let others weigh in on some of the concerns you mentioned, but regarding the SFDP: In short, this proposal likely won’t bring about significant changes.

The SFDP is designed to make it easier for operators with exceptional operational capabilities to have a meaningful role in the network's governance. The intent of this SIP, in my view, isn't to promote a wide array of smaller validators through the SFDP. Instead, it's to make it more accessible for large, independent stakeholders or smaller groups to spin up their own validators without relying on support from the Foundation's delegation program.

The SFDP will continue to prioritize directing stake towards operators who:

1. Demonstrate operational excellence,
2. Contribute to the ecosystem beyond just running validators,
3. Are responsive and actively engaged in community matters.

Great feedback @packetstracer!!

I wanted to say a bit more about (4):

4.- possible performance issues (unlimited validator set, poor performing validators)
Would increasing the number of participants bring performance issues to the network?
Would be great to test and measure on testnet before implementing the increase in mainnet.

I think we would definitely not want to 10x or 100x the validator set size in a hurry--it's best to grow gradually and mitigate issues as they arise. As mentioned above, Mysticeti was benchmarked with 150 geo-distributed validators without perf degredation, and I think +44 validators is probably outside of what we would expect from this change in the short term.

If performance issues arise due to new individual validators performing poorly, there are two mechanisms available:

• leader reputation via HammerHead https://arxiv.org/abs/2309.12713 to discourage slow leaders
• slashing (of earned rewards, not of principal) via reporting non-performing (e.g., upgrading slowly) validators https://docs.sui.io/guides/operator/validator-config#validator-slashing-and-tallying-rule

Today's validators are excellent operators, so these mechanisms are not much utilized, but they are available if needed.

Thanks for the info @sblackshear !

Didn't know about Hammerhead, LFG for performance mitigation issues.

Just remark that for the long run would be interesting to provide some performance/reputation public metric (via RPC or other) so this could be used to aggregate data and implement scoring in wallets, explorers or analytics sites.

Hey, sorry for being late to the party here. I wrote this up back in July when I was thinking a lot about this problem. It takes a different approach, and since SIP-39 has been finalized, you may just find it to be another (possibly interesting) perspective.

https://obelisk.sh/posts/2024/07/the-operator-layer/

Hey, sorry for being late to the party here. I wrote this up back in July when I was thinking a lot about this problem. It takes a different approach, and since SIP-39 has been finalized, you may just find it to be another (possibly interesting) perspective.

https://obelisk.sh/posts/2024/07/the-operator-layer/

Thanks @wizardfiction! Will take a look

Prototype implementation now here: MystenLabs/sui#19836