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

[Zane]

I think many issues stem down from the fact DFINITY decided on a particular network topology and configuration pre-genesis and has since stuck to it, with very little to no experimentation on possible alternatives.

This choice was likely made at the time cause they wanted to showcase the protocol’s capabilities to the fullest extent, demonstrating it is possible to build and run full scale applications on it and not just simple ledgers and financial applications.

The problem is simple ledgers and financial applications make up a big portion of crypto’s use cases and in general blockchains’ biggest strengths are resiliency to bad actors and self verifiability, both of which have been either weakened or lost to these performance tradeoffs.

Don’t get me wrong, I’m not saying 13 nodes subnet should not exist, after all until a huge breakthrough is made, they are the only possible way to run more complex applications in a decentralized manner. But they should not be the ONLY option, the one size fits all approach rarely works out, a hybrid one is much better and offers more flexibility.
A ledger or a DEX don’t need 500GiB of state, nor require 2MB ingress messages for transactions, if anything those actively work against such applications since the latter effectively reduces the unique user generated TX/s the network can support and the former makes decentralization enhancing features, like node rotation and light nodes, harder to implement.

[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.