Thank you for your considered comments on this topic.
After reading the material presented for the last meeting I would like to have some guidance on what concern we are addressing.
I think @Lorimer goes close with this statement “the lopsided risk/reward relationship for NPs that would seek to exploit or do harm to the IC” …
Is there consensus that this is the concern? I am assuming there is at this point.
If this is so, then it seems that the proposed solution to this concern is that NP’s must be independent. OK and if this is the solution then it can be seen that the rest of the discussion follows down this path. First up is that the only solution to address this concern, and secondly even if independence is mandated by specific rules _ i can’t see how this stops NP’s if they wanted to “exploit or do harm to the IC” banding together at a future point in time ..
I would like to see an analysis of :
How can clustered NP’s working together with > 42 Nodes exploit or do harm to the IC?
What is the risk of this happening ? Can a risk calculation be done and if so can it then be monitored?
Are there other ways to mitigate this risk other than imposing independence ?
So simply put what is the intent of prohibiting NP’s clustered together with more than 42 nodes woking together … there are many reasons why this is a the good thing.
History shows us that the more you legislate the more holes you create the more time you waste applying the legislation. Its not all bad but I would sway towards less is more rather than more is better.
Thanks @bls_sigmature, but you’d have to elaborate for me to be clearer about what you mean.
I think so. Node Providers need to be disinclined to collude (in such a way that the subnet is no longer faithfully executing instructions as intended, thereby allowing funds to be stolen etc.). Even if they’re considered ‘independent’ they could still contact each other and collude (it’s just less likely).
Confidence about independence is necessary if subnets are to be as small as 13 nodes, otherwise you may as well do away with the subnet and just have one node.
I agree.
We need proof of stake (something measurable that is risked by Node Providers that break rules). It needs to be commensurate to what they’d stand to gain by breaking those rules and colluding. It would also be worth having a scheme that rewards Node Providers for foiling a collusion plan.
However how would this work in the real world? Node providers purchased the hardware and as far as anyone in the real world is concerned they own it and have access to it in the data center that they contracted.
Leaving (physical?) access rights to one side here, but can’t we already revoke a node provider’s benefit by NNS vote? We can put a proposal to remove a node provider, or we can put a proposal to set a node provider’s rewardable nodes to zero (or specific nodes to zero).
I don’t there’s a way to confiscate a Node from a Node Provider (against their will), and assign it to another Node Provider. That’s what it would take for a node to be considered ‘stake’.
How do remote hands already work in the real world? If a Node Provider can assign temporary access rights to remote hands, shouldn’t the NNS be able to assign (and revoke) access rights to an NP?
Remote hands are data center employees and they would normally only touch a server if directly instructed by the person who made the data center contract. And no matter what we may assign on the NNS, the data center has a contract with a physical person, the node provider, not with the NNS. Any physical access to a server would only be granted by the data center to a third party if instructed by the person who they contracted with. Data centers have very strict security protocols.
Given the above, I doubt this would be executable in the real world.
Also some further clarification on what remote hands do. They don’t have BMC password access to the nodes, they would normally only carry out certain tasks if instructed, like if a server needs a hard reboot, they can flip a switch. If a cable has come loose, they can replug. If a fan fails, they might be able to carry out such simple repairs (this can vary though).
If this suggestion is found to not be workable in practice, as you indicate, then in my mind the only sensible solution is proper proof of stake. This goes back to our earlier discussion.
Hi all,
please find here a second forum post with proposals for enhancing network decentralization. Feedback is very welcome! We suggest discussing these proposals in the node provider working group meeting on April 14.
Thank you for joining the Interim Node Provider Working Group call. You can find all relevant resources (minutes, slides, and recording) here.
The next working group meeting is scheduled for May 5th at 4 PM CEST. I’ll be sharing more details about the agenda closer to the date.
As discussed on the call, the conversation around the proposed maintenance standard could continue in a dedicated “Special Interest Group” running in parallel to the main WG. If you’re interested in participating or following these discussions, please react to this message with a so I can gauge interest.
If there’s enough traction, I’ll follow up with more details on how the breakout group will be organized.
The Node Provider Working Group meeting has been postponed by one week and will now take place on May 5th, as many will be returning from the Easter holidays.
The calendar invite has been updated, and previous announcements will be revised accordingly.
Thanks for joining the last NP WG meeting! All the meeting material can be reviewed here.
The next session will be on the 26th of May, 4pm CEST. More details on the agenda will be shared closer to the date.
Thanks to those who have already reached out to express their interest in participating in the pilot program for the Independence Assessment. If you would like to participate, please reach out to me via Element: @louisevelayo:matrix.org
This month’s working group meeting will be skipped due to a holidays. Also, a few of the updates that were planned to be shared will be more ready in a couple of weeks.
As a result, July’s meeting will be moved up and will now take place on July 14 at 4:00 PM CEST.
We’ll be covering:
Update: Concentration tooling
Update: Performance-based node rewards
Meeting details are below. Looking forward to seeing you all then!
so I can gauge interest.
Hello all,