Happy Wednesday! Welcome to our weekly debrief. This week we are excited to announce our upcoming Züs hackathon with NYTechAlliance – a great opportunity for our community. We will also be taking a look into distributed ledgers, debunking some of the common misconceptions surrounding this increasingly important element in data storage strategies. Plus, learn more about the latest blockchain updates. So, without further ado, let’s get started!
Mainnet Update:
Since our last update, our team has continued the load testing process (without chaos), and we are delighted to share that transaction execution and network liveness have performed well under normal testing conditions without encountering any issues.
However, we found a few bugs, when high-load testing blobbers and their effect on the network, which are now addressed and fixed. Our current focus lies on retesting the blobbers under a high load of operations, which we estimate will require several days, potentially concluding by the end of this week.
Once blobber testing is completed and issues are addressed, we will start our final phase of load testing with chaos, which, once completed, we can finally engage and start the Active Set again.
Züs Hackathon in Partnership with NYTechAlliance:
We are thrilled to announce an exciting upcoming event: the Züs Hackathon in collaboration with the New York Tech Alliance! This event is set to offer a thrilling week of innovation, bringing together creative minds from across the technology sector.
The hackathon will kick off on July 10th, 2023, and conclude on July 17th. This is your chance to transform applications or websites using the powerful Züs SDK. As a high-performance decentralized storage network, Züs provides the perfect playground for developers seeking to explore the possibilities of a decentralized Web3 infrastructure.
Register for the Züs Hackathon
Register for the event by following this link: Züs Hackathon Registration. We are proud to partner with the New York Tech Alliance, sharing the mission of encouraging innovation and tech development. Learn more about them here: NYTech Alliance.
Mark your calendars and join us on this exciting journey. Your passion for innovation and technology can bring about the next big breakthrough in decentralized technology. This is your call to gather your team, spread the word, and prepare for an unforgettable experience at the Züs Hackathon. We cannot wait to see what you will build!
In the News:
Debunking Misconceptions Around Distributed Ledgers
Explore the transformative potential of blockchain technology as Saswata Basu, CEO of Züs, debunks common misconceptions surrounding distributed ledgers. In this insightful article, Saswata sheds light on key highlights that will reshape your understanding of blockchain’s capabilities:
- Lack of understanding
- Unveiling the robust security of blockchain
- Addressing business uptime and scalability challenges
- Exploring the cost efficiency of decentralized storage
- Discussing the need for a regulatory framework
- Shedding light on adoption hurdles
Blockchain Updates:
Last week, the blockchain team focused on optimizing smart contracts. The new_allocation_request smart contract, which previously took about 10ms with the default benchmark test config, was a key area of improvement. The default tests only selected four blobbers to create an allocation, but more blobbers may be selected in real cases. Therefore, we tested the contract with nine blobbers per allocation, resulting in an increased time of 21ms, which was considered too slow.
After the optimization efforts, the team decreased the time to around 3.5ms for four blobbers per allocation and around 4.5ms for nine blobbers per allocation. It was discovered that the time could be further reduced by not encoding the entire allocation into JSON and returning all as transaction output. However, due to certain APIs relying on the current format, this change will be postponed to avoid disrupting system tests.
Several improvements were implemented during the optimization process, including the following main changes:
a) The team addressed the issue of excessive MPT (Merkle Patricia Trie) reading and writing, which resulted in a significant performance bottleneck. Before the optimization, the number of different data types for each blobber (represented by m) could be 2, indicating the data types of the blobber and stake pools. With 4 blobbers per allocation (n=4), this led to at least 16 MPT accesses (4 times blobber reading, 4 times blobber writing, 4 times stake pool reading, and 4 times stake pool writing). With 9 blobbers per allocation, the MPT accesses increased to 36 (9 times blobber reading, 9 times blobber writing, 9 times stake pool reading, and 9 times stake pool writing).
MPT access time reduced
After the optimization, the MPT access times were reduced to n+2, where n represents the number of blobbers per allocation. Additionally, the team optimized the concurrent reading of all blobbers from MPT. The stake pool read and write operations were fast since they only involved saving the mapped blobber staking information (e.g., TotalOffers, TotalStake, and Allocated). Each blobber was assigned a unique index when added to the stake pool list, allowing efficient stake information access using the index (e.g., stakePoolList[blobber_index]). The performance of the stake pool list depended on the total number of blobbers, but the tests showed that even with 30 or 100 blobbers, the differences were negligible due to the small space occupied by each blobber.
Allocation Saving Process
b) Another area that impacted the speed of new allocation requests was the allocation saving process. Each allocation involved saving n blobber allocation nodes and selecting a higher number of blobbers per allocation resulted in slower performance. To optimize this process, the team identified that not all information needed to be initialized when creating the allocation. Some information could be added later during allocation read/write commits. This insight allowed the team to optimize by moving part of the information to the allocation and leaving the rest empty to avoid saving to the MPT.
Closed PRs
In addition to these optimizations, the team successfully closed numerous pull requests (PRs) in the 0chain, blobber, and gosdk repositories. The main PRs included:
- PR#2501: Fixed challenge numbers for expired allocations.
- PR#2522: Exposed block.finalization.timeout to make the block finalization timeout configurable.
- PR#2533: Fixed fault tolerance conductor test cases.
- PR#2440: Fixed reward endpoints.
- PR#2534: Modified /getblobber endpoint to also return created_at.
- PR#987: Replaced allocationTx with allocationID in all blobber REST API calls.
- PR#983: Updated blobber image remotely for wasm.
- PR#972: Exposed multiupload in gosdk and wasm.
- PR#1042: Fixed panic.
- PR#1019: Moved the private key from JavaScript runtime variable to the zbox client within the go wasm SDK to prevent private key theft through XSS attacks or malicious browser extensions.
- PR#1044: Fixed multiupload to a folder other than root.
- PR#1037: Fixed download unit test.
- PR#1032: Fixed deadlock in transactionauth.
- PR#1123: Resolved issue where the create connection obj API was returning nil in every case, causing problems in wasm.
- PR#1126: Added ActualSize for directories.
- PR#1100: Fetched allocation directly from eventsdb.
- PR#1130: Added share check in file meta handler.
- PR#1133: Added build workflow for building a Docker image for conductor test.
- PR#1135: Added integration test in blobber.
These updates reflect the team’s dedication to optimizing smart contracts, resolving issues, and enhancing the overall performance and functionality of the system.
