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.
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.
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.