yes, we have pretty much the same header and footer 
1 Like
Yes,I don’t think it’s the footer or the header.
2 Likes
With proposal 136899, the queue size for key derivation requests accepted by subnet fuqsr for the key vetkd:Bls12_381_G2:test_key_1 will increase from 10 to 20. As noted in an earlier post, the initial limit was set conservatively to support preliminary testing. Based on the results, we are now confident that the subnet can sustain a higher number of parallel requests, and we are proposing to increase the queue size to 20, aligning it with the limits used by other chain keys. Further adjustments may follow as adoption increases and additional usage patterns emerge.
If adopted, the new chain key config of the subnet will look like the following:
ChainKeyConfig {
key_configs: [
KeyConfig {
key_id: Some(
Ecdsa(
EcdsaKeyId {
curve: Secp256k1,
name: "test_key_1",
},
),
),
pre_signatures_to_create_in_advance: Some(
7,
),
max_queue_size: Some(
20,
),
},
KeyConfig {
key_id: Some(
Schnorr(
SchnorrKeyId {
algorithm: Bip340Secp256k1,
name: "test_key_1",
},
),
),
pre_signatures_to_create_in_advance: Some(
7,
),
max_queue_size: Some(
20,
),
},
KeyConfig {
key_id: Some(
Schnorr(
SchnorrKeyId {
algorithm: Ed25519,
name: "test_key_1",
},
),
),
pre_signatures_to_create_in_advance: Some(
7,
),
max_queue_size: Some(
20,
),
},
KeyConfig {
key_id: Some(
VetKd(
VetKdKeyId {
curve: Bls12_381_G2,
name: "test_key_1",
},
),
),
pre_signatures_to_create_in_advance: Some(
0,
),
max_queue_size: Some(
20,
),
},
],
signature_request_timeout_ns: Some(
1800000000000,
),
idkg_key_rotation_period_ms: Some(
604800000,
),
},
6 Likes
Proposal 136899 Review | aligatorr - CO.DELTA △
VOTE: YES
TLDR: Increases max_queue_size from 10 to 20 for VetKd key. Rest of configuration is unchanged.
Current
"chain_key_config": {
"key_configs": [
{
"key_id": {
"Ecdsa": {
"curve": "secp256k1",
"name": "test_key_1"
}
},
"pre_signatures_to_create_in_advance": 7,
"max_queue_size": 20
},
{
"key_id": {
"Schnorr": {
"algorithm": "bip340secp256k1",
"name": "test_key_1"
}
},
"pre_signatures_to_create_in_advance": 7,
"max_queue_size": 20
},
{
"key_id": {
"Schnorr": {
"algorithm": "ed25519",
"name": "test_key_1"
}
},
"pre_signatures_to_create_in_advance": 7,
"max_queue_size": 20
},
{
"key_id": {
"VetKd": {
"curve": "bls12_381_g2",
"name": "test_key_1"
}
},
"pre_signatures_to_create_in_advance": 0,
"max_queue_size": 10
}
],
"signature_request_timeout_ns": 1800000000000,
"idkg_key_rotation_period_ms": 604800000
}
}
}
0 Warnings
1 Improvements
- Subnet has been set gossip config to FALSE.
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
CO.DELTA
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
- Look: We observe the details and context of NNS proposals.
- Test: We test and verify the claims made by those proposals.
- Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
2 Likes
Proposal 136899 Review | Lorimer - CO.DELTA △
VOTE: YES
A minor change to the new vetkd test key config, increasing the max queue size from 10 to 20, which is consistent with configuration for the other keys (discussed previously).
Here’s the proposed chain_key_config for this subnet. If you click the orange edit history icon (top right of this post) you’ll see the minor change that’s been applied in diff format (+++/—).
"chain_key_config": {
"signature_request_timeout_ns": 1800000000000,
"key_configs": [
{
"max_queue_size": 20,
"key_id": {
"Ecdsa": {
"name": "test_key_1",
"curve": "secp256k1"
}
},
"pre_signatures_to_create_in_advance": 7
},
{
"max_queue_size": 20,
"key_id": {
"Schnorr": {
"algorithm": "bip340secp256k1",
"name": "test_key_1"
}
},
"pre_signatures_to_create_in_advance": 7
},
{
"max_queue_size": 20,
"key_id": {
"Schnorr": {
"algorithm": "ed25519",
"name": "test_key_1"
}
},
"pre_signatures_to_create_in_advance": 7
},
{
"max_queue_size": 20,
"key_id": {
"VetKd": {
"name": "test_key_1",
"curve": "bls12_381_g2"
}
},
"pre_signatures_to_create_in_advance": 0
}
],
"idkg_key_rotation_period_ms": 604800000
}
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
CO.DELTA △
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
- Look: We observe the details and context of NNS proposals
- Test: We test and verify the claims made by those proposals
- Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
1 Like
Proposal 136899 – LaCosta | CodeGov
Vote: ADOPT
The proposal increases the queue size of the new vetkd from 10 to 20. This can be confirmed by comparing the key_configs with proposal 136653. The diff from the two proposal payloads can be found below.
chain_key_config: {
key_configs: [
…
3: {
key_id:{
curve:"bls12_381_g2"
name:"test_key_1"
}
max_queue_size: 10
max_queue_size: 20
pre_signatures_to_create_in_advance: 0
}
]
…
}
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.
2 Likes
Proposal 136899 Review | Malith H - CO.DELTA △
VOTE: YES 
TLDR:
A Change in the vetkd test config. According to the proposal payload it increases max queue size from 10 to 20.
{
"key_configs": [
{
"key_id": {
"curve": "secp256k1",
"name": "test_key_1"
},
"max_queue_size": 20,
"pre_signatures_to_create_in_advance": 7
},
{
"key_id": {
"algorithm": "bip340secp256k1",
"name": "test_key_1"
},
"max_queue_size": 20,
"pre_signatures_to_create_in_advance": 7
},
{
"key_id": {
"algorithm": "ed25519",
"name": "test_key_1"
},
"max_queue_size": 20,
"pre_signatures_to_create_in_advance": 7
},
{
"key_id": {
"curve": "bls12_381_g2",
"name": "test_key_1"
},
"max_queue_size": 20,
"pre_signatures_to_create_in_advance": 0
}
]
}
Confirms test_key_1 and increase in max_queue_size to 20
You may wish to follow the CO.DELTA known neuron if you found this analysis helpful.
CO.DELTA
We’re a verifiably decentralised collective who review IC deltas (changes applied by NNS proposals). We follow a common code:
-
Look: We observe the details and context of NNS proposals
-
Test: We test and verify the claims made by those proposals
-
Automate: We automate as much as possible by building increasingly sophisticated tools that streamline and strengthen the reviewal process.
Every vote cast by CO.DELTA is the result of consensus among diligent, skilled and experienced team members acting independently. The CO.DELTA neuron follows the vote of D-QUORUM on NNS topics that the CO.DELTA team does not handle directly. You can therefore follow CO.DELTA on all topics and rely on the highest quality of vote.
@andrea Before you vote on proposal 136899 - are the algorithm names case-sensitive? Please see this comparison between this and previous proposals:
Note that the tree in proposal 136653 (the middle one) has key_config (singular) as an extra level, so although the algorithm names here are lower case I’m not sure if precisely the same thing is being referred to. This and this might be potentially relevant code sections.
4 Likes
Proposal #136899 — review by Zack | CodeGov
Vote: Adopted
Reason:
The subnet id from the payload and the increased value for max_queue_size:20 from previously10 for vetkd:Bls12_381_G2:test_key_1 on subnet fuqsr are correct, while the rest of the settings remain unchanged.
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.
1 Like
Proposal 136899 | Tim - CodeGov
Vote: Reject
This proposal is intended to increase the queue size for VetKD key derivation requests in this subnet from 10 to 20. That’s all fine, but the Schnorr algorithm names may have been mistyped in the payload as noted in my earlier post above. I’m not sure if this is a genuine error or not but I’ve voted to reject out of caution.
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, API Boundary Node 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 & Neurons’ 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 decentralisation 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.
4 Likes
The payload is a canid-encoded record, and the algorithms are variants (enums) as you can see in the code you linked, with one option per algorithm. I think the governance canister would not accept badly formatted arguments. Likely, what happened here is that the dashboard deserialized the payloads of those proposals and displayed the algorithms with different cases.
As you spotted, there are multiple types for the same thing in the codebase, and you can see that the governance type enforces (now at least) the lower case #[serde(rename = "bip340secp256k1")], but other types may allow different serializations. I am not sure why the dashboard are showing different cases for different proposals, but it is likely due to some of the following:
- Changes in the underlying types. The ChainKeyConfig was migrated a couple of times to allow extensions, e.g. to be reused for Schnorr sigs and vetkeys. So it could be that the lower case was introduced at a later time.
- Changes in the tools used by the dashboard to deserialize and display the payloads over time.
7 Likes
A new proposal with ID 137004 has been submitted, please take a look.
Click here to open proposal details
Replace a node in subnet fuqsr
Motivation:
- replacing cordoned node ohtm4 (Rivonia is selling its nodes as announced in the forum: New Node Provider Proposals - #1047 by dfisher)
Calculated potential impact on subnet decentralization if replacing:
- 1 additional node would result in: (gets better) the average log2 of Nakamoto Coefficients across all features increases from 2.2683 to 2.3219
Based on the calculated potential impact, not replacing additional nodes to improve optimization.
Note: the information below is provided for your convenience. Please independently verify the decentralization changes rather than relying solely on this summary.
Here is an explaination of how decentralization is currently calculated,
and there are also instructions for performing what-if analysis if you are wondering if another node would have improved decentralization more.
Decentralization Nakamoto coefficient changes for subnet fuqsr-in2lc-zbcjj-ydmcw-pzq7h-4xm2z-pto4i-dcyee-5z4rz-x63ji-nae:
node_provider: 5.00 -> 5.00 (+0%)
data_center: 5.00 -> 5.00 (+0%)
data_center_owner: 5.00 -> 5.00 (+0%)
area: 5.00 -> 5.00 (+0%)
country: 4.00 -> 4.00 (+0%)
Mean Nakamoto comparison: 4.83 → 4.83 (+0%)
Overall replacement impact: equal decentralization across all features
Details
Nodes removed:
ohtm4-wevpf-tiy4y-egeex-cocfx-saewl-oe3ld-nj6bk-ex4k2-ln6yp-6qe[health: healthy]
Nodes added:
ghwbi-m4ch3-f252p-czcmv-ppibh-52ucu-e3rfi-6bjib-izssn-jeh4q-eqe[health: healthy]
node_provider data_center data_center_owner area country
------------- ----------- ----------------- ---- -------
4dibr-2alzr-h6kva-bvwn2-yqgsl-o577t-od46o-v275p-a2zov-tcw4f-eae 1 bu1 1 Africa Data Centres 1 Bucuresti 1 CA 1
6nbcy-kprg6-ax3db-kh3cz-7jllk-oceyh-jznhs-riguq-fvk6z-6tsds-rqe 1 fr2 1 Anonstake 1 Douglas 0 -> 1 CH 1
7at4h-nhtvt-a4s55-jigss-wr2ha-ysxkn-e6w7x-7ggnm-qd3d5-ry66r-cae 1 ge1 1 Cyxtera 1 Florida 1 -> 0 DE 1
7ryes-jnj73-bsyu4-lo6h7-lbxk5-x4ien-lylws-5qwzl-hxd5f-xjh3w-mqe 1 hk1 1 Digital Realty 1 Gauteng 1 HK 1
bvcsg-3od6r-jnydw-eysln-aql7w-td5zn-ay5m6-sibd2-jzojt-anwag-mqe 1 im1 0 -> 1 Equinix 1 Geneva 1 IM 0 -> 1
i7dto-bgkj2-xo5dx-cyrb7-zkk5y-q46eh-gz6iq-qkgyc-w4qte-scgtb-6ae 1 jb2 1 HighDC 1 Hesse 1 IN 1
kos24-5xact-6aror-uofg2-tnvt6-dq3bk-c2c5z-jtptt-jbqvc-lmegy-qae 1 jv1 1 -> 0 M247 1 HongKong 1 KR 1
r3yjn-kthmg-pfgmb-2fngg-5c7d7-t6kqg-wi37r-j7gy6-iee64-kjdja-jae 1 lj2 1 Manx Telecom 0 -> 1 Ljubljana 1 RO 1
rpfvr-s3kuw-xdqrr-pvuuj-hc7hl-olytw-yxlie-fmr74-sr572-6gdqx-iqe 0 -> 1 mb1 1 Megazone Cloud 1 Maribor 1 SE 1
spp3m-vawt7-3gyh6-pjz5d-6zidf-up3qb-yte62-otexv-vfpqg-n6awf-lqe 1 -> 0 pl2 1 Posita.si 1 Ontario 1 SG 1
unqqg-no4b2-vbyad-ytik2-t3vly-3e57q-aje2t-sjb5l-bd4ke-chggn-uqe 1 sg1 1 Telin 1 Panvel 1 SI 2
wdjjk-blh44-lxm74-ojj43-rvgf4-j5rie-nm6xs-xvnuv-j3ptn-25t4v-6ae 1 sh1 1 Tierpoint 1 -> 0 Seoul 1 US 1 -> 0
wdnqm-clqti-im5yf-iapio-avjom-kyppl-xuiza-oaz6z-smmts-52wyg-5ae 1 sl1 1 Unicom 1 Singapore 1 ZA 1
zy4m7-z5mhs-zfkpl-zlsjl-blrbx-mvvmq-5z4zu-mf7eq-hhv7o-ezfro-3ae 1 to2 1 Yotta 1 Stockholm 1
Proposal 137004 | Tim - CodeGov
Vote: Adopt
This proposal replaces 1 node in subnet fuqsr, appearing in the decentralization tool as “UP” and belonging to Rivonia Holdings, as this node provider is selling its nodes. As shown in the proposal, decentralisation parameters are unchanged and remain outside the requirements of the target topology given that there are 2 nodes in Slovenia both before and after the change. (I’ve voted to adopt as the decentralisation parameters are no worse.) The proposal summary states that replacing one additional node would improve Nakamoto coefficients but “not replacing additional nodes to improve optimization”. @alexu Is this a mistake on the part of the DRE tool?
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, API Boundary Node 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 & Neurons’ 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 decentralisation 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.