Züs Network Weekly Debrief — March 08, 2023
Cloud Cover / Apps demos update
Happy Wednesday! The Cloud Cover AMA (Ecclesia #11) has been postponed to the next Thursday, on March 16, at 9 am PST. Make sure to add questions to the Züs Network discord channel. We thank you for your patience for the delay. After enduring rigorous system tests, the apps are expected to be released in the next 2–3 weeks.
Mainnet Progress
The team made good progress in resolving issues and is now down to 87 from 112 since 12 new issues were added last week. We anticipate further reduction by next week’s AMA, with 30+ PRs waiting for system tests to pass before merging. We still expect to resolve all issues by the end of March.
Storm of the Week:
In AI, is bigger always better?
Today I came across a fascinating article from Nature titled “In AI, is bigger always better?” The article discusses the tradeoffs between model size and performance in AI. It highlights the negative environmental and economic impacts of using larger models, which require more computational power and energy to train and run. Additionally, larger models may not be accessible to individuals and communities with limited computing resources.
The article suggests that using smaller, more efficient models can help reduce the environmental impact of AI and improve accessibility. There are, however, challenges with efficiently storing and managing the large amounts of data generated by AI models. Decentralized storage could potentially address these scalability issues by distributing data storage and processing across a network, like the Züs Cloud Network.
How the Züs Network addresses issues
By utilizing decentralized storage, AI models can scale much cheaper and faster, while creating a secure, bulletproof database accessible to any community around the world. This would allow for smaller AI models to utilize the database for optimization and reach much higher potential. Decentralized storage also increases security, privacy, and reduces the risk of data loss and corruption, making AI more environmentally friendly and cost-effective without data constraints.
In summary, using decentralized storage like the Züs Network can help address the scalability challenges of AI by improving data accessibility, security, and reliability, while reducing costs and environmental impact. This is a promising solution for making AI more accessible and beneficial to a wider range of users and communities.
Blockchain Team Update:
Last week the team mainly focused on investigating the testnet stuck issue. After adjusting the event aggregate period settings, the blockchain team was finally able to reproduce the issue. Based on the logs that were previously added, miners notarized a block with txn that could not find the last partition normally. Therefore, the block’s state differed between miners and sharders, leading to the chain being stuck. During the investigation, the team found another place that could cause the stuck chain issue. The issue was that the team did not check the ‘node not found’ error when processing build-in txns when generating blocks. That means the generator could pack txns with a ‘node not found’ error into a block. If consensus miners did not have a synced state, they could notarize the block, while sharders not having the full state. Therefore, the sharders would have a different block state from miners, and could not finalize the block, hence the chain stuck. Despite the fix, the testnet still got stuck, so the blockchain team will continue the investigation while closing other issues related to the mainnet launch.
Apart from investigating the testnet stuck issue, the team detected and fixed a challenge-related issue, the uint64 overflow error. This error was mainly caused by bugs in both 0chain and blobber. Check for details on the fix on 0chain PR.
As for blobbers, the team will need to process the challenges individually in the created timestamp order. Although it tries to submit txns one by one, from the logs, the team could see challenges to verifying txns were submitted in the wrong order. The team will close this issue shortly this week. With the help of the DevOps team, the team fixed the txn fee system tests, which will be merged with all related PRs this week after final checking.
The following fixes are core PRs that the blockchain team merged or are ready to be merged.
The team closed an issue that carefully uses ‘RequestEntityFromAll’ to send requests to all sharders. In this PR, they will only send requests to part of the sharders concurrently and reach out to other nodes only when all the requests fail. Also, they optimized ‘payFees’ smart contract. It has been optimized from 11ms to 8ms from a previous PR for optimizing the miner/sharder health check — this PR optimized it to around 1.7ms.
In addition, they fixed an empty allocation issue when populating a challenge. Modified writeMarker as described here. It has added a few fields in writemarker and also uses fileMetaRoot to determine if all the blobbers are in sync with each other or not, fileMetaRoot can be used to repair files in an allocation.
Furthermore, the team fixed a security alert reported by code-scanning, though most of them were false positives.
Merged PRs
Also, multiple PRs in 0chain are ready to be merged but are blocked by system test failures. These will be merged shortly after resolving the test error this week. In the blobber repo, the following PRs were merged already merged:
- Added endpoint to list shared files.
- Recorded time taken to generate challenge proof, and also will record file size.
- Improved dockerfile to speed up the blobber/validator image build process.
- Implemented blobber end for the issue.
In gosdk repo, PRs merged are:
- Added AuthorizerHealthCheckPayload to zcncore
- Improved the logic in `misc.go` for improved rounding off when converting floats to ints
- Correct failure reason for the duplicate file upload
- Exposed getAllocationMinLock, getRemoteFileMap to wasm
- Added a few fields in writemarker and fileMetaRoot to determine if all the blobbers are in sync with each other. `fileMetaRoot` can be used to repair files in an allocation.
- Fixed dir actual size calculation
- Fixed dir create issue by checking name early.
- Exposed GetAllocation/GetFileMeta/CreateDir/Rename/Delete in win sdk
- Added mime_type , created_at, updated_at to getRemoteFileMap
- Added `file_id` to fileStats response
