it’s started making me wonder how easy it could be for a node provider to own multipe nodes under different identities/entities, with the intention of eventually having full control over a subnet (controlling > 2/3 of the nodes), i.e. a sybil attack.
Technically, this risk is why every subnet cannot have more than one node with a single node provider. Each subnet being spread across nodes around the entire world also works against this risk, as it would be signficantly harder for a node provider to set up legal entities in many countries and form DC contracts in many countries. We encourage the community’s engagement with this topic!
The biggest requirements to become a node provider are both the funds to buy the servers (which can easily run $10k per server) and have the technical ability to manage nodes. Many people have one but not the other. The biggest issue with requiring a large staking amount is that it would raise the cost to become a node provider even higher than it already is, since any funds that are staked could not be used to purchase servers. (But one could argue that spending $100k on servers that are highly specialized for the use of the Internet Computer—and signing data center contracts which typically run for a few years—provides a similar type of “sign of dedication to the IC” as staking. The only realistic way to gain that money back through rewards is if the IC continues to grow. I do not think we currently have any way to slash someone else’s staked ICP, though someone else can correct me if I’m wrong.)
I think this would still be achievable if the motivation, means, and incentive is there. Maybe not too concerning at this point, but in the future, when there are many more subnets and NPs, I think there really needs to be a protocol-level mechanism that can do a better job of disincentivising bad actors.
Maybe stake slashing isn’t necessary, but a significant ICP neuron that’s max staked, owned by each NP (or perhapse special NPs, for which there need to be a certain proportion per subnet) seems like an absolute must.
I actually think every NP should have a known neuron. This is a neuron that they could use to demonstrate alignment with a proposal that affects them (to get around the potential for impersonation on forums that aren’t on-chain).
The problem with the second is this… to a NP who is already putting up $500k in cash to buy servers, what amount of ICP to stake would be significant compared to that? If they’re willing to “waste” $500k, then it stands to reason that the staking should be even more… but would it be good for the ecosystem if a NP had to stake another $500k in ICP? That’s $1 million! How many legitiment, honest NPs have that?
I don’t really understand the need for these two concepts. It doesn’t seem like we need node providers to provide a stake that gets slashed or a large neuron. I also don’t see how this would solve any problems. If we are just worried about the same node provider creating multiple identities, then why not strengthen the KYC requirements, sign legal compliance agreements, and/or conduct detailed compliance audits? Non-compliance violations could have the consequence of the individual node provider remuneration getting slashed (partially or fully). Is this not what is already planned or in progress?
I personally think this is comparing apples and oranges. The servers are expensive not because they can be used as IC nodes, but because they’re sophisticated hardware capable or generally useful compute. If the IC network crashes, is attacked, or otherwise damaged, those servers would continue to remain expensive pieces of hardware. The same can’t be said for staked ICP (that’s the point of proof-of-stake).
I’m thinking that if the IC is to be a world computer, there shoudn’t need to be a dependency on off-chain systems and structures. If all of those things you mentioned are handled on-chain, then they then become exposed to the attack that they’d be intended to prevent.
A world computer needs a protocol-level solution to these sorts of challenges, for the sake of dependencies and scalability. Proof-of-stake is a highly effective protocol-level incentive alignment mechanism.
Those are valid points. I support the principals myself, if only we could find a way to make the barrier to entry for NPs easier for very real, very honest, technically capable people who want to be NPs. There are a lot more honest people who want to support the IC who do NOT have a million dollars then there are poeple who do. I don’t think hosting IC nodes should belong only to the wealthy, because let’s be serious… does wealth guarantee that a person is honest? No, it doesn’t.
Proof-of-stake, and decentralised systems in general, aren’t about guaranteeing the behaviour of individual entities.
I agree that the barriers to entry shouldn’t be too high for NPs (or it would hurt scalability). But scalability shouldn’t be prioritised over robustness. I think you could have both by having two tiers of NPs. As longs as more than 1/3 of the nodes in a subnet are backed by a large proof-of-stake, then you have a significantly more robust subnet than one where the nodes are not backed by a large proof-of-stake.
Nothing like 19 addtional subnet membership proposals to review over Xmas Stay tuned for reviews…
Update: On reflection, and following @timk11’s lead (who makes a very good case) I will be rejecting the vast majority of these proposals.
I consider this action to be consistent with my Reject-if-you-can’t-verify Policy Today is Xmas eve, tomorrow is Xmas, and then Boxing Day. I don’t have time for due diligence on proposals like this (though I would make time if they were critical).
Hey @katiep@sat@SvenF why were 20 Subnet Management proposals submitted 2 days before Christmas? That means that the 4 day voting period falls on a national holiday (which typically involves seasonal activities with family and friends) for all our reviewers in each of their respective locations. Why are these proposals critical to happen now? What problem would it create if the CodeGov team (@ZackDS@timk11@LaCosta) decides to reject due to insufficient time for reviews? DFINITY and @Lorimer could still review and vote if you have time and it would still trigger execution if you decide to adopt. We are aware that these proposals intend to remove cordoned nodes, but why is that critical enough to submit over a global holiday?
Well put @wpb, I was wondering the same thing and felt inclined to reject on this basis. They don’t seem like critical proposals at all. The voting period hasn’t even ended for the prior batch of 20 subnet membership proposals that got submitted a few days ago…
It takes time to review each proposal properly. Submitting them in avalanches like this (which just keep coming) seems inappropriate. I dont see where the fire is (what was the rush to get these proposals out?.. the day before xmas eve…)
I’ve voted to reject the full set of proposals for this reason. (I’ll come back to look at the dead node properly. That one’s fair enough.) I’m surprised that this happened, given that Dfinity made a specific choice to pause non-critical IC-OS proposals over the holiday period. I fully support them having a break like this, as well as agreeing with the patch proposal that was largely aimed at avoiding unnecessary holiday call-outs.
Thank you for raising these concerns @wpb . The timing of the proposals was indeed a misunderstanding on our part—apologies for that. Typically, we aim to submit proposals on a Friday to allow community members to review them over the weekend during their free time. The assumption was that having more non-working time available would be preferable for the community. Clearly, that assumption didn’t hold here—lesson learned.
In this case, there was an initial sense of urgency due to some subnets having over one-third of their nodes cordoned, which posed a risk of stalling subnets if those nodes were taken offline unexpectedly. However, since the last batch of ~20 replacements, this urgency has been significantly reduced. There wasn’t strict urgency anymore, but we proceeded with the submission under the impression it might actually be more convenient for reviewers. Apologies for any confusion or inconvenience caused by this decision.
To clarify, the proposals were submitted on Monday and will expire on Friday, both of which are working days. Reviewing a single proposal should only take a few minutes, so if you do review the proposals, we kindly ask that you spend no more time on this than necessary.
We apologize for the overlap with the holiday season and will work to improve communication and scheduling for future submissions.
Hi @Sat, could you clarify what it is for a node to be considered cordoned (in particular, what determines the moment in time when a node transitions from non-cordoned to cordoned?).
Surely nodes should be removed from subnets before there’s a tangible risk of the NP intentionally taking them offline randomly. My understanding was that this is what cordoning those nodes essentially is about.
OMG, sorry I didn’t know you spend so much time per proposal. We should optimize that. Your reviews are outstanding but 20 minutes per proposal is just too much IMHO.
Why a node would be cordoned? Typically this would be requested by the NP themselves or by other authoritative community member. These nodes may still be healthy but for some reason (explained in the link) should not be used in subnets.
What is done for cordoning? Nodes are not to be added to subnets, and if possible should be removed from subnets. That is, they should be in the unassigned/awaiting state.
Do you have a suggestion? In my experience this is how long it takes to check all the things that need checking, and to then consider all of those things together, and to then cast a vote, and to then post your review. It can take significantly longer (including the follow up discussion) for complex proposals with unintended side effects.
As a side note, this is a good time to point out that this proposal topic is heavily underfunded. Compare it to the Node Admin & Participant Management topics (for example).
Stay tuned for reviews…
Today is Xmas eve, tomorrow is Xmas, and then Boxing Day. I don’t have time for due diligence on proposals like this (though I would make time if they were critical).