Hi Bianca,
Iād find it helpful if you could explain your motivations for onboarding under multiple identities (as a business, as an individual, etc.). Could you also comment on the naming conventions used for the various ā¦23 accounts, and the other commonalities among these accounts - several of which Iāve highlighted.
Hello Lorimer and everyone else,
Iām Maria, Director of Engineering at DFINITY. Since Sven is leaving DFINITY, Alex (@alexu) and I will be taking over his responsibilities. Weāll be working closely with Katie on decentralization and Node Provider (NP) related initiatives. I was deeply involved in launching the ICP network and am excited to return to this topic now that the network has grown so much. Alex joined from the Infrastructure Security team and has worked on these topics from security PoV. So his background is definitely a great fit for this discussion.
Thank you to Lorimer and other community members for thoroughly reviewing proposals and conducting independent research on node decentralization. It really shows how committed you are to ICPās security and success.
Regarding your questions about specific Node Providers, I think itās best to let them address those concerns directly here.
As youāve noted, the issue is broader and the network security should not just rely on any business relationships between NPs and DFINITY.
We appreciate your willingness to collaborate on improving the current approaches to incentivizing, onboarding, and auditing NPs. Balancing incentives, tracking business relationships, and keeping entry barriers manageable is not simple, but there are potential technical solutions. Staking, slashing, and geolocation tracking have been raised in other threads, though we havenāt yet seen any detailed proposals.
I suggest we continue exploring these ideas during the next Node Provider Working Group meeting, which should take place toward the end of February. It will be more productive if we can propose concrete suggestions by then. On our side, weāll work on some proposals and share updates on the projects started last year. We can also use dedicated threads for follow-up discussions, technical feedback, and progress reports. If you have some suggestions - they are of course very welcome!
Thank you again for your efforts, and we look forward to working together on these important issues.
Im confused why do we require kyc to on-board node providers when we have no mechanism to verify authenticity of those node providers in a trustless decentralized way ?
Let just remove kyc and replace with staking (maybe start with staking monthly rewards for a certain time)
Maybe apply to existing node providers, and think for another mechanism for new or upcoming node providers
Without it, achieving deterministic decentralization would be impossible.I completely agree that the process has room for improvement.
I am also a strong advocate for implementing staking and slashing for node providers to ensure additional economic security.
For overall subnet security, efforts should be made to implement node shuffling. This would enable shared security, ensuring that each new subnet contributes to the networkās security, something that is not currently the case.
Part of the process is that new node providers must upload a self-declaration document and an identity document to the IC Wiki (not a personal wiki) and provide the hashes of these documents for verification. In my review process, Iāve maintained an expectation that the hashes should be included in the text of the NNS proposal for adding the new NP. This, however, does not necessarily prove the authenticity of these documents. In some jurisdictions (e.g. Delaware) it is very easy to verify the authenticity of a company document whereas in some other jurisdictions it is very difficult or impossible. I note that even this kind of check does not necessarily prove the identity of the individual(s) behind the business entity concerned.
Some while back I queried whether some sort of KYC process could be involved here but it was felt that this might not be in keeping with the goal of having a decentralised and trustless network, as well as having its own technical challenges.
So the community has decided to place a limit of 42 on the number of nodes that can be controlled by a single individual or entity, but enforcing this is very difficult and Iām not aware of anything yet in place that can achieve this with a high degree of rigour. I appreciate that you have some suggestions as to how this could be solved. A couple of years ago I took part in a project to address the Sybil attack issue in another network. The approach might not be relevant to the issue hereāIāve just included it as an exampleābut it might be possible for some other technical methods to be developed that could help to address this.
Staking isnāt feasible with the current implementation. The IC model is far betterā as slashing for missed blocks wouldnāt work since NPs invest $500K to $1M+ in hardware based on ICās strict requirements. In other networks hardware cost is next to nothing.
IC isnāt just software on a server; itās the OS itself, making it highly secure but limiting NP debugging due to restricted logs. Until logs are more accessible, this approach remains necessary. As there is already mechanics in place discuss here which is more than fair for both network and NP. Reward reduction for misbehaving Nodes
Hi @maria, thanks for introducing yourself. Itās nice to meet you. Iām sad to hear that @SvenF is leaving DFINITY though. I hope you remain an active member of the community Sven.
Thank you for acknowledging the commitment 
I personally think an information gathering/sharing excercise is needed as the first port of call for effective community participation on this topic. Solutions should come from a place of understanding the current state of affairs as best as possible.
Would you be able to co-ordinate with @katiep in publishing the known aliases for all NPs (e.g. @GeoNodes, @tina23, @geeta23 etc.)?
Could you also clarify whether NPs onboarded under multiple aliases is considered permissible? What exactly are the restrictions, particularly in the context of node machine count per NP, and the IC Target Topology? These are explicit and unambiguous, as far as I understood.
Agreed, Iāll await a response from @tina23/@geeta23/@paul23 on my question here.
How would this work for NPs that are eventually found to be aliases for the same person?
Thinking out loudā¦
The NNS is placing a level of trust in what NPs claim during the onboarding process. Perhaps the trust relationship should be more balanced for future onboarded NPs. What if onboarding were a process where NPs place their node machines under the custody of the NNS, such that the NPās legal ownership of the node machines is suspended (until such a that they wish to reclaim legal ownership of the node machine and leave the IC). The node machine itself then becomes the stake, and if the NP is found to seriously violate terms and conditions then the NNS could vote to revoke that NPs right to the relevant node machines, which could then be reallocated to other/new NPs.
Without something like this, how is the IC supposed to handle NPs that are found to represent an irredeemable threat to the network? Additionally, without something like this, what is the disincentive for at least trying to onboard under multiple aliases?
The answer to this seems quite simple. Remove their nodes from participation in the IC and stop paying them remuneration. This is already a risk that they take when they decide to invest in these machines. Why wouldnāt the NNS already take this action if any node provider is found to be nefarious in any way? There is no contract with node providers that protects them from these consequences if they are found to be dishonest.
Because then they would just re-register their nodes under a new identity. The problem is that they havenāt lost anything commensurate to what they gained over the course of their deception. As soon as an NP is removed, the IC will be in need of more nodes, and will be on the lookout for new NP(s).
Becoming a node provider is not freely open to anyone any time. There have been very few instances when new node providers are accepted in the remuneration tables. You and I cannot go purchase node machines and they expect to get added and receive remuneration. Hence, it is not a plausible scenario for them to re-register under a new identity and gain anything.
@Lorimer this is correct, it takes almost 3 - 4 months from acceptance and hardware purchase.
Itās a lengthy process, IC validated before the NP actually submitted NNS proposals including registration and node onboarding. So before the community validated the onboarding Dffinity / IC did checks before from my experience.
The point is that the actor hasnāt lost anything by registering numerous aliases. Theyāve gained the rewards that they recieved for as long as they got away with it. If theyāve already hit the cap for how many nodes theyāre supposed to own, they have nothing to lose by registering more under a new identity. Thereās no stake against which to perform a risk/reward calculation (thereās only reward), unless all of their aliases are exposed simultaneously.
Additionally, if the NNS has to lose the nodes when removing an NP due to irredeemable behaviour, the NNS has to take the hit. This may not even be possible without similarly compromising the network.
Thanks @MalithHatananchchige, can I ask what sort of checks?
By the way, I think it would make sense for there to be a requirement that a node provider list all their aliases and companies somewhere that is verifiable. While there may be no rules (and probably shouldnāt be) against using multiple aliases and business names, it shouldnāt be a challenge to know who is linked to who when checking it against the rules that limit how many nodes a node provider is allowed to operate. I think it makes sense that a node provider would want to create a new business entity in each location and I donāt really see an issue with having multiple forum or other social aliases. Hence, the rules should be tolerant of these scenarios.
They have nothing to gain by doing this either. Registering as a node provider does not entitle you to remuneration. If they are banned as a node provider, then they will be left with a specialized asset that they cannot easily sell for itās depreciated value.
There is an excess of nodes. The NNS does not take a hit if a large number of nodes and node providers are removed. Currently there are at least 77 node chits that could rightfully be allocated that are not being paid remuneration, but the NNS is not suffering in any way.
100%. Itās critical that the IC minimize trust as much as possible. Unique node ownership is one of those things that should be closely monitored and strictly enforced by the community and the NNS. So much of the argument that the IC is sufficiently secured relies on node providers being verifiably unique and independent. If this is not the case, then users of the network have to make whole new assumptions about the networkās security. I donāt like what I am seeing. Thanks @Lorimer for bringing this up.
Hi @tina23, could I chase you on this?
Cool, but why nobody can verify the result of the consensus for each block that being proposed?
Why is such a critical and vital information not public?
If there are blocks being finalized with 66% of nodes of some subnet voting to reject, even so the other 34% dishonest nodes will be able to approve the rogue transactions and nobody will be aware.
And itās being like that since genesis.
Proposed blocks that fail consensus are recorded and impact the rewards that node providers are entitled to. Usually this is related to performance/networking issues as far as I gather.
Failed block rates are reported in the dashboard I linked to. This sort of stuff is actively being worked on and improved as far as I understand. I also think this falls under the trustworthy node metrics (but I could be mistaken).
Note that if over 1/3 of nodes (38% for a 13 node subnet) are dishonest they could stall a subnet, but that certainly would get noticed. Youād need over 2/3 to have control over consenus.
Certainly still a concern if we have SYBILing NPs
The danger is that as far as the IC Target Topology decentralisation coefficients are concerned, the IC is pretending to be there.
This undermines IC Target Topology enforcement, moving from a situation where NP centralisation within a subnet is somewhat visible (assuming honest NP declaration and diligent onboarding reviews), to one where itās not because NPs do not actually represent the āindependentā entities that the target topology assumes (and which was the point of limiting node ownership to 42 per NP).
Distinct business entities do not need to be modelled as distinct ānode providersā on the IC.
Doing this leaves you in a position where you now need to invent a new concept, like ānode provider providersā to represent the group of ānode providersā that can be considered independent from other ānode provider providersā. Alternatively, a ānode providerā itself could simply represent a handful of businesses that pool resources to provide and maintain nodes for the IC. This is what Node Providers are supposed to represent as āindependentā entities.
The reasoning youāre applying to managing this whole affair erodes the integrity of IC Target Topology, rather than strengthening it (which is supposed to have been the purpose). If a limit of 1 node per independent-NP per subnet is not achievable, the IC Target Topology needs updating to avoid masking the problem.
Have you decided this by yourself, or is this DFINITYās official stance? Serious question. Itās based on faulty reasoning, at least in the context of the IC.
The knowledge that enforcement solutions are being worked on and will arrive in the future is a disincentive for offenders. Rules can exist to set expectations, even without immediate enforcement. Even unenforced rules shape behaviour by signalling what is right or wrong.
Hi @maria, are you able to provide an update regarding the state of play with this request? ā
This is neither, just an observation that most law-making entities, when they write those laws, include the funding/means/plan to enforce it.
I think you are (correctly) highlighting one part of the inherant nature of a decentralized system. In order for Node Providers to truly own the nodes, they have to literally have FULL control over the servers, over the access to them, etc. Does the IC own and control the nodes, or do the NPs? I donāt know much about how miners and stakers on other blockchains operate, but how have those blockchains ensure that server owners havenāt given access to other people, who might also have access to other mining servers? Is there anything to be learned there? I know that when someone rents space in a DC, that personāand no one elseācontrols who can access whatever they put in that rented cabinet space.
I think Iāve given you all the context that I have, as well as some thoughts (some of which are playing devilās advocate because I think all sides of the equation need to be considered). I (and I think everyone) agree that there are still risks that need to be mitigated. You are welcome to join the Working Group meetings where some of this is discussed.
I will be traveling over the next two weeks and will not have as much time to dedicate here, but I thank you for your passion for the security of the Internet Computer!