SYBILing nodes! 😱 Exploiting IC Network... Community Attention Required!

[Jdcv97]

We don’t need more nodes, staking tokens of
Individuals on the same node providers doesn’t help the security nor the decentralization of
The network.

What we need is the same node providers being rotated between subnets, a way to validate that each KYC really matches the REAL identity of the person who say’s is applying as node provider, and with that we can onboard more different node providers.
But NOT MORE NODES, NODE PROVIDERS,DIFFERENT ENTITIES is what work.

Then you need to understand that ICP has in the whole industry the only business economic model that actually works and it’s aligned with traditional cloud computing services, where users pay and they get a service, if this service costs way more then the economic model will be affected, ICP is not a dream and illusion of a network full of useless nodes like on other blockchains just to meet the fantasy narrative and idea of “ a world full of nodes and decentralization “ , that actually doesn’t bring any real value to the blockchain itself, instead more nodes means make everything more expensive removing real world utility to the technology, We don’t need that.

[marcio]

@Jdcv97

We don’t need more nodes, staking tokens of
Individuals on the same node providers doesn’t help the security nor the decentralization of
The network

With that kind of logic, we might ultimately reduce the IC to a single massive server, why have 13 smaller entities when one big one is better and more efficient (as long as it’s KYCed )? I believe every improvement helps, including better KYC.

[Lorimer]

@Lorimer

This would be similar to how the various DFINITY NPs are a special case, with special business rules.

It’s great to see that this has been implemented! Thanks for this @Sat, I noticed relevant comments in the recent Subnet Membership proposal summaries, so I checked the DRE tooling repo and just noticed this →

