Let me answer to some points that I have some initial thoughts on. I would ask someone from another team to look at the details of the more ledger-related questions.
A canister can set the NNS gov canister ārrkah-fqaaa-aaaaa-aaaaq-caiā as controller and later anyone can make proposals of type āNNS Canister Upgradeā to upgrade this canister (In this case - when there are unexpected changes in the upgrade system)
I would like to point out that this is something that I would very much recommend the NNS not to do. I think the NNS should always vote ānoā on such proposals. There are two main reasons why I think the NNS root should only control system canisters and never user-installed canisters:
I think this will overwhelm NNS voters. NNS decisions should focus on platform decisions. If there are too many proposals, this might overwhelm voters and lead to a) very important (protocol) proposals being overseen or b) users spending less time verifying the protocol proposals.
Making calls to potentially untrusted canisters on untrusted subnets is a risk for the NNS root canister and therefore for the whole governance system. This should therefore be avoided. Note that this is also why most SNS canisters are not controlled by the NNS and SNS canisters are on a trusted, higher replication subnet.
The upgrade path is one for all, there are no forks.
For the SNSs, this is generally true. However, there can also be customised upgrade paths for individual SNSs, if this should be needed to recovering them in an exceptional case.
There is no chance for one canister upgrade to fail while others go through. Itās just a straight line patch after patch.
I think this is true (I hope I understand the statement correctly). So basically there is one canister upgrade at a time (from one version to the next version only one canister is upgraded). Each of those can fail, but yes this would always mean that no other canisters are changed no matter if the one upgrade succeeds of fails. Does this make sense?
In general, I think following this idea could be an interesting solution and it would be interesting to hear some more opinions from our ledger-experts.
I wonder though if it would be better to have something similar to the SNS-upgrades but customised for what is needed for ledgers. Otherwise, it might make evolving both the SNS framework and the newly envisioned solution for ledgers more complex, both for secure development but also for end-users to understand.
I think this problem is partially due to the fact that we specified ICRC-1/-2/-3 under the premise that ledgers are mutable (eg. adding ICRC-2 support implies upgrading your ICRC-1 ledger canister). Once we finish those 3 specifications completely (ICRC-1&2 are complete, ICRC-3 is pending), we should aim to specify further ICRCs under the premise that canisters are immutable, so that dapps can actually blackhole their ledger canisters.
We needed this initial period where we assume ledgers are mutable due to multiple properties of the IC. Also, DFINITYās standard ledger implementation is not simply 1 canister but multiple canisters, which adds to the complexity.
Thank you for the feedback. I agree, that should be a last resort. My reasoning was - If the community starts using it and a lot of the ledgers in the ecosystem end up being governed by this, it would be beneficial if NNS can fix it if something breaks so upgrades will continue, otherwise they will stop. And I estimate that should happen at most once or twice. But I guess I didnāt account for this āMaking calls to potentially untrusted canisters on untrusted subnets is a risk for the NNS root canister and therefore for the whole governance systemā Not sure what the risks are.
That would simplify things, but even if the standards are frozen, I assume Dfinityās icrc1_ledger implementation will still improve, get faster, fix bugs if any are found, and adapt to new protocol improvements.
@infu What about the ledgers whose minter is not a governance? I think in most of the use cases, youād like the main canister of your app to be able to mint tokens. Isnāt that the case for the COYN token for HotOrNot for example?
IMO in these cases your ledger is just as secure as is the canister you set up to mint it. Which makes me think a more secure design would be to set the governance as the minter, then send pre-minted tokens to the app, and only occasionally mint new tokens for the app if/when it runs out?
Yes, that is one of the main use cases of blackholed NNS blessed ledgers - being part of another contract that mints them. TAL or COYN or an LP token and others alike. The canister should be able to mint and burn on demand.
I have no idea if COYN has a ledger. If there was it would be in the list of dapp canisters governed by Hot, but I canāt see a ledger there. There is also no COYN in Icpswap and Sonic.
Yes in these cases the ledger is practically as secure as the canisters allowed to mint its tokens - when it comes to DeFi contracts using it.
SNSes can govern these ledgers, which will provide some guarantees, but they can get more guarantees if they have blackholed ledgers. Then even if someone takes over the DAO governing them, the ledger will still be out of reach. That will be best for something like TAL. A small DAO governing its ledgers is a recipe for disaster.
Another improvement would be a blackholed canister in between the minter and the ledger that throttles the number of tokens minted per day.