0Chain Weekly Debrief — February 16, 2022
Major progress made this week on the development side as we have completed our CLI tests and progressed to API testing. In addition, the core blockchain team has been able to further finalize progress made in previous weeks in areas including transaction nonce, cost implementation, and Byzantine testing. With this recent success, the team has begun work to optimize smart contracts through code refactoring. Due to the extensive testing and subsequent positive outcomes of testing, the team’s confidence is rising in the blockchain’s core stability and performance under load. With a few final tasks to tackle, which continue to be under progress, the team is nearing opening up to external testing.
Development Team Updates
Some significant progress was made over the past week on both the storage and blockchain sides. Our systems tests have made great breakthroughs as we have finished our CLI tests, meaning that our entire customer-facing CLI for core storage has fully been tested. Despite this, we will continue to expand our coverage to add edge cases; however, we are now moving on to focus on direct API testing. As discussed in a recent twitter group, this testing allows the team to focus on solving larger bugs without introducing more. In that area the team have pivoted to bug fixes for smaller issues as the major bugs have now been fixed.
As noted in previous weeks’ updates, the team continues its work on transaction nonce features. They were able to identify some test failures and fixed a couple bugs, while also adding nonce caching mechanisms to the goSDK lib. The team identified the root causes of errors and is currently discussing potential solutions internally. Nonce is a more reliable way to order transactions. Similar to nonce in ethereum, it is a sequence for every user to create happens-before relations. For example, all users start with nonce=0. The first transaction will have nonce=1, the second nonce=2, and so on. If a transaction is wrong (can’t be executed), it’s nonce is not used and can be used again; meanwhile, the nonce of a successfully executed transaction cannot be reused in the future. The team currently uses creation time to prevent transactions from resending while time is part of the transaction hash calculation. Transaction time is not a good solution to order transactions since time is not absolute in general and malicious miners can easily manipulate this.
The blockchain team also continues its work on transaction cost implementation. This process is important when there is a large group of transactions that are set to take place. Typically, most transactions are easy to calculate and are fast; however, when a group of transactions are heavy and take a lot of resources, it is critical that the transactions chosen for a block are done so wisely. If a block is packed with only expensive transactions, it won’t be verified in time and could cause the network to timeout. So, the team is optimizing this progress to ensure that the network remains stable even as demand for transactions and transaction size increases.
Over the past week, the blockchain team conducted testing on our high-performance network which was created specifically for stress testing the blockchain with high transaction load, including thousands (1–5K) of concurrent transactions. The initial results looked very promising and the team will dive deeper this week to analyze results in full. In addition to that testing, the team continued its work on Byzantine testing. Due to the major progress and consistently positive outcomes, the team is confident in the code and has included it in CI (continuous integration, meaning that every time a dev commits to a repo, their code is built and tested automatically to ensure it works).
With the recent successful blockchain testing, the team has moved onto optimizing and refactoring smart contracts. This week, the team put emphasis on refactoring the data structure of the blobbers. Instead of storing all data in a single list, they optimized it to store each blobber on MPT with its own path, and have separate partitions to store the blobbers list and blobber rewards list. In this way, we can a) avoid encoding/decoding the full blobbers list for each updating b) make it easier to extend the blobber functions. In addition to the refactoring described above, the team has put emphasis on sorting out blobber block rewards (which will be discussed more thoroughly alongside release of the updated tokenomics paper) by addressing a few issues uncovered in testing.
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.
