NNS Updates Dec 1, 2023

Developers
1

The NNS Team will be submitting the following upgrade proposal today, 2023-12-01. DFINITY plans to vote in favor of this proposal on Monday, 2023-12-04.

This release

Upgrade proposals will be submitted for the CMC, governance, registry and sns-wasm. See the proposals below for details.

Of note: Due to a bug with how SNS Swap canister and NNS Governance canister communicates, SNSs that are deployed with no matched funding will have issues with finalization. To mitigate the issue while a fix is being written, the NNS governance canister has disabled the ability for CreateServiceNervousSystem proposals to be submitted without Neurons’ Fund funding.

Proposal to be Submitted

CMC

## Proposal to Upgrade the Cycles-minting Canister
### Proposer: DFINITY Foundation
### Git Hash: 14e0b0adf6632a6225cb1b0a22d4bafce75eb81e
### New Wasm Hash: 8d13251be4f4951a00819d0dfcec3855efd30b4bbd77a258033f3673afb574ba
### Upgrade Args Hash: 0fee102bd16b053022b69f2c65fd5e2f41d150ce9c214ac8731cfaf496ebda4e
### Target canister: rkp4c-7iaaa-aaaaa-aaaca-cai
---
## Features

Beside various chores and refactorings the following are the new features:

* Adds the endpoint notify_mint_cycles that works almost the same as notify_top_up, but instead of depositing the minted cycles in a canister, the CMC will deposit those cycles to a specified account on the cycles ledger.

* Add create_canister endpoint to allow creating canisters using cycles.

* Allow specifying a subnet for canister creation.

* Add ability to specify canister settings in notify_create.

* Add get_authorized_subnets endpoint which enables querying the CMC for authorized principals and subnets.

## Release Notes
```
$ git log --format="%C(auto) %h %s" e813c43a337a26c026c2f2ec19099bd2036e7280..14e0b0adf6632a6225cb1b0a22d4bafce75eb81e --  ./rs/nns/cmc
 8c2e06d955 feat(CMC): notify_mint_cycles to cycles ledger
 d0d02d41a8 build: fix few build dependencies
 5ae303770f chore: bump rust to 1.73
 b968ee6288 refactor(IDX-3017): sync version of build-info and move to the workspace.
 8b6c8d1b0f feat(release): Introduce workspace version
 ab8783a919 refactor(IDX-3017): move serde to the workspace.
 33b4bbbfd8 RUN-810: Switch `CanisterId::new` to infallable `CanisterId::unchecked_from_principal`
 63bd1c173e fix: Bring cmc.did in sync with code
 bb083881c5 feat(SDK-1260): allow specifying a subnet on CMC for canister creation
 d1d7cc09ce feat(SDK-1237): CMC: add create_canister to allow creating canisters using cycles
 70226d30e4 refactor: [IDX-3017] Update base64 and put it into workspace.
 dd6829112e feat(NNS1-2430): CMC: add ability to specify canister settings in notify_create
 78836a179a chore: use the global workspace for the version of the futures crate
 9371e6fbd8 chore: use the global workspace for deriving the prost version
 8b3323c1e0 Chore: Fix typos in nns code
 68c57d1242 Update gazelle, go and buildifier toolchains.
 5bdc1612a0 Merge branch 'NNS1-2361' into 'master'
 191d7df2a1 fix(sns): Apply SNS maturity modulation at the end of the 7 day window
 0ecb948723 chore: Update links to interface spec
 3855fbb623 chore: bump rust to 1.71
 2aaa82b6e9 feat(NNS1-1956): Enable querying CMC for authorized principals and subnets
 8d2f376768 Implement various clippy warnings throughout our code.
 3de7d413ea chore(build): unify versions of candid in Cargo files
 90c8a01659 feat(ledger_core) add TokensType trait
 211f587e4c Sort imports with crate import granularity
```
## Candid Post Upgrade Args
```candid
()
```
### Validating Candid Args
Verify that the hash of the args matches proposal contents.
`didc encode '()' | xxd -r -p | sha256sum`
## Wasm Verification
Verify that the hash of the gzipped WASM matches the proposed hash.
```
git fetch
git checkout 14e0b0adf6632a6225cb1b0a22d4bafce75eb81e
./gitlab-ci/container/build-ic.sh -c
sha256sum ./artifacts/canisters/cycles-minting-canister.wasm.gz
```
## Current Version
- Current Git Hash: e813c43a337a26c026c2f2ec19099bd2036e7280
- Current Wasm Hash: fc1655302a81cd1b7148a6f66479b2830bd0d567d04780720e7bdd6c5b124fb5

