1. Technical issues exposed in this SNS-1 Decentralization Sale
1.1 User repeated deductions
The rules for the SNS-1 decentralization sale were simple: total 3141 SNS-1 tokens are for decentralization sale, and up to 1 ICP can be used to purchase 1 SNS-1 token.
But many users report that they have been deducted more than once for 1 ICP. I can’t collect specific numbers of total number of users affected (DFINITY should have that numbers), but here are just three examples of community feedback that I have collected:
Although after 48 hours the extra ICP deducted has been returned to users, this problem occurred at the launch of the sale, reflecting the serious functional bug in the SNS sale code.
Any computer science major student knows how to develop an e-commerce system that meets basic functional requirements. Products are either traded for the price amount or not traded without deducting more money from the user (no DOUBLE SPENDING). Even if you encounter the traffic of Black Friday online shopping, users may face long delays, service degradation, or even service interruption, but basic functions must also be guaranteed, and users should not pay more than once!
1.2. Sybil Attack / Front-run Prevention
NNS/SNS team blamed bots for causing issues and they have acknowledged (https://twitter.com/dfinity/status/1598399777284427776 ) bots heavily impacted this launch, with over 1/3 of SNS-1 being purchased by robots. This however raises questions about whether the NNS/SNS team responsible for the launch had any experience in product design. Bots are very common in both the web2 and web3/crypto worlds, yet the team seemingly ignored them beforehand and later blamed the robots for the problems with the launch.
The crypto industry already has well-established sybil-attack solutions for airdrops or token launches (of course each with its own advantages and disadvantages). Even within the IC ecosystem, there have been proposals like DOM’s favorite project People Parties(People Parties - Community Proposal), as well as community projects like ModClub(http://modclub.app) , the Supernova-winner project Proof of Personhood(https://devpost.com/software/web3-mkdgh6) , and even there is the cycle faucet anti-robot solution (DFINITY DEV OFFICIAL ) . It’s clear that the NNS/SNS team was living in their own bubble without sufficient communication with the other DFINITY team members.
Additionally, the presence of bots also raises the issue of front-running. It’s likely that bots or scripts were used to directly invoke the NNS backend to complete front-running. Moreover, NNS initiated the public call for the function through the front end, added orders and notifications to SNS through its own backend, inevitably concentrating all traffic in one place. This easily led to congestion. Regardless of how strong the ledger’s performance was, the traffic was still congested at the NNS frontend and its single Canister. The distributed processing of concurrent issues was not well considered.
1.3. The Subnet node outage and congestion issues
Why did 5 of SNS subnet’s 34 nodes go offline during the initial SNS-1 sale? Why did the SNS subnet also crash for several hours after the SNS-1 sale was over?
Some members of the community celebrated (https://twitter.com/danostrovsky/status/1597637014341357568 ) the huge tps achieved during the SNS-1 sale, but we need to be aware that during this 1-2 hour period, only 3141 SNS-1 tokens were finally bought by 3141 NNS wallets. Therefore, most of the transactions are invalid, blocking the network and wasting a lot of computing resources. The number of effective transactions is far lower than the data shown on the panel, which is only close to 1 TPS.
1.4. Lack of Rigorous Testing
If SNS-1 decentralization sale had undergone thorough and rigorous testing, particularly stress testing, many of the issues mentioned above could have been discovered and resolved.
While SNS-1 was intended as a test, it was essentially a PUBLIC BETA test in a production environment, with thousands of users investing 1-2 hours and their own real money to participate. Low-level bugs should not have been discovered at this stage. Public beta testing should be used as a last line of defense to discover complex software defects or human economic incentive issues.
I have heard that members of the NNS/SNS team previously worked at well-known big tech companies such as Google/IBM. It is hard to believe that Google/IBM would have such low engineering quality standards.
If the NNS/SNS team’s testing engineering issues are not addressed fundamentally, the community will have no confidence in the immediate release of the OpenChat token.
1.5. Lock-up time
Why was the lock-up time for SNS-1 so random, when it was previously announced as 30 days, and why was it adjusted before the launch? This is a big product issue.
DFINITY‘s Manu has made a detailed post-incident analysis, which can be found here: https://forum.dfinity.org/t/degraded-performance-during-SNS-1-decentralization-sale-incident-retrospective-tuesday-november-29-2022/17005. His analysis identifies the cause of the performance issues mentioned in 1.3 and suggests solutions, but does not provide satisfactory answers for issues such as the problem with repeat charges and other issues. And I hope to see NNS/SNS team come forward to provide their post-mortem.
In summary, NNS, the first usable wallet launched by IC and developed by DFINITY, not only takes on the functions of transfer transactions, neuron pledge and community governance, Canister creation, and top-up. Coin holders and community users had high expectations.
However, since its launch more than 1 year ago, poor loading performance, poor user experience and inability to interact with DApp have been the criticisms of NNS. DFINITY wanted to improve user experience by revamping the front-end, but lacked knowledge and experience in building user-side products and did not achieve good results.
The experimental release of SNS1 Decentralized Sale saw transaction congestion and robotic rush, which DFINITY explained was an experiment to expose the problem. However, as a product for end users and ICP holders, this attitude is quite irresponsible. Participants are not only investing real money but also with a real desire for the performance and performance of the IC. The experiment was not meant to be 100% successful, but the problems and reasons for failure were not officially pinpointed and held accountable.
The biggest reason for SNS1’s big failure in experience is the design of NNS, and the front-end and back-end teams are responsible. Apparently, the team did not have enough knowledge and testing on the completeness of business processes, sybil-attack, and performance guarantees.
The successful completion of the decentralization mechanism to offer is to decentralize while achieving the effect of horizontal scale out, which should allow more builders and users to help tokens sale and circulate. In the design process of SNS, the team did not engage enough with the community. It was only in the public beta testing before the final launch that so many problems were discovered, giving the community a huge surprise.
SNS decentralization sale 发售的规则很简单：发售3141个SNS-1代币，最多1 ICP购买1个SNS-1，但是有多位用户汇报他们被扣了超过一次SNS-1的ICP。具体数字我无法统计，但以下仅为我收集到社区反馈的三个例子：
crypto业界已经有比较成熟的针对机器人的空投或者抢售抗女巫攻击方案（各有不同利弊）。即使在IC生态，Dom提出过People Parties并且DFINITY基金也通过提案, 社区里也有像ModClub项目，Supernova获奖项目Proof of Personhood, 以及cycle领取水龙头防机器人 的方案。显然 NNS/SNS团队活在自己的泡泡里，跟DFINITY内部团队也没有充分的交流。
为什么在 SNS 初始代币交换其间，SNS 的 34个节点掉线了 5个。为什么同时 SNS-1 售完后 SNS 子网也宕机了几个小时？
有社区成员为SNS-1发售时达到巨量的tps而欢呼 ，但我需要清醒的认识到，在这1-2小时内，只有3141个SNS-1 token，被最终3141个NNS钱包购买成功。所以绝大多数的交易都是无效交易，阻塞网络并浪费了大量计算资源。真正有效交易远低于面板展示的数据，接近1 TPS而已。
综上，NNS作为IC推出的第一个可用型钱包，由 DFINITY 开发，不仅承担了转账交易，神经元质押和社区治理，Canister创建和充值等职能。 持币人和社区用户寄予厚望。
然而上线以来，加载性能差，用户体验差，不能和 DApp 互动一直是 NNS 的诟病，DFINITY 想通过改造前端来提升用户体验，但缺乏对用户侧产品打造的认知与经验，没有取得良好的效果。
此次 SNS1 的实验性发行，发生了交易拥堵和机器人抢购，DFINITY 解释这是为了暴露问题做的实验。但作为一个面向持币人的产品，这种态度是极不负责的，参与者不仅是真金白银的在投入，而且是带有对IC的性能和表现的真实愿望。实验并不是要百分百成功，但是失败的问题和原因官方并没有准确定位和进行问责。
SNS1 在体验上的大失败，最大的原因就是 NNS 的设计问题，前端和后端团队要承担责任。显然，团队对业务流程的完备，防刷，以及性能保障都没有足够的认知和测试。