Caveat: If it ends up being that the solution to the issue(s) described in the SNS-1 postmorten is a simple configuration change or bug fix, then the actions described in the topic may not be necessary.
First off, I want to say congratulations to the SNS team - this was a big step forward for the platform
Today’s SNS-1 test run experiment (while technically successful, nothing crashed ) shows some of the potential issues with the SNS decentralization sale sharing the same subnet as the NNS.
When an unusually large amount of requests started hitting the SNS-1 decentralization sale, 5xxs were regularly returned and slowed down not just the SNS-1 participation sale, but the entire NNS subnet, including the ability to vote on proposals (potential NNS and IC security vulnerability), the IC Dashboard, and the ability to transact ICP throughout the IC via the ICP Ledger.
While the ability of the NNS and canisters to handle load should be improved, having these types of issues only further highlight the need to decouple and distribute as much functionality and load from the NNS to other subnets as possible. Until load scalability issues are solved, the NNS should not take on further load bearing burdens.
Side note: I’m also curious regarding how the NNS is load tested and how many update requests/sec both the NNS subnet and NNS canister can handle.
I wonder how fast the SNS-1 sale would have been if there weren’t any hiccups this isn’t a shot, I’m honestly just curious how fast it would have sold out
As a suggestion for future “load tests” going forward, in the future maybe DFINITY can offer ICP rewards to all of the participants (x amount of ICP split amongst all sale participants) instead of requiring that everyone spend 1 ICP to participate. That will ensure an organic and realistic amount of load hits the network, similar to that of an anticipated project’s SNS launch. Otherwise, I’m not sure that an “SNS-2 test” launch would attract as much participation and traffic as this morning’s SNS-1 sale.
I’ll further add that having the launchpad in the same domain as our ICP and NNS holdings is a massive regulatory risk. Can we at least get launcpad.ic0.app or something similar to host the launch pad?
Principals can be shared via the trusted domain functionality.
Why turn the NNS into an ICO machine when all of it can run completely trustlessly and disconnected on the IC? It is one thing to argue that the IC has lots of good uses so if some unregulated ICOs are going on it isn’t worth shutting the whole thing down. On the other hand, if it is explicitly tied to the NNS then no regulatory entity on earth has the discernment to see it for anything other than an unregulated ICO machine. The first time someone gets a sale approved and then manipulates the platform into a Ponzi we’re going to get all the wrong kind of attention on the NNS and our eight-year neurons may become inaccessible if nns.ic0.app gets blocked in our local jurisdictions.
Could have been done in minutes, it’s hard to say. As it stands it still went pretty quick, even with all the problems. And yeah, there was no crash, no need to relaunch. It was a success and shows where fixes are needed.
We can’t have the NNS slowing to near non-function twice in a week ever again.
I also agree that the regulatory aspect needs to be fully thought through.
As an aside - how were these issues not considered before; was it truly a surprise that the NNS couldn’t handle slight congestion? Why wasn’t this foreseen?
Has DFINITY not considered the ramifications of allowing ICOs on their governance dapp?
I’m sure they’ve considered it, and likely spent a large number of digits on lawyers to advise them, and they likely have a bunch of good info on the risks involved, but those aren’t public. I know they do their diligence, but it still makes me nervous not being able to see the reasoning myself.
Agreed; I should preface my slightly accusatory comment with the fact that I am nothing more than an ICP holder (that is; I have no idea of the complexity of coding on the IC)
I’m also slightly annoyed that I missed SNS-1 as a result of the NNS not loading due to the congestion.
Regardless, food for thought. Overall, we need more communication from DFINITY.
Regulation aside what are the advantages of having the launchpad in the NNS? The only one I can think of is using the NNS as a storefront for upcoming projects.
The two big technical problems that I identified were:
Double spend problem. Some folks submitted two ICP rather than one ICP.
Extremely slow to the point of not working.
Any others?
I do think we need to do this a couple more times, make sure it’s smooth before we let OpenChat go down this path.
Maybe we should consider voting to burn all SNS1 tokens and giving it another go to make sure all the various issues are resolved. Take 2 if you will. Or we just do the SNS2 before OpenChat.
Is it not possible to put the SNS in a different subnet AND keep the launchpad in the NNS front end? So we can just remove it from the front end if we run into issues.
) shows some of the potential issues with the SNS decentralization sale sharing the same subnet as the NNS.
this isn’t a shot, I’m honestly just curious how fast it would have sold out