feat(decentralization): add provider clusters for node linkage analysis (#1338)

Looks like a great change, and a nice way of making progress without needing to wait for this sort of thing to be modelled on-chain in the registry.

Subnet Management - w4rem (System Bitcoin)

Proposal 135839 Review | Lorimer - CO.DELTA △ VOTE: YES TLDR: Removes a node belonging to the ‘George Bassadone’ NP, because he already has control over another node in this subnet (63rak, under his GeoNodes LLC NP) Ideally in future proposals the reason will be placed in the ‘Motivation’ section (currently blank in this proposal summary). However the reason is given by the business rules statement → Business rules check results before the membership change: Node provider clu…

Subnet Management - x33ed (Application SNS)

Proposal 135838 Review | Lorimer - CO.DELTA △ VOTE: YES! TLDR: This looks like a good proposal to me. The node that’s claimed to be offline has recovered (thanks for the detailed explanation @MalithHatananchchige!). Despite this there are some good reasons to adopt this proposal: George Bassadone and GeoNodes LLC are essentially the same NP. The fact that this isn’t currently explicitly captured is a known problem and a solution is being worked on. That doesn’t mean we need to …

I’d also like to thank @borovan for shaking the community into action. There appeared to be little movement on this until he started making some noise

I’d also like to thank all of the NPs who have reached out to provide information and clarifications. There are however, still outstanding questions. I don’t believe anyone at DFINITY has proper answers to this (or none that they’re willing to share). I’m considering if a motion proposal might be needed to make progress with this particular topic. This element has so far received little discussion. →

@Lorimer

I’d like to try and turn attention to a question that has been asked repetitively, but still an answer has not been provided.

1. Why are some node providers feeling the need to obscure the terms of their node transfers to other Node Providers by getting them to sign a non-disclosure agreement about the terms of the node transfer?
2. How can anyone expect the original NP to be fully relinquishing their claim to those nodes under this sort of circumstance?

[Lorimer]

I’ve formulated a theory regarding the above, but it’s unsubstantiated at the moment. Can this be confirmed or refuted by anyone?

I suspect there wasn’t sufficient uptake in terms of buyers for nodes that needed shedding, leaving NPs that needed to shed those nodes with the option of either dropping the price, or establishing a hire-purchase agreement. A hire-purchase agreement complicates the ownership of nodes, which would call into question the “independence” of the NPs. A non-disclosure agreement avoids these details being shared, so that it can’t become a point of contention which might have caused the related proposals to be rejected by the community.

I personally wouldn’t see a big problem with this, as it’s a practical step in the right direction for decentralisation. I think the problem comes with attempting to hide it. In my opinion this is a best-case scenario, but there are worse scenarios (some that fall under the category of ‘asset protection/shielding’). Given this, the presence of a non-disclosure agreement itself (or no comment) should have been reason enough to reject these proposals (in my opinion).

While there’s still uncertainty about what these non-disclosure (and/or no comment) cases are about, I would suggest that the donor NPs and recipient NPs should be considered to belong to ‘clusters’ (and should not reside within the same subnet). If I don’t hear objections, I’ll update my tooling to take this into account, which will inform the way that I vote. This of course largely undoes the point of transferring the nodes away from the donor NP - so I think transparency and clarity are by far preferable (I’m not sure how many times this needs to be requested though).

---

As a side note, I’ve gone through the Declaration of Independence statement for each of the recent transfers, and the wording that’s used is not standardised. Some are short →

Both Existing Node Provider and New Node Provider declare that they do not have any
majority control in each other’s operations.

Some are longer →

Both Existing Node Provider and New Node Providers declare that they do not have any majority control in each other’s operations, financial interests, or governance decisions. Each party operates independently, with no undue influence or control over the other’s activities.

Questions

• If the donor doesn’t have majority control what sort of control do they have?
• Why was there a deliberate choice not to word this as ‘do not have any control’?
• What would constitute due influence (as opposed to the undue influence)?

Someone was responsible for this template wording. Given that this is being used in formal review documents, I think the reasoning for this wording should be elaborated and understood by the community a little better (such as the reviewers who are voting on these proposals and asking the community to follow their votes). Related discussion from a little way back.

[wpb]

@Lorimer

While there’s still uncertainty about what these non-disclosure (and/or no comment) cases are about, I would suggest that the donor NPs and recipient NPs should be considered to belong to ‘clusters’ (and should not reside within the same subnet). If I don’t hear objections, I’ll update my tooling to take this into account, which will inform the way that I vote.

I’ve already stated that I believe this is a good idea.

@wpb

Anyway, understanding the reason that each node provider has felt the need to protect their business or investment with an NDA doesn’t seem like something that will result in a productive outcome. I think identifying the rules and work process that can ensure a higher degree of transparency in the future is the place to focus. In the meantime, establishing relationship clusters is the best idea I have heard so far on how to mitigate the risk of assigning too many nodes from node providers with a relationship to the same subnet.

These clusters could be defined by node transfer parties and assumed relationships, but with no remuneration penalty. The DRE tool could take these relationship clusters into account in the topology targets.

It would be nice if a more complete list of relationships were discussed and agreed to in the form of an NNS proposal. @Lerak made the best attempt at creating this list that I’ve seen so far, but it’s been largely ignored so far.

Technical Working Group: Node Providers

Concerns have been raised in various posts by reviewers and other members of the community about links between Node Providers. These concerns center around the theoretical possibility of too many “linked” Node Providers ending up on the same subnet and the implications thereof. Node Providers are not involved in the allocation of specific nodes to subnets. Dfinity makes these changes, and it gets reviewed by the community when “Subnet Management” proposals are submitted to the NNS. Reviewers …

[Thyassa]

Agreed. I think the community needs to formulate very strict wording and when it can be used, as well as dictating what can and cant be used as valid ID. Ok “the community” is vague, in reality, one or two individuals needs to propose a draft, get feed back and then the community votes. With majority agreement, that is what should be used for all node provider applications going forward.

Too much vagueness and not enough eyes on the ball has meant there is a lot of opaqueness when everything should be clear.

[wpb]

@Thyassa

I think the community needs to formulate very strict wording and when it can be used, as well as dictating what can and cant be used as valid ID.

Have you seen the recommendation made by Karel Frank (@Lerak)? This was part of a very lengthy recommendation they posted 9 days ago after the initial concerns were raised by @borovan and @Lorimer, but it got no attention even when I tried to point it out to Adam multiple times. I think you will find it to be a healthy start. The node providers have already agreed that they want this to be a point of discussion at the next node providers technical working group meeting. Perhaps you can attend and participate in the discussion.

@Lerak

We do need a definition for what we as community regard as a declarable link, as well as penalties, should it come to light that a Node Provider failed to declare a declarable link to another Node Provider. Penalties can only be applied if there are clear rules regarding the links that should be disclosed and the links that are not material.

The following list could be a starting point of our upcoming debate of what would be regarded as a declarable link:

• An effective control share in the operations of another Node Provider - YES
• A minority share in the operations of another Node Provider - MAYBE
• Where the Ultimate Beneficial Owners of the Node Providers are related (detailed definition of related needs to be established) - YES
• Where the Ultimate Beneficial Owners are co-investors in other projects - NO
• Where the Ultimate Beneficial Owners are working or did work together at the same company - MAYBE
• Where the Node Providers in question use the same IT company / “remote hands” for node maintenance - YES
• Where the Node Providers in question use the same Internet Service Provider - YES
• Where the Ultimate Beneficial Owners in question attended the same school. - NO
• Where the Ultimate Beneficial Owners in question both attended the same event at Dfinity talking about the challenges of being a Node Provider. - NO
• Where the Ultimate Beneficial Owners in question attended business meetings together unrelated to their Node Provider business. - NO
• Where the Ultimate Beneficial Owners in question go on holiday with other Node Providers. - NO
• …

This list could go on forever, but I hope to illustrate the need for a well-considered set of rules that determine what “links” Node Provider’s must disclose.

[Lorimer]

@wpb

it got no attention even when I tried to point it out to Adam multiple times

@Lorimer

@Lerak seems to be doing a great job of pushing this idea forward

Wenzel please stop posting long-winded posts that parrot earlier statements and only really serve to bury the questions being put forward.

@wpb

I’ve already stated that I believe this is a good idea

Great, but you’re missing the point of my post.

As pointed out the DRE tooling now has a concept for clusters, but node transfer donor-recipient pairs are not represented. If this is done, it largely undoes the point of the transfers (which was to make the IC Target Topology easier to achieve more consistently - not harder…). What we actually need is clarity about these transfers, and if we can’t get that then I think this is the option that’s left. Please stop posting long-winded fluff unless its pushing the converstation forward rather than dragging it back to things that have already been read, acknowledged and/or praised.

@Lorimer

I’d like to try and turn attention to a question that has been asked repetitively, but still an answer has not been provided.

1. Why are some node providers feeling the need to obscure the terms of their node transfers to other Node Providers by getting them to sign a non-disclosure agreement about the terms of the node transfer?
2. How can anyone expect the original NP to be fully relinquishing their claim to those nodes under this sort of circumstance?

@Lorimer

Questions

• If the donor doesn’t have majority control what sort of control do they have?
• Why was there a deliberate choice not to word this as ‘do not have any control’?
• What would constitute due influence (as opposed to the undue influence)?

Someone was responsible for this template wording. Given that this is being used in formal review documents, I think the reasoning for this wording should be elaborated and understood by the community a little better (such as the reviewers who are voting on these proposals and asking the community to follow their votes). Related discussion from a little way back.

[Jdcv97]

So what are the strategies to validate that the KYC provided is real? This is a really important are to focus on, doesn’t matter the amount of “different node providers “ if we can’t validate that all of those node providers apply with their REAL INFORMATION. KYC DATA CAN BE FAKED!

[Jdcv97]

I’ll keep pushing forward with this, because is a valid concern that Dfinity isn’t providing any solution or answers to this problem. Why? Because they don’t know how to address this is my opinion. As the IC scales this issue doesn’t disappear just becomes impossible to control, there’s no way to after 5 years go and validate if most of the node providers have provided their real IDENTITY, or fake data, so we will not know if the network is about to be exploited or the network is safe. We will have to remove all the node providers or ask them to meet the new requirements by that specific point in time (example, meet in person to validate real IDENTITY, fingerprint, eyeballs) etc

But how we will know the exact time to ask this new requirements? Could be to late or to early? Who knows there’s no way to time where the (possible) attack will happen and for how long this node providers have been colluding and gaining trust across the people in the ecosystem and the foundation.

Knowing there’s no way to validate KYC data is something that doesn’t let me sleep at
Night. @Jan @samuelburri @dominicwilliams

[Lorimer]

Enhancing Network Decentralization - Proposals for Identity Verification and Subnet Allocation

Introduction During this quarter, several discussions have taken place in the forum on network security and decentralization. Valid concerns regarding node provider governance and the subnet allocation scheme have been raised. As indicated earlier, we have taken the action to review how to best capture these connections and consider them in subnet allocations, taking into account the constructive feedback received in the current discussion. This forms the scope of this forum post. Additional con…

[LaCosta]

LaCosta | CodeGov

I have voted to reject all proposals regarding the removal of Node Providers.
I don’t like the approach that has been followed and I think there is no need to rush to conclusions specially with the Node Providers that were mentioned. This has been a race to make proposal after proposal with no undeniable evidence.
Also, I don’t think it’s the best move to give voice to people who behave unprofessional even when provided with reasonable arguments.
I’ll be reviewing the next proposals with the some ideals. DFINITY has moved to using clusters implemented in the dre tool and even though the current Node providers in clusters were really linked I think it’s necessary to discuss how clusters will be decided if this is seen as the best move forward.

Edit: better wording

About CodeGov

CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these technical topics. We also have a group of Followees who vote independently on the Governance and the SNS & Neuron’s Fund topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron, KongSwap, and Alice with a known neuron and credible Followees.

Learn more about CodeGov and its mission at codegov.org.

[alexu]

Hi @borovan !
IMHO Henrique suggested that rushing this process wouldn’t lead to good outcomes, like jumping to hard quests unprepared. Here’s an approach I think would work better:

1. Clearly define which Node Provider behaviors or situations constitute a breach of trust.
2. Discuss and ideally draft a motion proposal for the community to vote on.
3. After the motion is approved, present evidence demonstrating that provider X exhibits these trust-breaking behaviors.
4. Submit formal motion proposals to remove the provider based on this evidence.

And BTW, the Foundation started working on 1. See Enhancing Network Decentralization - Proposals for Identity Verification and Subnet Allocation and what’s to come.

[borovan]

Yeah I saw that. These two providers obviously breached the rules, or their documents were lost, or whatever. They have absolutely no presence on the internet.

Those will be the last ones I submit in that way, I just don’t want to lose 50 ICP

Very excited to see how the whole process is iterated upon.

[borovan]

It’s some sort of logical fallacy, don’t know which one. Appeal to Authority mixed with Tu quoque?

[LaCosta]

I did indeed mean were colluding (were linked would have been a better wording) as mentioned by @alexu when I previously asked about this.

@alexu

These proposals swap a few nodes belonging to a set of Node Providers out of the critical subnets, treating them as single “cluster.” This connection among the Node Providers is public information, declared by the group (Geonodes LLC, George Bassadone, and Bianca-Martina Rohner) themselves: George and Bianca are both linked to Geonodes LLC due to co-ownership.

[snoopy]

I fully agree with this approach. And I am not at all convinced that there has been any “colluding” at all, nor do I think we have a definition of what “colluding” even is. There were node provider rules when these people onboarded, and one needs to look at whether the rules that were in place at the time were followed. One can then say that further rules need to be stipulated going forward and this should be set by and agreed by the community. But I don’t think it is constructive to demonize people who have done nothing wrong based on the rules that were in place when they onboarded. I don’t think there should be any “ex post facto” rules set up, and rather we should follow the principle that everything that is not explicitly prohibited is allowed. Nulla poena sine lege.

We can have a constructive discussion on setting up further rules around node providing of course and come up with a robust system that is endorsed by the community.

As regards clusters, again, to me I don’t see any ill intent and nothing in the rules in place at the time prohibited that. And I would encourage everyone to also think about the fact that people who were targeted in this witch-hunt have actually been quite forthcoming, and if someone had truly wanted to hide sth, they could have done so from the start. The easiest things to find are the ones not meant to be hidden…if you can see it, it’s not really hidden.

[snoopy]

Which 47 fake node providers are you even talking about? I don’t recall anyone “fake” having been identified. There has been some dashboard admin cleanup, mostly of old entities and people with zero nodes anyway, which technically someone with no nodes is not a node provider…

[snoopy]

The very first node providers were all onboarded by Dfinity through in a completely different process to what is in place right now.

And the only entities removed from the dashboard by you were entities with zero nodes currently, the IC has no fewer nodes now than it did before your cleanup exercise. There are a few more people on the dashboard still with zero nodes, given there is no node provider onboarding anymore and hasn’t been for a year and we have almost 3x as many nodes as are currently being used in subnets, we could remove all those entities with zero nodes from the dashboard for all I care, but that doesn’t mean that anyone fake or malicious has been identified.

[codecustard]

One massive server isnt even feasibly with traditional cloud infrastructure. Scale requires replication to reduce latency and increase redundancy. ICP aligns with trad cloud and takes it further by also using replication for consensus.

Hes right.. More nodes mean nothing for “decentralization” when one entity controls all the nodes. That’s why blockchains use POS instead of POW, because they figure its the same thing in the grand scheme of things.

And in the grand scheme of things ICP basically modeling off real world governance. “Deterministic decentralization”. If it looks like a fish and and it talks like a fish… Its a fish.

Node shuffling? Validator staking? Interesting… But wake me up when we start discussing the KYC and “shell companies” and also dont forget the attack vector of NNS and vote persuasion. Guess people forget that even sound governments can be corrupted… or I guess thats why were finally talking about node shuffling and valkdator staking, . Were awake.

Whatever happened to Utopia. What ever happened to badlands. Lol… ICP got social consensus embeded into the protocol, yet cant even iterate on some ideas so CT gotta invent some narratives on their own tokens.

Gotta love how ppl discussing this or that while blockchains upon blockchains throwing ideas into the wild,

Why all these blockchains with these ideas couldnt be ICP badland network?