0Chain Weekly Debrief — August 24, 2022

Tiago Souza
Zus Network

--

Happy Wednesday! This week, we were featured in an article by the Investors Business Daily, where our CEO Saswata Basu talked about the value of enterprise data security and privacy solutions.

Calling action fans: we are looking for high-resolution videos to showcase our decentralized streaming capabilities. If you have something, or would like to create a video, let us know by the end of next week! We would like to feature your video on our streaming demo! Note, that the content must be your own, or unrestricted. Message us on telegram if you are interested!

Last week our devs continued working with frontend supports, load test optimization, and bug fixes. Let’s dive into this week’s update!

Development Team

During load tests, the team detected slow block finalization process on block rewards update event storing, which would take about 1.3 seconds to finish working. This is unsatisfactory, as it would hinder the performance of the blockchain the team was able to locate the code that led to this slow finalization process. When distributing rewards to all clients that staked into miners that generated the block, the loadtest network would allow a max of 200 delegation clients. The problem was that, when the rewards were distributed, it generated 200 reward update events. Even though it is not a problem to save the 200 events into the database, it was being stored one by one, and each time it would query the client delegate pool from the database first, update reward, and then save to the database. This process was not optimal, but the team was able to fix by updating all events into one database action (ie: batch/bulk update). This change optmized the process to about 3 milliseconds with local benchmark test, and to about 50 milliseconds in loadtest.

Furthermore, the team detected and fixed a partition bug that could cause data to be lost. This bug happened when the partitions had more than one partition. When updating any item into one partition, and calling the Save() method, it would cause all other partitions to be removed from MPT. This bug didn’t happen before because our data could be stored into one partition, so it was always saved to the MPT, and no other partitions were removed.

In addition, the team refactored to use txn.ClientID as miner/sharde’s stake pool id. Previously, it was used to stake transaction hash as pool id. Each time tokens were staked to a miner or sharder, the client would occupy one stake pool position. However, each miner has limited positions for staking pools. For example, if a miner allows a max of 200 stake pools, then the miner is only allowed for max of 200 staking transactions, which is not intended by our protocol design. Nevertheless, after the refactoring, the total allowed stake pools is still limited, but each client can perform as many staking transactions as they want.

Furthermore, the team fixed the ‘previous block state is not computed’ bug. For some unknown reason, the block in chain.blocksi and round could be the same, making it possible that the round is computed, but not synced to chain.blocks. Then, in the next round, it would get the previous block from chain.blocks, and cause the not computed error.

All changes above can be found here. Beyond these changes above, the team also merged PRs as below:

They fixed logic to get requested data-points in response for frontend and merge into snapshot branch. Added new endpoints to return a list of blobber ids ordered by rank, and added round number to transaction event db, fixed a bug in evaluation of dominant response on MakeSCRestAPICall in gosdk. Also, the team exposed getWalletBalance API to wasm in gosdk, fixed a lock/unlock panic issue in InitAllocation function in gosdk, exposed preferred blobber ids on creation allocation in gosdk, modified consensus logic similar to delete operation, and fixed a lock issue on blobber. These changes are intended to ensure stability and performance upon launch.

Developer Resources

  • Interested in learning more about building on 0Chain or becoming a service provider? Check out our GitHub for access to repositories. Community ambassador Sculptex has created numerous tutorials to help get you started.
  • Try our BetaNet here! Users can create wallets and allocations, store files, send transactions, and share files.
  • Need help navigating creating wallets, allocations, or joining as a blobber? Check out our documentation page.
  • 0Chain’s API endpoints use simple and intuitive HTTP requests to interact with the blockchain in order to send/retrieve information to and from miners, sharders or blobbers in the active network.

About 0Chain

0Chain is a high-performance decentralized storage network designed to eliminate business threats such as censorship, privacy liability and data breaches. 0Chain helps entities achieve GDPR compliance, localization and tokenization, and monetizes private data sharing.

API| Docs | Telegram | Reddit | Twitter | Forum | GitHub

--

--