Happy Wednesday everyone! Hope you are doing well. Last week the team continued working on loadtest optimizations and fixing several newly detected bugs. The blockchain team supported the frontend team for both gosdk, wasm APIs, and blobbers bugs. You can now check the unit and system tests for the latest fixes, and additional changes on the 0Chain repo.
In the following weeks, the blockchain team will be working on fixing a DDOS issue on uploading files of blobbers, and a 0Chain network finality variation issue. In addition, some focus is being allocated to block synchronization. Only after these two main issues are fixed, it will be possible to estimate a pre-mainnet date.
Blockchain Team
The team detected and fixed a bug in sharders block synchronization process. This happened when the current round had multiple blocks to be processed. When computing the state of a block, its previous block state was not ready, causing the next round to fail. Furthermore, they fixed bugs in the allocation challenges stats. The TotalChallenges was updated incorrectly, leading to incorrect block rewards being distributed.
In addition, they investigated why higher TPS on loadtest run would lead to lower total challenges being generated and passed. The core issue was that the loadtest only collected a subset of the allocation’s challenges. However, with higher the TPS, and the more test targets, more allocations would be created in total. This lowered the times of each allocation to be challenged, hence, leading to a lower number of challenges being collected. Because of that, the team altered the loadtest to collect all of the allocation stats so that the total number of challenges could be seen correctly. Moreover, the team detected and fixed new bugs in allocation stats in the storage smart contract.
Finality Variation Issue
Furthermore, the team investigated the finality variation issue. When performing loadtests, the finality time has been increasing significantly when TPS increases. This is mainly caused by the slow events process on sharders with block synchronization. Transaction costs are used to determine how many transactions are allowed in a single block so that the block compute time does not exceed specific time ranges. However, there is no mechanism in place for such events, so each transaction can only emit a limited amount of events, which significantly slows the whole block finalization process.
Upcoming
In the following weeks, the team will address this issue into two different steps. First, they will focus on optimizing the event processing code to perform batch/bulk updates instead of inserting or updating one by one for a bunch of items in a block. Second, they will address the transaction costs to measure the events while limiting the number of events a single transaction can have. The first step has already been partially done against the users table, which will be aggregated into all of the new and existing user update events in a block by only performing two batch inserts/update SQL actions, instead of several SQL actions. Here you can check more details of the commit.
Lastly, the team fixed createdir does not work bug in gosdk, fixed indefinitely request blobber for lock exists error, exposed ransferAllocation and freezeAllocation on wasm. Supported new playlist APIs on blobber, and finally, added a custom nonce monitor that helps yielding higher success rate on blobber txns, which is executed from one wallet through gosdk.
About Züs
Züs is a high-performance storage platform that powers limitless applications. It’s a new way to earn passive income from storage.