Governance

## Proposal to Upgrade the Governance Canister
### Proposer: DFINITY Foundation
### Git Hash: 14e0b0adf6632a6225cb1b0a22d4bafce75eb81e
### New Wasm Hash: 539e5e33f64742044d06c20fecc6b66161901d5f07b576e171d51bd383beb81f
### Target canister: rrkah-fqaaa-aaaaa-aaaaq-cai
---
## Features

Besides various chores and fixes the most important changes are the following inactive neuron migration features:

* Turn on the flag to delete inactive neuron copies on heap and bump the number of neurons limit.

* Check whether heap can grow before performing manage neuron operations.

* Maintain only one copy of inactive neuron.

* Temporarily disable submitting CreateServiceNervousSystem proposals that do not request Neurons' Fund funding


## Release Notes
```
$ git log --format="%C(auto) %h %s" 44a5a63b03b7aa2791e5b45abfa6a709abe5c831..14e0b0adf6632a6225cb1b0a22d4bafce75eb81e --  ./rs/nns/governance
 f75bdf2a2f chore: Call get_build_metadata for committing canister state and add comment
 d0ab500d0f Merge branch 'jason/NNS1-2538' into 'master'
 0865ab1486 feat: NNS1-2538 Turn on the flag to delete inactive neuron copies on heap and bump the number of neurons limit
 dae825f2a6 feat: NNS1-2766 Check whether heap can grow before performing manage neuron operations
 794d1259be feat: NNS1-2533 Remove inactive neurons from heap when it exists in stable storage
 7e3d9f4e46 Merge branch 'jason/NNS1-2532-1' into 'master'
 2f6a07ae9d feat: NNS1-2532 Maintain only one copy of inactive neuron
 ea1ae9150b fix(sns): Include validation to only allow NF participation to be enabled
 176072ec80 fix(NNS): NNS1-2757: Refunds maturity to Neurons' Fund in more cases where deploy_new_sns fails.
```

## Wasm Verification
Verify that the hash of the gzipped WASM matches the proposed hash.
```
git fetch
git checkout 14e0b0adf6632a6225cb1b0a22d4bafce75eb81e
./gitlab-ci/container/build-ic.sh -c
sha256sum ./artifacts/canisters/governance-canister.wasm.gz
```
## Current Version
- Current Git Hash: 44a5a63b03b7aa2791e5b45abfa6a709abe5c831
- Current Wasm Hash: f680e1e7a178ed660e2fa4edf11306cf41b6eecbfe0d99b009ea2575f482ce27

Registry

## Proposal to Upgrade the Registry Canister
### Proposer: DFINITY Foundation
### Git Hash: 14e0b0adf6632a6225cb1b0a22d4bafce75eb81e
### New Wasm Hash: 46d26b7c9e8d1da2f03747b3e896f732e584a5175bfe38b3be1bce06bb3064df
### Target canister: rwlgt-iiaaa-aaaaa-aaaaa-cai
---
## Features

Besides various chores and refactorings the following are the new features:

* Preparations for allowing nodes to have an IPv4 address. A field is added to the NodeRecord for the IPv4 configuration. The node operator can directly change that configuration through a call to the registry canister.

* Add a registry invariant for the high threshold public key. 

* Replaced the subnet feature sev_status with sev_enabled.

