Since it theoretically provides higher security guarantees than application subnets, it makes sense for DeFi related canisters to be deployed on it. The cycle costs are indeed higher, ~3x iirc, but for the workloads of a financial application like the average DEX they should not be prohibitive.
1 Like
@skilesare Managing SNS canisters in my experience is probably 10x more cumbersome than dfx - single dev control. The system you propose is probably going to make it 50x harder. You mentioned 12-day wait time to upgrade (if I am not wrong). It probably can’t support concurrent proposals to upgrade the same canister. What if there is a security vulnerability that needs to be fixed quickly? What if something goes wrong after upgrade? You will need developers to be extremely careful with these canisters. If something goes wrong and the service is used, it could go down for weeks, if not months.
I think the proposed upgrade system that delegates NNS control in a different way than the SNS is interesting. But it appears some of us are in DEFCON 1 right now, everything has to be examined under a microscope. You mentioned the solution can be permissionless, not requiring anyone to do anything. That is good, but then which services go under that system, who pays for the cycles, who funds the development of new services, who uses them, are we moving other services over there? Are the reviewers getting paid by someone. It’s a brand new SNS (Service Nervous System) alternative, designed to govern services as well. Since you can do it all permissionlessly, it’s pretty much up to the ones using and funding such services, if they like it or not. And also the NNS voters - if they want to be voting on these and spend time researching each veto proposal.
What about launching a custom SNS where the governance canister copies all NNS neurons periodically and lets them vote in the SNS. This way, you won’t need to launch a token… But then you will end with people having to follow others as well. In that case a malicious party will follow a forum promoted neuron and also people who aren’t aware will follow it, because of someone spending time on advertising it. Then the service will be taken over, not through buying tokens, but through investing in advertising and forum posts. Since I answered my question - scratch that idea.
SNSes are good enough imo, you just need people who have governance power to care about the service. Then nobody can take them over. You can also customize them a bit.
Just a thought - you can use this kind of system to ‘fetch’ governance from everywhere. You could have services or neurons governed by other blockchains - Bitcoin, for example. Where miners include a few bits in blocks, and after counting a number of blocks, you get their vote.
1 Like
Yeah it does seem like a bit of an awkward overreach.
Read the room @skilesare
Let’s just get things back to normal before you start filibustering conversations and adding needless levels of complexity.
An SNS is 100% overkill for this application and, yes, would be too much for what I’m seeking. This would not be 50x more complicated due to the fact that, by definition, you could manage it with a single user with dfx(probably not advisable and I’d likely look for an n of m multisig to start).
The delay is certainly an issue, but as we’re looking at hopefully maybe 1 or 2 upgrades a year(ideally far fewer) I’m just not concerned with this. If we brick the canister we brick the canister. If it held value I’d be concerned. It does not hold value, just approvals.
Freezing people’s assets for days at a time would be a bad pattern. This canister would not do this. Having it off line for long periods would cause issues for service providers…and I’ve attempted to maximize the at-stake entities to be those that have them most to lose by the devs screwing up so that they watch them like a hawk. If three services emerge that have over $100k of revenue coming in during the year via subscriptions I do not think I’m going to have a problem getting canister upgrade reviews twice a year. If we don’t have at least that then it will just be a bunch of smaller people using it who needed it because they did not want to roll their own…until they get big enough they need to know what is at risk. False faith in an SNS that can be co-opted is not a solution. This canister will have drawing rights of likely 30x annual revenue. There is not a viable economic model that makes sense at the SNS level.
Yes the canister can be spammed by an attacker and can be blocked from upgrade if not enough people care. My counter argument is that if not enough people care, who cares? There is always the fall back of the NNS installing the canister proactively if it is a big enough emergency. I would not suggest this pattern for many types of canisters. They need to be mostly feature complete and almost blackholeable. This is likely a temporary solution for the short term that provides some reourse to users and removes god-mode from the controller of the canister.
All of these questions are speculative based on the use case and cycle usage of the canister, as well as the interest and usefulness of the canister. Perhaps, once people have value at stake in the service they will pay attention. Perhaps not. We won’t know until we try it.
SNS are a lot of things, but they certainly are not a cure-all given the empirical evidence of their success rate so far. DFINITY themselves today published a thread about flaws they need to reconsider given the evidence we’ve seen. This is besides the fact that running an SNS is completely financially a non-starter for services that aren’t guaranteed to produce $4k+ a year. Token voting DAOs are volatile to time and interest. I’m building something I want to be as dependable as the US Postal Service with a cost as small as possible to the user because it is a piece of basic infrastructure that 10,000 other things can be built upon. There is no profit motive, just common good. It does not need an SNS.
Yes. This is an interesting thought.
I’m literally asking for no-governance changes and no updates. I simply asking DFINITY how they would vote a particular type of motion proposal. I’m not sure in which sense this qualifies as overreach as the system seems to allow anyone to make a proposal if they have 10 ICP.
Respectfully, this conversation started months ago and DFINITY asked me to have it. I gave up on normal a long time ago. If we sit around waiting for normal we’ll never ship a thing.
1 Like
It makes sense, just a lot of problems could arise. You could always start with the utility board after all. The rest depends on the NNS (definitely not on me). Just trying to help in figuring out how things may play out. If veto motion proposal requires simple majority accept to stop the upgrade and a lot of neurons don’t like these proposals - voting reject on all of them, just because they find them out of place. Then you won’t really get a veto when there is a good reason for it. If it’s the opposite (reject to veto), then there is a high chance no upgrades will pass if someone makes veto proposals.
You kind of need the whole NNS to be on-board to get unbiased veto votes. If let’s say 20% always reject them, because they don’t like the idea and there is something that one side likes and the other doesn’t. The veto has higher chance to fail and upgrade will pass. This will put the utility board in control I guess. But again it’s probably not something that matters when it comes to a simple service that nobody can’t exploit in their favor.
1 Like
Sorry for the delay. Let me answer this question specifically.
DFINITY would also be OK abstaining from motion proposals that represent veto options.
Again a few things that came up when I was thinking about this:
- Note that, probably even more so if DFINITY abstains, it could be that other known neurons (and their followers) could make a up a substantial part of the voting power. I think you accounted for that and in both approaches one relies on the fact that enough voters care enough to really examine the proposal and vote properly.
- I don’t recall exactly how long you wanted to wait with upgrade proposals in the veto option. Since NNS proposals can take up to 8 days and if you would like to give some additional time for people to react to upgrade proposals (maybe they first have to analyze them before deciding to veto), it might be that the upgrade proposals need quite some delay around at least 2 weeks. This is of course longer than a direct upgrade proposal would take, so probably a disadvantage of this compared to the other approach - especially if there is ever the need for an urgent upgrade due to a bug. Would non-vetoed proposals still be adopted faster but give the people a chance to challenge it if needed? Might just be another factor to consider..