Is my 5-year dream of ICP and DFINITY shattered? Is there still a future? SNS-1 Decentralization Sale questions

(English is not my native language, the following content is written in Chinese and the English part is translated by ChatGPT)

My Story with ICP

Hey, community, sorry for the title.

I don’t speak much in English on social media (I occasionally speak on Twitter https://twitter.com/shaoan_ , and for the first time writing a long post on this forum).

I have been a firm supporter of ICP and DFINITY since 2017 when I volunteered to help DFINITY build the earliest community, ICPL. In 2018, despite the coldest winter of the crypto market and my personal financial difficulties, I still invested 20k ETH (worth over ten of millions of dollars in 2018, much more at today’s ETH price) in DFINITY.

Yes, ICP’s price fell below my private round price (4.5 dollars), but I still have confidence and have been looking forward to the launch of SNS-1 and OpenChat. I absolutely believe in IC’s technical strength and innovation, and I even spent more than one million dollars to run ICPL.app (http://icpl.app) not for profit without expecting any return. I want to devote myself to this great endeavor that I believe can change the world in my lifetime, the dream of the internet computer.

I have no motivation or any reason to FUD ICP.

After the horrible night of November 30th, I was very disappointed. I entered the crypto market in 2015, but the terrible experience of SNS-1 Decentralization Sale was unprecedented, even worse than the earliest ETH ICOs I participated in. I almost spent the whole night refreshing and logging in repeatedly, but the 500 or 503 error message occupied the screen. I used to believe that ICP was infinitely scalable and that the launch would be smooth and successful, but now it feels like a joke.

SNS-1 Decentralization Sale was chaotic, users could not access, transactions were congested, repetitive fee deductions (without instant refunds), no consideration of robot attacks, confusion about the lock-up mechanism (inconsistent with the previous description of the one-month lock-up time), etc. The fact that so many problems have arisen shows that the team responsible for SNS-1 Decentralization Sale obviously lacks some basic knowledge and operational experience of crypto. What makes me feel helpless and angry is that the careless and sloppy work attitude of the development team has also led to a large number of low-level errors.

This has caused great damage to the brand image of DFINITY and IC: ordinary users do not understand the technical principles of IC, so most users will think that the actual effective performance of the IC chain is too low (even lower than ETH) which has caused congestion, and some people even regard the entire work of IC as a scam.

In short, SNS-1 Decentralization Sale has a huge difference from my expectations. I am not a technology expert, but I have seen every day for more than a year that developers have been struggling to develop due to various reasons of DFINITY. I’m deeply heartbroken.

Here is a list of questions that I have gathered from a number of crypto native/experienced developers in the IC ecosystem, especially in the Asian community.

我与 ICP 的故事

嘿,社区,很抱歉我打出了这样的标题。

我在英文社媒很少发言(我偶尔在Twitter说话 https://twitter.com/shaoan_ ,在论坛第一次发长文)。

我一直是 ICP 与 DFINITY 最坚定的支持者:在 2017年,我就自愿地帮助 DFINITY 建立了最早的社区ICPL。在 2018年,尽管那是加密市场最深的寒冬,也是我个人财务最困难的时候,我依然向 DFINITY 投资了2万ETH(当时法币价格超过1千万美金,如按今日的ETH价格更高)。

是的,ICP 的价格跌破了我的私募价格(4.5刀),但是我依然充满信心,并一直期待着 SNS-1 与 OpenChat 的 launch。我绝对相信 IC 的技术实力与创新,我甚至花费了 100 多万美金,在不期待任何回报的前提下,出资运行了 ICPL.app 这个非营利性组织,我也想在我有生之年推动一件在我认为能改变世界的伟大事情,就是互联网计算机的梦想。

我没有任何动力与理由去 FUD ICP。

但在11月30日那个糟糕的晚上之后,我感到非常的失望。我 2015 年就进入了加密市场,但 SNS-1 Decentralization Sale 的糟糕体验是我从未见过的,就连我参与过 ETH 最早的 ICO 都比它更好。我几乎一晚上都在不断的刷新,并重复登录,但是 500 503 的错误提示占据了屏幕。我曾经相信 ICP 是无限扩展性与 web speed,但是现实狠狠地嘲笑了我。

SNS-1 的发售简直是一片混乱,用户无法访问、交易堵塞、多次扣款(且没有即时退款)、没考虑机器人攻击、锁仓机制混乱(与之前描述一个月锁仓时间不符)等等。出现如此多的问题,说明负责 SNS-1 Decentralization Sale 的团队显然不具备 crypto 的一些基本常识与操作经验。让我感到无奈与愤怒是,开发团队粗心、不严谨的工作态度也导致了大量低级错误。

这已经对 DFINITY 与 IC 的品牌形象造成了很大的破坏:普通用户不了解 IC 的技术原理,因此大部分用户会认为是 IC 链的实际有效性能过低(甚至低于 ETH)导致了拥堵,有些人甚至将 IC 的整个工作视为骗局。

总之SNS-1发布与我的预期有着巨大的出入,我并不擅长专业技术,但上线一年多来每天看到专业的技术开发者因为DFINITY的各种原因让开发变的举步维艰,我就感到心痛,以下是我集合了IC生态里特别是亚洲社区多位crypto native/经验丰富的开发者交流后列出的问题。

47 Likes

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.

Summary

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.

1. 本次SNS-1发行暴露的技术问题

1.1 用户重复扣款

SNS decentralization sale 发售的规则很简单:发售3141个SNS-1代币,最多1 ICP购买1个SNS-1,但是有多位用户汇报他们被扣了超过一次SNS-1的ICP。具体数字我无法统计,但以下仅为我收集到社区反馈的三个例子:

虽然在48小时后多扣的ICP已退回给了用户,但这个问题在发售上线时发生,反映了SNS发售代码存在的严重功能性Bug。

任何一个计算机专业的大学生都清楚如何实现一套电商系统,满足基本功能要求,商品要么按照金额成交,要么没有成交,而不会多扣用户的资金。即使碰到黑色星期五电商的流量,用户可能面临长延迟,服务降级甚至服务中断,但基本的功能也必须会得到保障,而不会重复扣款。

1.2 机器人女巫攻击/抢跑

DFINITY事后承认 了机器人严重影响了这次发售,超过1/3的SNS-1被机器人抢购。这难免不让人猜测,负责这次发售的NNS/SNS团队是不是完全没有产品设计的经验?机器人无论是在web2还是Web3/crypto世界里,都是广泛存在的,他们竟然完全无视,并事后把发售的问题归咎于机器人。

crypto业界已经有比较成熟的针对机器人的空投或者抢售抗女巫攻击方案(各有不同利弊)。即使在IC生态,Dom提出过People Parties并且DFINITY基金也通过提案, 社区里也有像ModClub项目,Supernova获奖项目Proof of Personhood, 以及cycle领取水龙头防机器人 的方案。显然 NNS/SNS团队活在自己的泡泡里,跟DFINITY内部团队也没有充分的交流。

另外,有机器人就必然有Front-run的问题。大概率有机器人或者有人用脚本直接调用NNS后端完成Front-Run。而且NNS通过前端发起公募的函数的调用,通过它自己的后端来去对SNS进行订单添加和通知,无疑让所有的流量都集中到了一个地方。非常容易造成堵塞。无论ledger本身性能多强,流量依然塞到了NNS前端和它自己的单个Canister上。分布式处理并发问题并没有很好的考虑到。

1.3 节点掉线和堵塞问题

为什么在 SNS 初始代币交换其间,SNS 的 34个节点掉线了 5个。为什么同时 SNS-1 售完后 SNS 子网也宕机了几个小时?

有社区成员为SNS-1发售时达到巨量的tps而欢呼 ,但我需要清醒的认识到,在这1-2小时内,只有3141个SNS-1 token,被最终3141个NNS钱包购买成功。所以绝大多数的交易都是无效交易,阻塞网络并浪费了大量计算资源。真正有效交易远低于面板展示的数据,接近1 TPS而已。

1.4 缺乏严谨测试

如果SNS-1上线前经过完整严格的测试,特别是压力测试,以上这些问题大部分是能被发现并解决的。虽然SNS-1本身是一次测试,但这是一次在生产环境里的公开BETA测试,有上千的用户投入1-2个小时,而且消耗用户自己真金白银来参与的。低级bug不应该有在这个阶段才发现。公开BETA测试应该作为最后一道防线,用来发现复杂的软件缺陷,或者经济激励问题。

我听说有NNS/SNS的团队成员之前在谷歌/IBM这些知名Web2企业工作,难以相信谷歌/IBM会有如此低的工程质量门槛。

如果NNS/SNS团队的测试工程问题不被根本性解决的话,接下来直接发布OpenChat代币,社区都不会再有信心。

1.5 锁仓规则

这是产品设计问题 ,为什么SNS-1的锁仓时间是随机的,之前说过的30天,最后上线前为什么做了调整?

总结

DFINITY Manu做了详细的事后分析。他的分析指出了上面1.3的性能问题的原因和解决方案,但重复扣款的功能问题和其他问题并没有很好的回答。

综上,NNS作为IC推出的第一个可用型钱包,由 DFINITY 开发,不仅承担了转账交易,神经元质押和社区治理,Canister创建和充值等职能。 持币人和社区用户寄予厚望。

然而上线以来,加载性能差,用户体验差,不能和 DApp 互动一直是 NNS 的诟病,DFINITY 想通过改造前端来提升用户体验,但缺乏对用户侧产品打造的认知与经验,没有取得良好的效果。

此次 SNS1 的实验性发行,发生了交易拥堵和机器人抢购,DFINITY 解释这是为了暴露问题做的实验。但作为一个面向持币人的产品,这种态度是极不负责的,参与者不仅是真金白银的在投入,而且是带有对IC的性能和表现的真实愿望。实验并不是要百分百成功,但是失败的问题和原因官方并没有准确定位和进行问责。

SNS1 在体验上的大失败,最大的原因就是 NNS 的设计问题,前端和后端团队要承担责任。显然,团队对业务流程的完备,防刷,以及性能保障都没有足够的认知和测试。

成功的完成去中心化机制来发售,就是要去中心化而达到水平扩容的效果,应该让更多人帮助代币发售和流通。在SNS的设计过程中,官方并没有这个思路,而是所有的环节都默认放在NNS或者SNS自己这里做,导致了能够参与的社区力量无法参与,进一步的无法获得准确有效的反馈。 在最后上线前的公测环节,才发现如此之多的问题,给社区一个巨大的意外。

17 Likes

2. Other IC technical issues that plague developers

I have also collected a number of technical problems that plague the developers of IC, which are not directly related to the SNS-1 decentralization sale but reflect the current dilemma of building applications on IC, and I list them below

2.1. Question about Canister Output Message Queue Limits

If a user request contains a chain of multiple awaits, when the request is not processed. After other user requests come in, their await will be interspersed, so that the number of output queue will soar and then exceed the limit and finally report an error. If canister doesn’t distinguish between internal await and external await, it’s hard to handle concurrency, and it’s hard to implement DEFI projects.

Link to the post: Canister Output Message Queue Limits, and IC Management Canister Throttling Limits - #17 by bitbruce

2.2. Heap out of bounds" error when upgrading canister with Motoko

When canister takes up a little more memory (e.g. 70M), upgrading canister will result in a Heap out of bounds error.

Link to the post:Heap out of bounds , use motoko - #11 by bitbruce

2.3. How does the user connect to a properly working node?

When the user gets data from canister, the route is proxied by ic0.app and if the node being routed does not work properly, then the user will get the wrong data. Therefore, the user needs a list of nodes to choose from. and have ic0.app route to the node that works properly.

Link to post: https://forum.dfinity.org/t/how-users-can-connection-a-node-that-work-properly-we-may-be-getting-the-wrong-data/16856

2.4. Bug of Trie data structure

Trie has an error in filter, Trie.get()/Trie.find() cannot return data.

Post link: A Trie.filter() Bug

GitHub:Bug: user reported bug in Trie.filter · Issue #369 · dfinity/motoko-base · GitHub

github.com/dfinity/motoko-base

Trie.get()/Trie.find() does not return data, but the data is present.

opened Nov 16, 2022

closed Nov 24, 2022

iclighthouse iclighthouse

We had this issue during a stress test. orders used the Trie module and had a to

2.5. Nat serialization problem

Nat, as a base type for Canister development, does not support rust standard serialization other than candid (such as cbor\json\bincode), need to add support to facilitate developers to implement their own serialization optimization.

Or the best serialization and deserialization solution can be given, both the size after serialization and the efficiency of serialization/deserialization should be taken into account.

GitHub:As a developer, I want to [Nat] support bincode/serde_json/cbor deserialize · Issue #374 · dfinity/candid · GitHub

2.6. Boundary node load

Since long links cannot be established between icp boundary nodes and the browser, I have to send all requests to boundary nodes at once to ensure performance.

When I send these requests, either to fetch data or to upload data, the feedback from the boundary node becomes very unstable after a certain threshold, and many requests become difficult to guarantee QOS after a certain threshold (about 300M of data fetched in a short time).

Solution: The condition of rejecting POST requests should be changed or websocket should be added as soon as possible.

2.7. Adding an optional unique Principal ID for II

Internet Identity (II) is a great way to log in, but Principal inconsistencies make it difficult to interoperate identities between Dapps.

Users should be given more options. IIi should add a parameter to the login screen, or use means that would allow users to choose whether to keep a uniform Principal ID across Dapps.

2.8. Optimizing upload and download of large files

When a large file is uploaded and downloaded, to ensure the speed of the upload and download, I need to respectively.

When uploading, I need to slice the file into n 2M size chunks to upload.

When downloading, I can get up to 3M in size each time.

However, if a file is large and I want to get all the data, there are only two options.

Send all update requests or query requests to the edge nodes

Create a long link, and go to http_request, but http_request authentication is very troublesome

Solution:

Establish a long link to the edge node websocket (long-term recommendation)

Increase the load of single-ip post and get requests (short-term recommendation)

2.9. Optimizing the motoko-base library

The data structure algorithm of Motoko-base library is crude and inefficient, and the use of RBtree and Trie does not tidy up the structure when deleting data, resulting in growing space.

The unit test of Motoko-base library is not comprehensive, it is not tested extensively, boundary test, and there are many bugs.

GitHub

Issues · dfinity/motoko-base

The Motoko base library. Contribute to dfinity/motoko-base development by creating an account on GitHub.

https://github.com/dfinity/motoko-base/pulls

#Summary

These problems above are commonly reported by developers that DFINITY Foundation doesn’t pay enough attention to them, which seriously affects their development progress.

Just imagine that one or more of the following issues will keep causing developers’ applications (say a DEX) to fail or even lose user assets, which will result in users losing confidence in the application, the DEX project will get shut down, developers will have to leave IC, and eventually, IC will become no man’s land.

2. 其他困扰开发者的IC技术问题

我也收集到不少困扰社区开发者工作的技术问题,虽然跟SNS-1发售没有直接关系,但也反映目前在IC上搭建应用的困境,我一并列在下面。

2.1. 关于Canister Output Message Queue Limits问题

一个用户请求如果包含多个await的链条,当这个请求没有处理完的情况下。其他用户请求进来之后,他们 await 会相互穿插,这样的话 output queue 的数量就会飙升然后超出限制最后报错。一般正常大型项目,都会代码重构内部调用的,如果 canister 不区分内部 await 和外部 await 的话,那就很难处理并发,像 DeFi 这种项目就很难去实现。

帖子链接:Canister Output Message Queue Limits, and IC Management Canister Throttling Limits - #17 by bitbruce

2.2. 使用 Motoko时候,升级 canister遇到“Heap out of bounds”错误

当 canister 占用内存稍微大一点时候(例如70M),升级 canister 就会出现 Heap out of bounds 错误。

帖子链接:Heap out of bounds , use motoko - #11 by bitbruce

2.3. 用户如何连接到正常工作的节点?

当用户从 canister 获取数据时,路由由 ic0.app 代理,如果被路由的节点不能正常工作,那么用户将获取到错误的数据。因此,用户需要一个可以选择的节点列表。并让 ic0.app 路由到正常工作的节点。

帖子链接:https://forum.dfinity.org/t/how-users-can-connection-a-node-that-work-properly-we-may-be-getting-the-wrong-data/16856

2.4. Trie 数据结构 的 bug

Trie在filter时存在错误,Trie.get()/Trie.find() 无法返回数据。

帖子链接:A Trie.filter() Bug

GitHub:Bug: user reported bug in Trie.filter · Issue #369 · dfinity/motoko-base · GitHub

github.com/dfinity/motoko-base

Trie.get()/Trie.find() does not return data, but the data is present.

opened Nov 16, 2022

closed Nov 24, 2022

iclighthouse iclighthouse

We had this issue during a stress test. orders used the Trie module and had a to

2.5. Nat 序列化问题

Nat 作为一个 Canister 开发的基础类型,不支持除 candid 之外的 rust 标准序列化(如cbor\json\bincode),需要添加支持来方便开发者自行实现序列化优化。

或者可以给出最佳的序列化、反序列化解决方案 ,序列化之后的大小和序列化/反序列化效率两者都要兼顾。

GitHub:As a developer, I want to [Nat] support bincode/serde_json/cbor deserialize · Issue #374 · dfinity/candid · GitHub

2.6. 边缘节点负载

因为icp边缘节点和browser之间不能建立长链接,因此为了保证性能,我不得不一次将所有的请求发给边缘节点。

当我发送这些请求,无论是获取数据还是上传数据,在超过一定阈值后边缘节点的反馈都将变得非常不稳定,很多请求在超过一定阈值(大概短时间获取300M左右数据)就会变得难以保证 QOS。

解决方案:拒绝 POST 请求的条件应该更改或者尽快增加 websocket。

2.7. 为 II 添加可选的唯一 Principal ID

II是一个非常好的登录方式,但是Principal的不一致让Dapp之间难以互通身份。

应该给用户更多选择。II 在登录界面应该加一个参数,或者用的手段,可以让用户选择是否在不同的 Dapp 之间保持统一的 Principal ID。

2.8. 优化大文件的上传与下载

当一个大文件上传和下载的时候,为了保证上传和下载的速度,我需要分别:

  • 上传时,我需要将文件切成 n 个 2M 大小的文件块,才能上传。
  • 下载时, 我每次可以 get 到 3M 大的数据。

但是,如果一个文件很大,我要获取到所有的数据,只有两个方案:

  • 把所有的update请求或者query请求发给边缘节点
  • 建立长链接,走http_request,但是http_request的鉴权十分麻烦

解决方案:

  • 建立边缘节点websocket长链接(长期建议)
  • 增加单ip 发post和get请求的负载(短期建议)

2.9. 优化 motoko-base 库

Motoko-base库的数据结构算法比较粗糙,效率较低,使用 RBtree 和 Trie 在删除数据时不整理结构,导致空间不断增长。

Motoko-base库的单元测试不全面,没有经过大量测试、边界测试,存在不少 BUG。

GitHub

Issues · dfinity/motoko-base

The Motoko base library. Contribute to dfinity/motoko-base development by creating an account on GitHub.

https://github.com/dfinity/motoko-base/pulls

总结

上面的这些问题,开发者普遍反映DFINITY基金会重视程度不高,严重影响他们的开发进展。试想一下,以下一个或多个问题会导致开发者的DEX应用失效,甚至丢失用户资产,这会导致用户对应用失去信心,DEX项目将关闭,应用开发者流失,最终IC变成无人之地。

17 Likes

3. Questions about the Foundation’s engineering culture

It seems that with these specific examples above, we should think about whether there is an endogenous problem with the DFINITY Foundation engineering culture.

3.1. Lack of crypto Mindset

IC, as a decentralized public blockchain network, should maintain the crypto philosophy of thinking (Decentralization, Permissionless, Composabliltiy) and embraces the crypto experience and habits that are central to continued innovation, fostering a healthy eco-system, and ultimately winning. Clearly, IC hasn’t been doing a very good job of this.

DFINITY’s ignorance of the crypto user experience and development experience is exposed in the design of II, NNS, Infrastructure, and most recently SNS-1 sale. For example, SNS-1 does not take into account the most basic resistance to sybil-attacks, and the experience of using II, for example, is very different from crypto wallets such as Metamask. This directly led to difficulties in migrating the core users, assets, and developers of the existing crypto world to IC.

DFINITY’s R&D team clearly does not know enough about crypto. The infrastructure and architecture of DFINITY’s development on IC is excellent and solid, but many of the anti-crypto designs are inconvenient for developers.

This gives the community the impression that IC seems to care nothing about crypto users and developers, and the community has a hard time imagining and identifying with a team that lacks a crypto philosophical mindset and is building an infrastructure that will lead the crypto world.

To this end, my recommendations are to

  • Raise awareness of crypto mindset among the R&D team and conduct crypto onboarding for new employees;
  • Streamline the team, change the composition of the R&D team, and recruit more crypto-native employees, especially for product manager positions;
  • Invite teams from other mature crypto ecosystems to peer audit the product design and code;
  • Increase collaboration and communication with the crypto industry.

3.2. On the Foundation’s accountability mechanisms and transparency

At the end of 2021, NNS passed 25 roadmap proposals at once through governance, and almost all of the milestones are currently undelivered on time. The community and developers have been notified of delays time and time again, many projects have died while waiting, and the IC network looks to be at a standstill.

Since the DFINITY Foundation has taken the initiative to propose and undertake the work, what is the accountability if the related work is postponed or the code quality is not up to par? How to be accountable to the developers and users of the whole IC? If a feature cannot be delivered, does it need to be handed over to another team for development?

The governance of the code is also worrisome. The unit testing of the base library is not comprehensive and the community is allowed to use it without extensive testing and boundary testing. Some bugs that could have been found in testing existed in the codebase for a year until they were discovered by community developers reading the source code. This made the community start to worry about the Foundation’s capabilities.

At the same time, the community had no idea of the progress of the Foundation’s internal R&D team, and there was a serious lack of transparency. While much of this is an internal Foundation matter, proposals for the roadmap are voted on collectively by the community NNS, and the community has a right to know the details.

To that end, my recommendation is this.

  • Allow the community to pass work on to another DFINITY team or community team through NNS governance if milestones are not reached on time
  • Expand the size of the working group and invite community developers to monitor the development progress

3.3. Long-term neglect of the real demands of community developers

No response to the needs and questions from the community developers. No accurate roadmap and timeline for the community’s requests such as “decentralized boundary node”, “multi-replication subnet”, “DeFi subnet”, etc. the frustrated developers even had to rely on me, as a non-technical investor, to get the word out to DFINITY for bug submission.

Many dapp developers had to stop working because they had to wait for official changes to the core protocol. As a result, demand has not been met and some community developers have given up on the IC network, even for some of the best developers who won awards at the Supernove hackathon.

3.4. The DFINITY Foundation does too much of the application layer itself

Psychedelic/Fleek, once one of the most important developers in the IC community, sparked a big IC community discussion six months ago, in which one of their core ideas was that DFINITY should focus on the underlying protocol rather than the upper application services. The most recent development I’ve seen is that Psychedelic/Fleek has left the IC ecosystem for good.

Indeed DFINITY does not only provide the underlying capabilities but always tries to guide developers’ thinking at the application level and has developed some user-oriented products into the market by itself.

This is not fair to eco-developers, which not only squeezes the living space of community developers and puts them at a non-branded competitive disadvantage, but also greatly stifles the possibility of new applications and paradigms emerging.

In contrast, IC is not well documented and there is a serious lack of infrastructure and toolkits. Clearly, there is a serious lack of work here.

As an infrastructure, it should maintain its purity, i.e., allow developers to explore any type of application on it, without discriminating against any one application. Diversity is the foundation of a thriving ecosystem and the secret to the success of the ETH ecosystem. A thriving application within the ecosystem is a truly thriving one. No public chain makes the ecosystem prosperous by making its own applications.

For this reason, my advice is this.

  • DFINITY’s R&D team should focus on the protocol layer and toolkit;
  • Improve developer documentation;
  • Stop guiding developers at the application level and stop launching new dapp in the name of DFINITY;
  • Stop actively using NNS to add privileges to official DAPPs;
  • If DFINITY has to develop a demo, follow the principle of modularity and replaceability。

In a nutshell, I hope DFINITY learns from this gentleman

3. 对基金会工程文化的问题

看来上面的这些具体例子,我们应该思考一下,是不是DFINITY基金会工程文化有内生性的问题。

3.1. 缺乏 crypto 土壤

IC 作为一个去中心化的公共区块链网络,保持 crypto 的哲学思维(无准入、可组合、去中心化),接纳 crypto 的经验与习惯是必须的,这也是持续创新、吸引生态,并最终获胜的核心。显然,IC 在这方面做的不好。

在 II、NNS、基础设施,以及最近的 SNS-1 的设计中,DFINITY 对 crypto 用户体验、开发体验的无知都暴露了出来,比如 SNS-1 没有考虑到最基本的抗女巫攻击,比如 II 的使用体验与 Metamask 等 crypto 钱包有很大的不同。这直接导致了加密的核心用户、资产与开发者很难迁移到 IC 上来。

DFINITY 的 R&D 团队显然对 crypto 的认识不够。 R&D 团队的大部分雇员都来自 IBM 与谷歌等传统科技公司,对 crypto 并不熟悉,很多设计与思路甚至与社区背道而驰。DFINITY 在 IC 上的开发的基础设施与架构非常优秀,但是很多反 crypto 的设计却给开发者带来很多不便。

这给社区的感觉是 IC 似乎完全不在乎 crypto 的用户与开发者,社区也很难想象和认同一个缺少crypto哲学思维的团队,正在构建一个引领crypto世界的基础设施。

为此,我的建议是:

  • 提高 R&D 团队对 crypto 的认识,开展 crypto 的入职培训
  • 精简团队,改变 R&D 团队组成结构,招募更多 crypto Native 员工,特别是产品经理岗位
  • 邀请其他成熟 crypto 生态系统的团队对产品设计与代码进行同行审计
  • 与 crypto 行业加强合作与交流

3.2. 关于基金会的问责机制与透明度

在2021年底,NNS 通过治理一次性通过了 25 个路线图提案,目前几乎所有的里程碑都未按时交付。社区与开发者一次次被通知延期,很多项目在等待中死亡,IC 网络看起来陷入了停滞。既然 DFINITY 基金会主动提出了相关提案,并承担了工作,如果相关的工作被延期后,或者代码质量不达标,该如何问责?如何向整个 IC 的开发者与用户负责?如果无法交付功能,是否需要交给其他团队开发?

代码的治理也令人堪忧,base 库的单元测试不全面,没有经过大量测试、边界测试就让社区使用。一些在测试中就可以发现的 BUG,却在代码库中存在了一年之久,直到被阅读源码的社区开发者发现。这不由得让社区开始担心基金会的能力。

同时,社区对基金会 R&D 团队内部的工作进度一无所知,严重缺乏透明度。虽然很多都是基金会内部事务,但是关于路线图的提案都是由社区 NNS 集体表决,社区有权利知晓细节。

为此,我的建议是:

  • 如过里程碑未按时达成,允许社区通过 NNS 治理将工作转交社区团队接手
  • 扩大 working group 规模,邀请社区开发者,对开发进度进行监督

3.3. 长期忽视社区开发者的真实诉求

社区开发者普遍反映的需求、问题未得到回复。对社区提出的“去中心化边缘节点”、“多复制子网”、“DeFi 子网”等诉求,没有给出任何准确的路线图与时间表。甚至连 BUG 的提交,还得依靠我这个投资人来向 DFINITY 传话。

因为不得不等待官方对核心协议进行修改,很多 dapp 开发者只能停止工作。因此需求一直得不到满足,一些社区开发者已经放弃了 IC 网络,甚至不乏在 Supernove 黑客松上获奖的优秀开发者。

3.4. 基金会亲自做太多的应用层

曾经是IC社区最重要的开发者之一Psychedelic/Fleek,半年前引发过一次IC社区大讨论,其中他们一项核心观点是,DFINITY应该专注在底层协议而不是上层应用服务。我看到最近进展是,Psychedelic/Fleek已经离开了IC生态。

的确DFINITY 并不止于提供底层能力,而是总是试图在应用层面上引导开发者的思路,并自行研发了一些面向用户的产品投入市场。

这对生态开发者来说并不公平,这不仅挤压了社区开发者的生存空间,让其处于非品牌的竞争劣势中,还极大的扼杀了新应用、新范式出现的可能。

与之相对的是,IC 的文档并不齐全,基础设施与工具包严重缺乏。显然,这里的工作是严重不足的。

作为一个基础设施,应该保持其纯粹性,即允许开发者在其上探索任何类型的应用,而不应该歧视任何一种应用。多样性是一个生态系统繁荣的基础,也是 ETH 生态成功的秘诀。生态内的应用繁荣,才是真正的繁荣。没有哪个公链是靠自己做应用让生态繁荣的。

为此,我的建议是:

  • DFINITY 的 R&D 团队应该专注于基础和工具包的开发
  • 完善开发者文档
  • 停止在应用层面引导开发者,不再以 DFINITY 的名义推出新的 dapp
  • 禁止主动利用 NNS 为官方 DAPP 添加特权

一句话总结,我希望DFINITY向这位先生学习:Steve Balmer repeatedly says "Developers" at Windows Conference - YouTube

24 Likes

Final Words

Internet computer is a dream that we all look forward to and is gradually approaching. However, I’m deeply concerned with the NNS/SNS team, part of the DFINITY R&D team that should be leading us toward the dream instead of away from the dream with their slacking and irresponsibility.

It takes great courage for IC developers and entrepreneurs to invest their time and money in research and development products on a brand-new blockchain infrastructure. As we all know about the IC eco-system, there is not a mature business model to make a profit yet, every moment for them has become a huge pressure.

But the current response from DFINITY is a variety of blame shifting and clear responsibility, and this phenomenon has been happening more than once or twice. DFINITY operating like a company should have been effective and efficient.

I believe it is the common responsibility of not only the employees but also the enthusiasts, IC developers, and investors like me to step out and restore the reputation of DFINITY. If the real mistakes are not corrected in time, how can we build an efficient and dynamic community? How can we realize the dream of the internet computer if we do not correct the real mistakes before it’s too late?

From the heart of a person who insists on five years of dreaming of the deepest love of IC

最后的话

互联网计算机是一个我和大家都期待的梦想,而且现实也是逐渐朝着这个梦想一步步接近,可我观察到做为这个梦想主导方之一的的NNS/SNS团队各种的怠工与不负责任后,感到由衷的担忧。

公司化运营本应是高效的,创业者当初雄心勃勃的在一个全新生态敢于投入资金研发产品,是一种很大的勇气,ic的现状大家都知道,还没有一个成熟的盈利方式,每时每刻对于他们来说都成了一种巨大的压力,可目前反应出来的是各种的推诿与撇清责任,这个现像并不是一次两次,维护DFINITY声誉不光是企业员工的责任,也是像我这样的爱好者及IC生态从业者和投资者的责任,可如果面对各种真正的困难还不及时改正,又如何打造一支高效的,活力的,有梦想的精锐之师,我又如何实现世界计算机梦想。

来自一个坚持五年梦想最深爱IC之人的肺腑之言。

34 Likes

Thank you very much @lei for taking the time to write down your thoughts in so much detail, and I personally think there’s a lot of valuable feedback in there.

Some initial responses:

I expect more post mortems to be shared on those parts very soon.

Can you clarify this point? I am not aware that NNS nodes went offline during the SNS1 sale. (also minor detail, the NNS subnet is 40 nodes now).

I think this is not entirely accurate. For example for boundary nodes, this is being worked on, see Boundary Node Roadmap for the roadmap. The high replication subnet for eg defi is on our public roadmap and I expect it to be launched next week.

I will share this post more widely in dfinity so more people can comment on some of your other feedback.

14 Likes

Some ideas to add, what’s the timeline for allowing community run full nodes and rpc support for blocks data? It’s been talked since the beginning of the year

4 Likes

I do think this is the call from ICP hardcore fans. Dfinity should have a lessons learn from SNS launch.

6 Likes

First of all, I want to say I love Internet Computer very much since I think I see the blockchain future from the concept of Internet Computer.

But from the performance of SNS-1 sale, I really don’t understand what are the declared 270+ ppl doing everyday? Maybe should learn from Elon Musk that fired 80% of Twitter employees?

8 Likes

This is a great piece of work. I hope the Foundation get their highlighter pens out and allocate each section to the appropriate team for action.

Thank you!

9 Likes

They have a problem of following their tokenomics.

Half of the public sale token was supposed to be unlocked, but they locked both for alot of people. And they refused to unlock it.

2 Likes

Regarding the long post feedback from the host, I think it reflects the aspirations of the community in a more comprehensive way. The foundation should really listen to the voice of the community instead of closing itself in its own circle and building a car behind closed doors.

12 Likes

It’s the SNS subnets. During the sns1 sales, 5 of 34 nodes were offline and right after the sale, the sns subnet went offline completely. Here is the screenshot from the dashboard

5 Likes

During the SNS Sale Time, we saw:

5 Likes

You spend 1million on a website? Bro you got cheated man.

On a more serious note… SNS-1 is a test so mistakes made can be forgiven (for me at least). Give IC one last chance to make things right.

I see, so you think @lei meant the SNS subnet, not the NNS. Makes sense, thanks!

4 Likes

This is the voice of community. So, dom, stop talking about the rival blablabla…nobody cares about dfinity, not mention to taking dfinity as rival.

6 Likes

One EXAMPLE:

Something like this just make me more worried about what they focus on right now. If they want to help developers to build wallet apps, shouldn’t they pay more attention to build the infrastructures for wallet app rather than imagine how to develop different DApps? Here DOM even want to bind all wallet apps with Internet Identity. You call this crypto? I can’t disagree more.

8 Likes

You can already register yourself as node provider, see Node Provider Onboarding - Internet Computer Wiki. Making it easier to become a node provider is being worked on and you can follow the progress here The State and Direction of Decentralization & Nodes on the Internet Computer.

Wrt making blocks publicly available, there is a forum discussion Discussion: public subnets, but there isn’t clear agreement yet on this topic.

5 Likes

Dfinity真的需要好好自我反省,别再让全球的IC家人伤心了

5 Likes