Here is this spin-off post. The last post “Is my 5-year dream of ICP and DFINITY shattered? Is there still a future in the next 20 years! (SNS-1 Decentralization Sale questions)” mentioned that the DFINITY Foundation ignores the claims of community developers, and here are my stats from the community.
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。
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.
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
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.
Trie has an error in filter, Trie.get()/Trie.find() cannot return data.
Post link： A Trie.filter() Bug
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.
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.
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.
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
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)
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.
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.