I’ve recommended to ICDevs that we reject the acceptance of the of the SNS wasms we will vote in the next 24 hours.
We recommend that all SNS instances run in applications mode and not be system level canisters until the system has proven reliable and regulators have made their intentions clear.
Further, If the SNS runs in NNS.ic0.app we believe that regulator restriction of the url will be a real threat and that many will lose access to their neurons and dfinity’s intentions to this objection have not been made clear. If it is run in a system level canister we recommend exposing the functionality in a non-ic0.app domain.
We know the team has been working like crazy and we can’t wait for the functionality, but wish we had a burn in period before we make it a system level application.
I agree, this is a major concern for me as well. I’m interested in learning more about where exactly the SNS will be “hosted” from. If it’s built into the NNS, I agree that it’s a possibility to run into regulatory issues, as it sounds like the SNS is meant to be an investment.
I 100% agree on your points with respect to the SNS running on ic0.app (and for that matter everything that is currently running on ic0.app), but I’m not sure just how far away we are from having multiple IC domains, and to reject on this principle may not be realistic.
In terms of moving the SNS from system level to application (canister) level, I’m not sure I quite agree with this. I think maybe we should get someone from the SNS team on hear explaining why the SNS wasms (not deployed SNSes) needs to be at the system level and not at the application level.
Tagging @lara@diegop to hopefully answer this question.
I do however agree with you on rejecting these proposals - for the following reason:
Apparently in this past week’s R&D there was a failed demo related to the SNS. All I’ve seen so far is the smiley dapp example. More complex apps like DSCVR have many asset canisters, or in the case of OpenChat thousands of canisters. I honestly have no idea how they are going to successfully upgrade thousands of existing canisters through the SNS.
I’d like to see a more complicated integration (than just a smiley dapp), or see a test run video of the OpenChat team working this through on the DFINITY test net before the SNS goes live.
It actually should be fairly easy using the new certified domain functionality. You could even have your same principle. Have just your NNS neurons on NNS.ic0.app and an integrated solution with the SNS at SNS.app using the same principals. This would make me feel a lot safer.
I still like SNSs proving themselves and issuing their tokens in application mode and then “promoting” them to a system subnet if they demonstrate success.
Voting to approve an SNS feels a lot like a token offering. Voting to upgrade or move a token to a different subnet seems less “target on our back-y”. I don’t doubt that dfinity has done an amazing amount of research as to why there may be little regulatory concern, but I’d like to see it more transparent.
As an NNS voter I don’t want to be on the hook for approving the issuance of the next LUNA that everyone thinks is great until it isn’t.
It isn’t that I disagree with a flourishing SNS future, I am just convinced that there is a short term path with significantly less risk to the entire ecosystem.
Hi all,
Lara here from the NNS team. Thanks for tagging me!
@skilesare could you elaborate a bit on what you mean by this? I don’t quite understand what you mean by an “instance running in application mode”.
We recommend that all SNS instances run in applications mode and not be system level canisters until the system has proven reliable and regulators have made their intentions clear.
Maybe this is clear, but let me explain a bit more where the SNS canisters will live and what these proposals do. Maybe this can help getting to the root of the concern.
Where will SNS canisters run?
The SNS canisters, which can also be called an “SNS instance”, will not run on the NNS subnet. Rather, they will be deployed to a new subnet “SNS subnet” that you can inspect here. As you can see on the dashboard, this is an application subnet.
On this SNS subnet there will only be SNSs that run code that has been tested, inspected, and vetted by the NNS community. This will simplify verification for users, who can just check that the canisters they interact with are on this subnet and can infer that the code running by these canisters has been vetted. To realise this, the vetted SNS wasm versions are stored on a canister that is called SNS wasm modules canister, or SNS-W for short. This is an NNS canister. It stores these SNS wasms and, if a new SNS is installed, it creates the new SNS canister, but on another subnet, namely the SNS subnet.
What is the purpose of the submitted proposals?
As mentioned above, the SNS-W stores the SNS wasm versions. In these proposals, we suggest to “vet” the first wasm versions for each of the SNS canisters and populate the SNS-W with them. If the proposals are adopted and we subsequently install and SNS on the SNS subnet, the SNS canisters would be installed with these wasm versions.
Under what URL will users be able to interact with the SNSs?
SNSs will likely have many frontends. In particular, we think that a lot of dapps who decentralize will built in the SNS frontend as part of their existing dapp UI.
As not all projects have the resources to do so and to attract more investors, the idea is to also integrate an SNS frontend to the NNS frontend dapp that already exists. As I am not a frontend expert, I’ll check if someone else can maybe provide even more information here. However, I would like to point out that the FE change is not what is happening with the proposals that are mentioned in this post.
I hope this can help a little to clarify what we are voting on in these proposals!
I think maybe we should get someone from the SNS team on hear explaining why the SNS wasms (not deployed SNSes) needs to be at the system level and not at the application level.
To answer this particular question: It would have been an option to store the wasms directly on the SNS subnet. In fact, this was our original design proposal. The main reason, why we changed this design (see this post) is that having it on the NNS allows us to have one place with all the relevant information even if there are multiple SNS subnets in the future.
Thank you @lara ! This is the most succinct description I’ve seen of this and it is really helpful.
I’m going to ask a few questions that may be very stupid and/or obvious, so please forgive the ignorance where it occurs.
Can I install these wasms myself without an SNS interaction to a non-sns sub net? I would consider this “application mode.”
If I do the above, I’d assume that the wasm hashes of the canisters in my controlled canister would be the same and just as easy to verify as a subnet ID.
Is there anything in the SNS code that would require a different subnet with different rules(like cycle limits).
Can I self compile these wasms?
Do I have to ask the NNS if I can have an instance of these in the SNS subnet or can anyone deploy them if they pay the cycles.
If the NNS won’t approve my request will there be a clear pathway to deploying them in my own on day 0 to a non-NNS subnet.
On the front end questions, I think my concern is that I’ll have non-ICP tokens with a significant difference in decentralization, ideology, implementation, regulatory scruples, sinning in NNS.ic0.app and that one of them will have a significantly higher chance of regulatory scrutiny than ICP does. I’m as excited about investing in some in these projects as any one, but I don’t want them affecting my access to existing investments in ICP which has it’s dashboard(and only avenue of access) at.
When this change to NNS is suggested, what kind of proposal will it be? Any chance we could have a “temp check” on this. /
I can’t wait to see the amazing work you all have done on this, but, maybe at beta.sns.app at first?
I have immense faith in the DFINITY team, and I hope this discussion is seen as an attempt at increasing transparency more than a challenge. If the NNS is going to be put in charge of approving these things, we need to understand them and if we have a misunderstanding we need a place to have those corrected. @lara has already adresses some of my issue with understanding and I’m looking forward to learning more.
ICDevs is basically saying they want DFinity to give them the ability to create parallel non official SNSs otherwise they down-vote this feature that we have all been eagerly waiting for. I sense conflict of interest.
Why must all of this go through the NNS? Couldn’t Dfinity simply provide us some bindings and let the community implement the same features? IMO it would have solved many concerns some members have with the SNS and possibly allow us to build even cooler stuff. e.g the ability to use our VP in other dApps or programmatically move maturity to other neurons.
I’m going to ask a few questions that may be very stupid and/or obvious, so please forgive the ignorance where it occurs.
This is a complex system. Please feel free to ask questions.
Let me try to clarify what I can:
Can I install these wasms myself without an SNS interaction to a non-sns sub net? I would consider this “application mode.”
Yes, you can download the code, build the wasm and install them on an application subnet or you can download the already built wasms and install them on an application subnet.
The difference of an SNS on the SNS subnet and what you call “application mode” would be that the SNSs on the SNS subnet can only upgrade to wasms that are in SNS-W (although the time of upgrade is up to SNS vote). An SNS in “application mode” could potentially diverge from this.
I have to admit: This is the design and I have to double check if the “possibility to diverge” is currently behind a feature flag or already enabled if you install an SNS canisters right now. We focused a bit more on the other path, but this is the plan.
If I do the above, I’d assume that the wasm hashes of the canisters in my controlled canister would be the same and just as easy to verify as a subnet ID.
It is correct that you could verify the wasm hashes.
Whether this is just as easy I think depends on the perspective, on who you trust, and on the technical knowledge of a user.
For an SNS on the SNS subnet, if I verify once that the SNS is on the SNS subnet and if I trust the NNS community to make good choices, then I don’t need to verify this every time I interact with the SNS canisters. You could claim something similar for an SNS in “application mode”, but the difference is that you need to trust the SNS community (as they could upgrade to any random SNS ledger e.g.).
If a frontend (for example the NNS frontend dapp) has the convention that they only display SNSs on the SNS subnet and if I am a user who trusts this frontend but am not able/ willing to use CLI tools, then this could be considered to be easier.
Of course a FE could have another convention of what is a “good/ vetted SNS”, but letting the NNS community verify the code seemed like a good first step.
Is there anything in the SNS code that would require a different subnet with different rules(like cycle limits).
You mean different compared to an application subnet? No there is not. The SNS subnet is really just an application subnet with the exception that there is only one way to deploy canisters to it (which is over the SNS-W).
Can I self compile these wasms?
Yes this should be possible
Do I have to ask the NNS if I can have an instance of these in the SNS subnet or can anyone deploy them if they pay the cycles.
In the long-term design: Everyone can install SNS canisters on the SNS subnet as long as they pay enough cycles, but the governance will be in a “pre-genesis” mode as it might not yet be decentralised. An NNS proposal is then used to start the SNS sale, which will lead to SNS genesis if successful.
This is just one way to decentralise and alternatives might be added in the future (see this original forum post).
Right now and in the coming weeks: Right now it is not (yet) true that anyone can install the SNS canisters. This is currently guarded by a whitelist on SNS-W that can however be changed via NNS proposal in a decentralised way.
The main reason for this is that we want to launch an experimental SNS in production to show users how SNSs will work and to get some more confidence that all works smoothly in production before launching an SNS for any major project. At this stage we do not recommend that real projects release SNSs.
If the NNS community agrees, we could then leave the whitelist there for the first SNSs as a means to control of how quickly SNSs are deployed (and e.g., monitor that all still works smoothly with multiple SNSs). Eventually, the plan would be to remove the whitelist and it would be as stated in “long-term design” above.
If the NNS won’t approve my request will there be a clear pathway to deploying them in my own on day 0 to a non-NNS subnet.
You mean whether it is then possible to deploy the SNS canisters on another subnet? It should be, but to be honest we focused our efforts, including testing and documentation to the path for SNSs on the SNS subnet in the last weeks as we thought focusing on one path first is more efficient.
When this change to NNS is suggested, what kind of proposal will it be? Any chance we could have a “temp check” on this. / I can’t wait to see the amazing work you all have done on this, but, maybe at beta.sns.app at first?
I think this will just be an upgrade of the NNS frontend dapp to enable this functionality.
As I said I am not the expert here and will leave the answer to this for others.
This is the key that I think I misunderstood. I like this a lot. If I’m reading this right, Anyone can launch and get started. This allows them to show what will be governed and and how their system will work. It is only the public sale that is gated.
The feedback I’ve received from the a dev or on the board is to follow dfinity for these wasm approvals.
We would love the domain issue adresses before the NNS front end upgrade.
The cost consists of a number of cycles that need to be provided initially. These cycles are then distributed among all the SNS canisters and can be used by them.
The design specifies that it is initially set to roughly 250$ worth of cycles.
One thing to note: the cycle costs for different operations are not special on the SNS subnet compared to other subnets. However, it is planned that subnets with more nodes are more expensive in general. Therefore, projects that install an SNS on the SNS subnet should expect that the operations on these canisters will be more expensive than the same operations would be on an application subnet right now.
As @Severin pointed out, the SNS subnet currently has 34 nodes, thus more than most application subnets currently have. (Thanks @Severin for the link!)
