- Can you explain where the 7s latency comes from? Regular update calls are advertised to complete in <2s, so I’m curious what the source of the remaining 5s is.
There are at least two rounds of consensus involved. A canister sends a transfer request to the ledger, which need to go through consensus on the NNS subnet to reach the ledger (and the NNS subnet runs at a slower speed than other subnets to prioritize stability). Then the response from the ledger needs to go through consensus on the canister’s subnet before the canister knows whether the transfer succeeded.
- Is the prioritization of inter-canister messages over external ingress messages a universal problem across all subnets, or does it only affect the ICP canister and/or the NNS subnet?
It affects all subnets.
- You mentioned a couple other bugs, including a “second highest priority”, a “third highest priority”, etc. Can you briefly describe what they are?
I’d prefer not to not discuss them until resolved. But generally: affecting availability, related to deterministic replicated message routing and execution, and not specific to ICP on canister.
- This would be a perfect use case for a fully open sourced IC codebase, as suggested by this post. If this proposal is indeed high risk, I think it would probably be best if we all could take a look at the PR before voting.
Totally agree. For ICP on canisters, note that the proposal only affects the ledger canister (open source) slightly; it upgrades the ledger canister by removing a condition that canisters transferring ICP must be whitelisted. We do not see much risk in the ledger upgrade by itself. The risk is whether there could be problems in the interaction between the ledger (open source) and the replica. But the replica (the platform itself on which the canisters run) does not change during the upgrade of the ledger canister.