The proposal allows the principal 2igsz-4cjfz-unvfj-s4d3u-ftcdb-6ibug-em6tf-nzm2h-6igks-spdus-rqe controlled by DFINITY to deploy canisters on the uzr34 subnet. This is one of the steps now announced to install the rate-limiting canister and was not discussed properly and neither explicit in the previous approved proposal.
I do agree with @Lorimer that this approach should be changed and prioritized as it doesn’t follow the trustless model that we desire from any blockchain. This step was not discussed nor revealed to the community in the past proposal and discussion, and I approved this proposal with a grain of salt. The reason I do this is that I agree that the pros of the installation of this canister as it is out weights the cons of preventing it, since the change to a new approach would probably take some time that would conflict with switch to new boundary node architecture.
I’m really impressed with how everyone has handled proposal 134256. The decisions made by @Lorimer and by the CodeGov team (@ZackDS@timk11@LaCosta) all seem sensible and I appreciate how DFINITY (@rbirkner) gave clear explanation of the issue and why it was handled this way. The system is not perfect and will always need continuous improvement, so it’s nice to know that there is a path forward when new issues come up that do not stifle progress and yet DFINITY is always thinking about improvements and the community has the opportunity to provide input. Great job everyone.
The vote on the proposal 134256 was quite close with a small lead for “yes”. Following the community, DFINITY decided to adopt. As the proposal has now passed, the boundary node team will proceed and submit the proposal to remove the privilege of the principal 2igsz as soon as possible.
We also want to thank @Lorimer for his thorough review. We agree with the identified shortcomings and will increase the priority of looking for a better solution.
Voted to adopt proposal 134286. The proposal seeks to remove a cordoned node from the subnet and specifies that the associated data centre is being offboarded “after 48 months”. Decentralisation parameters are improved with respect to country. The necessary context is provided by this forum post and associated discussion. For future proposals of this type I recommend that the background context be included in the proposal text for ease of verification.
Voted to adopt proposal 134318. This proposal removes authorisation for the boundary node team’s principal to deploy canisters to this subnet, following the deployment of the rate-limiting canister as explained here, thus returning the canister to its original and more secure state.
This follows proposal #134256 that authorized this, and removes the authorization from the same principal “2igsz-4cjfz-unvfj-s4d3u-ftcdb-6ibug-em6tf-nzm2h-6igks-spdus-rqe” . The summary is crystal clear and the payload is a match.
I’ve voted to adoptproposal 134318, because it seeks to partially undo a prior proposal that I would have preferred to see rejected (however I’m not confident that the proposal summary is entirely accurate).
As can be observed, both canister which have been deployed are controlled by the very same privileged principal → 2igsz-4cjfz-unvfj-s4d3u-ftcdb-6ibug-em6tf-nzm2h-6igks-spdus-rqe. This means that even after this proposal has executed, the owners of this principal will still retain special authorization within the II subnet.
@rbirkner could you clarify what’s meant by ‘remove the authorization from the 2igsz principal’? In principle, won’t this principal still have potential to spawn new canisters within the II, given it’s control of canisters that already reside within the subnet?
Voted to adopt proposal 134286. This proposal is part of a sequence of steps to remove cordoned nodes from subnets as the associated data centeres are being offboarded after 48 months of their respective DC contracts that are still private and were signed up before the Genesis. There is a great and detailed explanation of this changes in this forum post and the forum thread it is in. In the wiki there is a series of Steps for Gen-1 Node onboarding after 48 months that need to be followed in order for the nodes to continue earning rewards which starts by making a forum post in the following thread. As we can verify no one as come forward with nodes from the DCs in this proposals so I don’t see any issues with the removal of this nodes.
An authorized principal of a subnet can create new canisters. On application subnets everyone is authorized, but there are the canister creation fees (0.5T cycles IIRC). On system subnets, nobody is authorized by default and there are no fees. With the two proposals, we first authorized the BN principal to be able to create canisters and now we are proposing to remove that privilege again. A malicious authorized principal could create tons of canisters for free until the subnet reaches its limit. Authorization of principals on a subnet is governed through NNS proposals.
The controller of a canister can do “anything” with that specific canister (e.g., install/reinstall/upgrade the canister, change the canister settings, etc.), but cannot do anything else on the subnet. The canisters are well isolated, so the impact of two canisters on the rest of the subnet is minimal. Adapting the controllers of a canister can only be done by an existing controller.
Both canisters are currently empty and “just exist”. You can verify that with the following dfx command:
The proposal 134318 to remove the authorization of the BN principal on the uzr34 subnet has been adopted by the NNS. With this the BN principal doesn’t have any special privileges anymore.
Thanks @rbirkner, I’ve had a bit of time this morning to revisit my prior understanding in an attempt to verify some of the claims above (I’m just doing this as an exercise, and to learn what I’m missing). If you could spare a moment for some further comments that would be much appreciated.
My understanding was that canisters inside system subnets can spawn additional canisters (even within system subnets). Take the NNS ICP Archive Canister (No. 3) for example. This canister is new, and is preceded by the two other archive canisters which ran out of space:
The recent deployment of the latest instance of that canister (No. 3) didn’t require a proposal (as far as I can see). Canisters are principals themselves, and if they already reside in a subnet, do they not therefore have certain privileges de facto (or is there another mechanism here that I’m not appreciating)?
Voted to adopt proposal 134318 as a continuation of the steps to install the rate-limiting canister on subnet uzr34. The previous proposal 134256 reviewed here gave authorization to principal 2igsz-4cjfz-unvfj-s4d3u-ftcdb-6ibug-em6tf-nzm2h-6igks-spdus-rqe to deploy canisters on the aforementioned subnet. Now with the deployment of this canister the proposal removes the authorization of this principal.
@ZackDS, @timk11, @LaCosta, just a heads up that the comment ‘remove the authorization from the principal 2igsz to deploy canisters on the uzr34 subnet’ in the proposal summary should not have been taken literally. You may wish to update your reviews to reflect this, and avoid any misunderstanding when referring back in the future.
2igsz is still a privileged principle, and could still deploy canisters to the II subnet if so desired (bypassing the NNS). It would be good to avoid missing a detail like this in the future.
Thanks for drawing our attention to this unexpected loophole. I’ll leave my review as it is, as it reflects my thinking at the time that I wrote it, but I’ll take on board that there’s an extra layer of complexity that wasn’t immediately apparent.
