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
iclighthouseWe 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.
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.
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 路由到正常工作的节点。
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
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），需要添加支持来方便开发者自行实现序列化优化。
或者可以给出最佳的序列化、反序列化解决方案 ，序列化之后的大小和序列化/反序列化效率两者都要兼顾。
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。
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变成无人之地。