Major progress was 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. Momentum has been made in areas including transaction nonce caching, 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. 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. This means 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 has 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. A 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), its 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.
Transaction Cost Implementation
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 time out. 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 the 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. They have 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 on to 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 the release of the updated tokenomics paper) by addressing a few issues uncovered in testing.
Züs is a high-performance storage platform that powers limitless applications. It’s a new way to earn passive income from storage.