## Release Notes
```
$ git log --format="%C(auto) %h %s" 05198cac27d4d36f29c58e515c414f178d781988..14e0b0adf6632a6225cb1b0a22d4bafce75eb81e --  ./rs/registry/canister
 8c2e06d955 feat(CMC): notify_mint_cycles to cycles ledger
 2261ed7ebd Merge branch 'rjb/ipv4-registry-changes' into 'master'
 211ee0b97b feature(ipv4-replica): IPv4 Registry Changes
 10bb423819 feat(crypto): CRP-943: Add invariant for high threshold public key
 6b7746ec7c refactor: remove the unused ingress_bytes_per_block_soft_cap
 f64965d409 Merge branch 'mathias-CRP-1450-add-tests-for-check-ecdsa-signing-subnet-lists' into 'master'
 5efc264277 test(crypto): CRP-1450: Add tests for check_ecdsa_signing_subnet_lists
 04e66e5706 Merge branch 'rumenov/upppr' into 'master'
 830feb6580 chore: upgrade prost to 0.12 and tonic to 0.10
 992f8e8c42 feat(NODE-1182,NODE-1183): SEV feature tooling
```

## Wasm Verification
Verify that the hash of the gzipped WASM matches the proposed hash.
```
git fetch
git checkout 14e0b0adf6632a6225cb1b0a22d4bafce75eb81e
./gitlab-ci/container/build-ic.sh -c
sha256sum ./artifacts/canisters/registry-canister.wasm.gz
```
## Current Version
- Current Git Hash: 05198cac27d4d36f29c58e515c414f178d781988
- Current Wasm Hash: 8e5ed7748d347d88ed0e96fd7f037553b096966f5534996637ba6358d72ea47d

SNS-WASM

## Proposal to Upgrade the Sns-wasm Canister
### Proposer: DFINITY Foundation
### Git Hash: 14e0b0adf6632a6225cb1b0a22d4bafce75eb81e
### New Wasm Hash: 911f411ef48a73bd6148ef74ba1e495cea046cd544a37f84e4e5f99e792bd16f
### Target canister: qaa6y-5yaaa-aaaaa-aaafa-cai
---
## Features

Besides various chores the new feature is the ability to query deployed snses via the proposal id that created them.

## Release Notes
```
$ git log --format="%C(auto) %h %s" 751b2a0cf904934b4afb62b1457f6bf4f0a20275..14e0b0adf6632a6225cb1b0a22d4bafce75eb81e --  ./rs/nns/sns-wasm
 512c016f28 chore(sns): Add the two SNS proposals that have been adopted before this feature went live
 830feb6580 chore: upgrade prost to 0.12 and tonic to 0.10
 5ae303770f chore: bump rust to 1.73
 e80f2be231 feat(nns): Add the ability to query deployed snses via the proposal id that created them
```

## Wasm Verification
Verify that the hash of the gzipped WASM matches the proposed hash.
```
git fetch
git checkout 14e0b0adf6632a6225cb1b0a22d4bafce75eb81e
./gitlab-ci/container/build-ic.sh -c
sha256sum ./artifacts/canisters/sns-wasm-canister.wasm.gz
```
## Current Version
- Current Git Hash: 751b2a0cf904934b4afb62b1457f6bf4f0a20275
- Current Wasm Hash: df5d2dd24efc9c7f7b0a5a23ef94271174806d46c93d6d2613363ff3c55afb9b
1 Like
2

Hey @DanielThurau

Do you know why NNS Upgrade proposal 126300 is not included in this set of NNS Upgrade proposals? Why was it submitted separately earlier today?

Also, NNS Upgrade proposals 126170, 126171, and 126173 came out today too, but I know those are brand new NNS canisters related to installation of ckETH as described by @Manu. It kind of makes sense that they were submitted separately.

This past week there were NNS Upgrade proposals 126120 and 126130, both of which upgraded the governance canister. Proposal 126130 was executed almost immediately, so that leads me to think it was a critical update.

