That is a lengthy discussion. You can find the partial answer in the very first message of this thread, and the full answer in this proposal which is the one that this thread was in reference to, and which has even deeper discussions of the topology and why more than 42 nodes is currently useless to the IC.
1 Like
Thanks @katiep, my understanding is that itās driven by the IC Target Topology. The rationale for this topology with respect to NPs is given here ā
Am I correct in understanding the limit is to ensure that no more then 42 nodes are handled by the same independent entity?
Yes indeed. Thatās why the Handover statement is a required part of a Gen-1 NP selling nodes to another business. They donāt seem to have had any problem finding buyers. This is probably because, since Genesis, interest in running nodes has primarily spread through word-of-mouth. I think this is because the IC is still generally new and unknown to most business people, and when people first hear of the prospect of running nodes, theyāre typically not sure what it entails. The risks are also rather high, so when someone knows someone else who is running nodes, it tends to make them more interested and positive about doing it themselves. I assume this is similar among miners for Bitcoin, Ethererum, Solana, and most blockchains.
Anyway, the ecosystem does need some way of quantifying/tracking it when a NP has nodes through more than one entity. I recognize that there are valid reasons for a NP running nodes through more than one business entity. (Wenzel noted that different legal entities for running nodes in different countries is often necessary, and I have also heard of some countries where itās illigal for a NP to run nodes as a business, and yet others where it is unwise for a NP to run them NOT under a business, and people might have many more reasons.) That said, it is definitely in the interests of the IC for NPs to be transparent about these sorts of business connections.
Of course, finding out what someone is purposefully working to hide is a whole different issue and signficantly more complicated than just about anything else, since even if you had every single NP lined up in a room holding their passport, you still couldnāt guarantee that some of them hadnāt secretly been hired and paid off by someone else. The NP working group has discussed this problem a number of times and is still working on it.
1 Like
If this is indeed the reason, can I ask why this is considered permissible? ā
This does not result in 42 nodes being the limit of an independent entity.
On a separate note, Node Providers are an IC concept. Thereās no reason there needs to be a 1 to 1 mapping to a specific business entity, is there?
Simple answer: Weāre not there yet.
Considerations that are contributing:
-
Employees, contractors, DC techs, etc are contractually bound to carry out the direction of whoever is paying them, so thatās different than the OWNER of the nodes who controls the access to the nodes. Of course that doesnāt mean they couldnāt sabotage the nodes that theyāre being paid to keep running, and we realize the risk. But their motivations would be quite different and thus decentralizing the ownership of the nodes was considered top priority. Regardless, the IC has moved FROM the risk of when there was just ONE technician (us) to a much wider variety of technicians, so at least weāre headed in the right direction.
-
Making a rule thate NPs canāt use a technician that another NP is using would be quite complicated, as it would require all the NPs to disclose every single technician that they have so that can be cross checked (manually or technically or with a principal ID or something similar), which means:
-
The community would also have to decide if the NP would need to disclose every technician they ever use, even itās just a remote hands technician in a DC that can only perform limited services, or perhaps a temporary technician who helps set things up and then get his access cut completely. Or does it matter if the technician is a contractor, a DC employee, or an employee of the NP? There are tons of variance here that has been discussed and still needs more discussion.
-
Then thereās the question of how anyone would know if a NP failed to disclose a technician, or allowed someone else to use the credentials of someone who was āapproved,ā etc. Itās typicaly best to avoid making a rule until thereās a way to enforce it. (Iām assuming here that honest NPs would be happy to disclose technicians, and dishonest ones wouldnāt, and itās the potentially dishonest ones who are the ones weād be trying to ācatch.ā Therefore a rule that would be easy for dishonest NPs to break isnāt going to actually accomplish additional security. To be frank, it would have been remarkably easy for Gwodja to have two separate forum accounts for the two posts. It wouldnāt be breaking any rules to do that either, and there are honest reasons he could have had for choosing to do that.)
-
We have over 100 NPs but I donāt think there are yet 100 technicians in the world who know how to run IC nodes. When we launched at Genesis, there was NO ONE outside of DFINITY who knew how to do itā¦ and we were still learning. Weāve come a good way since then, but thereās still not a wide selection of technicians who have this skill set. So while the IC (on the technical level) is more decentralized than if DFINITY was still the only one handling the technical end of node managing, the decentralization still needs to increase on this level. Iām not sure there exists a way to force people to go out and learn the skills and then offer them to NPs though.
Thus, itās an involved topic that does not yet have a clear solution. I think everyone agrees that there is a risk involved here though, and as the IC matures, it must be minimized. But since the IC is still in its infancy, it is, hopefully, not surprising that all of these situations do not yet have solutions.
2 Likes
Iām sorry, Iām not clear about what youāre asking. Mapping what to each business entity?
Proposal #135173 Review ā Louise | Aviate Labs
Vote: ADOPT
Review:
(Gen-1) Node Provider āBlockchain Development Labsā is adding a new Node Operator record for 14 nodes in the BC1 DC. This is inline with the steps to migrate from the legacy deployment method, to the HSM-less deployment method being used by Gen-2 NPs.
- The previous NO record with ID
feb2qshows 14 Gen-1 nodes on this site, which is equal to the allowance being proposed.
- The NP ID belongs to Blockchain Development Labs as they will be retaining the nodes in this data center
- The NO ID being added is new and does not reference any records from other data centers
About Aviate Labs
Aviate Labs is a team dedicated to supporting node providers since 2020. Our mission is to make high-performance infrastructure management on the Internet Computer (ICP) as seamless as possible, while adhering to the principles of decentralization.
We are known for our contributions to the ecosystem, including the go-agent and developer work packages on GitHub, as well as the Node Monitor tool, which alerts Node Providers as soon as any of their nodes go down.
In the NNS, our teamāRoald, Louise, and Quintāreviews and votes independently on āNode Adminā and āParticipant Managementā proposals. Currently we donāt vote at all on other proposals.
The Aviate Labs known neuron is configured to follow our team for these topics and other trusted entities for broader proposals. We strive to be a credible and reliable Followee, committed to voting on every proposal and supporting decentralization within the ICP ecosystem.
Proposal 135075 ā LaCosta | CodeGov
Vote: ADOPT
Removes Node Operators ut325, ampm3 which had their nodes from BO1 and MR1 DCs offboarded which matches the previous proposal 134936.
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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
1 Like
Proposal 135157 ā LaCosta | CodeGov
Vote: ADOPT
As part of the Steps for Gen-1 Node onboarding after 48 months, the Node Provider Allusion is creating the Node Operator zsywq to hold 28 nodes in the br1 DC.
All the required steps were followed:
- A Forum post by the NP
- The self-declaration document was uploaded on the IC Wiki
- The Node Operator ID proposed is new
Currently the NP has a total of 28 type1 nodes on DC an1, 14 type1 nodes on DC br2 and 28 type1 nodes on DC br1 controlled by NO mjeqs-wxqp7-tecvn-77uxe-eowch-4l4gy-6lc6f-ys6je-qnybm-5fxya-qqe which match the proposed number of nodes and the DC mentioned in the proposal. The sum of the type1 nodes held by the NP exceed the limit of 42 for this type of nodes but the 28 type1 nodes from DC an1 will be handed over to a two NPs which will split them equally making the total from DCs br1 and br2 42 following the requirements.
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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
1 Like
Proposal 135158 ā LaCosta | CodeGov
Vote: ADOPT
As part of the Steps for Gen-1 Node onboarding after 48 months, the Node Provider Allusion is creating the Node Operator rpfog to hold 14 nodes in the br2 DC.
All the required steps were followed:
- A Forum post by the NP
- The self-declaration document was uploaded on the IC Wiki
- The Node Operator ID proposed is new
Currently the NP has a total of 28 type1 nodes on DC an1, 28 type1 nodes on DC br1 and 14 type1 nodes on DC br2 controlled by NO oorkg-ilned-36bwb-vyprm-56g55-hp6xq-gucq3-fmn2i-44a4e-txzlp-gqe which match the proposed number of nodes and the DC mentioned in the proposal. The sum of the type1 nodes held by the NP exceed the limit of 42 for this type of nodes but the 28 type1 nodes from DC an1 will be handed over to a two NPs which will split them equally making the total from DCs br1 and br2 42 following the requirements.
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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
1 Like
Proposal 135159 ā LaCosta | CodeGov
Vote: ADOPT
As part of the Steps for Gen-1 Node onboarding after 48 months, the Node Provider Arceau NP LLC is creating the Node Operator xva5m to hold 28 nodes in the ch2 DC that are being handed over by NP Rivonia Holdings LLC.
All the required steps were followed:
- A Forum post by the selling NP
- The self-declaration document was uploaded on the IC Wiki
- The Node Operator ID proposed is new
- A statement, published on the IC wiki, signed by both the current and the new node provider
Currently the NP has a total of 0 type1 nodes which means it can add the proposed 28 nodes and still have a possibility of adding an additional 14 nodes before meeting the maximum number of nodes 42.
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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
1 Like
Proposal 135173 ā LaCosta | CodeGov
Vote: ADOPT
As part of the Steps for Gen-1 Node onboarding after 48 months, the Node Provider Blockchain Development Labs is creating the Node Operator jqwj7 to hold 14 nodes in the bc1 DC.
All the required steps were followed:
- A Forum post by the NP
- The self-declaration document was uploaded on the IC Wiki
- The Node Operator ID proposed is new
Currently the NP has a total of 28 type1 nodes on DC to1, 28 type1 nodes on DC to2 and 14 type1 nodes on DC bc1 controlled by NO feb2q-mgxwe-okz7r-juws2-mahg4-wflqu-oeflf-kvh4r-qaqit-hbqpg-uqe which match the proposed number of nodes and the DC mentioned in the proposal. The sum of the type1 nodes held by the NP exceed the limit of 42 for this type of nodes but the 28 type1 nodes from DC to1 will be handed over to a new NP making the total from DCs bc1 and to2 42 following the requirements.
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 topics and Synapse on most other 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 and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
1 Like
Proposal 135075 | Tim - CodeGov
Vote: Adopt
This proposal removes node operators that were offboarded in proposal 134936. The node operator IDs in this proposalās payload match those that I checked when reviewing the earlier proposal.
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 topics and Synapse on most other 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 decentralisation of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
1 Like
Proposals 135157 & 135158 | Tim - CodeGov
Vote: Adopt
These 2 proposals add new node operator IDs for node provider Allusion in data centres BR1 and BR2. The node provider ID and data centre IDs given in the proposal match the information in the node provider record in the dashboard. The addition of the new node operator IDs is consistent with the processes outlined in the current thread for reconfiguring existing Gen-1 nodes under the new remuneration structure. The current nodes for this NP total 70, which exceeds the agreed maximum of 42, but this will come down to 42 after selling their nodes at the AN1 data centre, in keeping with the statement of intent here.
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 topics and Synapse on most other 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 decentralisation of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
1 Like
Proposal 135173 | Tim - CodeGov
Vote: Adopt
This proposal adds a new node operator ID for node provider Blockchain Development Labs. The node provider ID and data centre ID given in the proposal match the information in the node provider record in the dashboard. The addition of the new node operator ID is consistent with the processes outlined in the current thread for reconfiguring existing Gen-1 nodes under the new remuneration structure and the statement of intent here.
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 topics and Synapse on most other 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 decentralisation of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
1 Like
Thank you @timk11 and CodeGov for the vigilant review. We apologise for missing to upload this file.
We just added it to the Wiki: Decentralized Entities Foundation - Internet Computer Wiki
We understand that the proposal is already out and certain votes have already been cast. So we are ok to resubmit the proposal in case it doesnāt pass this time.
5 Likes
Are there any objections from anyone to us submitting a motion proposal that would make this rule official?
We would typically wait a bit longer for the discussions to settle but a) this is a minor change compared to the earlier motion proposal, and b) nodes were sold a long time ago (time flies!) and it would be important for them to have the situation clear.
So unless there are any objections, weād proceedā¦ Or please respond to this message if youād like a bit more time to discuss.
cc @timk11 @LaCosta @Lorimer @louisevelayo @ZackDS since youāve recently been active in this thread.
Cheers!
3 Likes
I have no objections. Sounds like a good idea to me and better to get it done sooner.
3 Likes
No objections from me either.
4 Likes