The NNS Team submitted the following proposal to create a Node Reward Canister, and plans to vote it in on Thursday, March 20th.
# Proposal to Create Node Rewards Canister on NNS Subnet
__Proposer__: DFINITY Foundation
__Source code__: [3a3cf55373bfe5843fac9fff6657127ae11b5dd8][commit]
[commit]: https://github.com/dfinity/ic/tree/3a3cf55373bfe5843fac9fff6657127ae11b5dd8
## Motivation
The complexity involved in calculating Node Provider Rewards will be increasing with the advent of performance-based
rewards. Performance data derived from the already established trusthworthy metrics will need to be collected and used
in calculating node remuneration.
The Registry should be kept as simple as possible as it supports the core protocol, so adding more complexity to that
canister increases the risk of bugs in a critical IC component.
Therefore, to support further and continued enhancements to Node Provider Rewards, we are creating a new canister, as
per the agreed motion proposal [135054](https://dashboard.internetcomputer.org/proposal/135054), which will assume the
responsibility for calculating those rewards, which will
allow that system to develop independently of the constraints Registry development imposes.
## Zero Feature Release
The first release of this canister has no meaningful features. This is being deployed in this way for two primary
reasons.
1. To have the infrastructure in place to deploy and update, so that operational capabilities are exercised before it
becomes a core part of the infrastructure.
2. To give the community more time to review the code in the canister during development, as it will be released in
smaller increments.
It will have no impact on the existing functionality until it is integrated into the system by redirecting Governance
to call this new canister instead of the Registry.
## Verification
See the general instructions on [how to verify] proposals like this. A "quick
start" guide is provided here.
[how to verify]: https://github.com/dfinity/ic/tree/3a3cf55373bfe5843fac9fff6657127ae11b5dd8/rs/nervous_system/docs/proposal_verification.md
### WASM Verification
See ["Building the code"][prereqs] for prerequisites.
[prereqs]: https://github.com/dfinity/ic/tree/3a3cf55373bfe5843fac9fff6657127ae11b5dd8/README.adoc#building-the-code
\`\`\`
# 1. Get a copy of the code.
git clone git@github.com:dfinity/ic.git
cd ic
# Or, if you already have a copy of the ic repo,
git fetch
git checkout 3a3cf55373bfe5843fac9fff6657127ae11b5dd8
# 2. Build canisters.
./ci/container/build-ic.sh -c
# 3. Fingerprint the result.
sha256sum ./artifacts/canisters/node-rewards-canister.wasm.gz
\`\`\`
### Init arguments verification
[\`didc\`][latest-didc] is required.
[latest-didc]: https://github.com/dfinity/candid/releases/latest
\`\`\`
didc encode '()' | xxd -r -p
\`\`\`
This should match the `arg_hex` field of this proposal.
Proposal #135859 for Node Rewards Canister — Zack | CodeGov
Vote: Adopted
Reason: The build is reproducible and the wasm hash as well as the empty arguments is a match.
This bening a so called “Zero Feature Release” and nothing stands out “Hello, world”
Not going to mention the TYPOS in the verification section in the summary. At this point we (GodeGov & Leo) been here many times before and know how to check it and I highly doubt it that anyone else will, so it’s fine.
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.
Vote: ADOPT
Hash Match: MATCH
Feedback: NONE
Proposer Check: MATCH
Target Canister: New
Reason:
I successfully built and verified the hash. New canister, no impact on anything.
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.
The proposal creates the initial template of what will be the Node Rewards Canister as approved in proposal 135054 with no meaningful features.
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.
The install mode is indeed 3, which corresponds to creating a new canister on the nns subnet:
/// A proposal to add a new canister to be installed and executed in the
/// NNS subnetwork.
/// The root canister, which controls all canisters on the NNS except for
/// itself, handles this proposal type. The call also expects the Wasm module
/// that shall be installed.
The wasm hash is reproducible.
I’m not familiar with this proposal type, but the parameter initial_cycles 1 might be an issue, IIUC that the canister will be created with 1 cycles we might hit the freezing threshold right away.
Is this the correct approach to stable memory? I feel like this code might be a bit heavy, using specific functions might be more elegant. StableStructures don’t feat as well as a simple Refcell in thread_local for mutable borrow access.
Reason: Build completes successfully and hashes match. The proposal installs a new system canister which in the future will be used to handle reward distribution for node providers though at the moment it contains no functionality.
Due to a mistake in adding empty init arguments (instead of an empty record) the proposal to create the canister failed, resulting in an empty canister on the NNS subnet.
Another proposal to install the code onto that canister will be submitted.