I’m trying to understand how DFINITY organizes submitting the NNS Upgrade proposals and sometimes it’s a challenge to follow because there are so many that are submitted each week by different people with different styles and content. For the forum posts that you make, would it be too much to ask for you to add the proposal ID to your forum posts. It’s easier to track by proposal ID than by commit ID. I really appreciate how thorough you are with these posts, but that small detail would help a lot.

1 Like
3

Also, the CodeGov project has a channel called SCM Reviews in the CodeGov community on OpenChat where we are posting the verifications that we complete for these NNS Upgrade proposals. Here is a link to that channel. Right now we are only performing verification (building and verifying hashes), but hopefully soon we sill start taking a closer look at the change details. It helps a lot to have these daily summaries and the aggregation thread, so please keep up the good work @DanielThurau.

1 Like
4

Is there any plan to make canister creation in a specific subnet possible without using the CMC, like with the ic_cdk:create_canister method?

5

The CodeGov neuron has voted to Adopt the 9 NNS Canister Upgrade proposals listed below that were all submitted to the NNS on Dec 1, 2023. Two of our team members (@ZackDS and @Zane) verified each proposal as linked below.

The NNS canister upgrade proposals below were announced in the OP of this forum thread.
126301 - cycles minting canister - CodeGov verification
126302 - governance canister - CodeGov verification
126303 - registry canister - CodeGov verification
126304 - SNS wasm canister - CodeGov verification

The NNS canister upgrade proposals below were announced here:
126170 - ckETH ledger - CodeGov verification
126171 - ckETH minter - CodeGov verification
126173 - ckETH index - CodeGov verification

I don’t know if the NNS upgrade proposals below were announced on the forum, but this seems like a good place to post how the CodeGov neuron voted on them:
126300 - exchange rate canister - CodeGov verification
126305 - frontend NNS dApp canister - CodeGov verification

The CodeGov neuron has voted to Reject the proposal 126172. The hash matches expectation, but @Manu at DFINITY indicated here that it was submitted with the wrong initialization arguments.

2 Likes
6

No plans for now. It would require a lot of effort because right now the CMC is responsible for access control to subnets, and ic_cdk::create_canister talks to the management canister, which has no direct access to the permissions list in the CMC.

So you have to go through the CMC, but I’d also like to point out this change:

* Add create_canister endpoint to allow creating canisters using cycles.

This endpoint is very similar to ic_cdk::create_canister and you can call it with cycles so you don’t have to have ICP available

7

Thank you for the response. Considering the proposal to establish a European-only subnet, does this imply that only canisters created through the CMC will have the capability to be deployed within that subnet? Is this the intended restriction?

8

Access control to subnets works like this (and has been working like this for a long time):

  • If you have a canister on a subnet you can create as many canisters on the subnet as you want. Simply use the management canister’s create_canister method through a canister on that subnet. This is what ic_cdk::create_canister does behind the scenes.
  • Otherwise you go through the CMC. The CMC has three lists/mappings of subnets:
    • List of default subnets. If you use the CMC’s notify_create_canister or create_canister without specifying any preferences for subnet selection your canister lands on a random subnet from this list.
    • Mapping of subnet type to subnets of that type. You can read this list with this function. If you select a subnet type in your subnet selection options your canister will be created on a random subnet in the list of this type.
    • Mapping of principals to subnets. For subnets where only certain principals are allowed to create canisters, e.g. the NNS subnet. If you don’t specify a subnet selection option and your principal has an entry in this mapping you get a random subnet from this mapping

In other words: If you want your application to live on the european subnet you have to use the CMC to create the initial canister(s) for that dapp, and then if these canisters spawn new canisters they will all stay on that subnet

1 Like
9

Will there be some mechanism to make it obvious to users that a subnet is hosted in one geographic region only? If the URL is the typical trust indicator, it might make sense to have a domain for EU/europe only. Of course we cannot restrict custom domains, but having default canister URLs as https://CANISTER_ID.EU_DOMAIN or something like that might help communicate where the computers are running.

10

You should propobably forward your question to the ongoing discussion about this proposed subnet: European subnet on the Internet Computer: A Step Toward GDPR-Ready Infrastructure

1 Like