Cloud Cover AMA:
Greetings, Züs community! We hope you are all doing well. We would like to remind you about our upcoming Cloud Cover AMA (Ecclesia #17), which is scheduled for tomorrow, Thursday, June 15th, at 9 AM PST. During this AMA, Saswata will provide the latest updates on Züs Mainnet, the Active Set, and the Apps. It will be an excellent opportunity to stay informed about our progress and get a glimpse of what is coming next. We encourage you to contribute your questions to our Discord channel or send them to me directly via Telegram. Looking forward to your active participation! Keep reading for more details on our upcoming hackathon filled with innovation and problem-solving and discover our latest updates to the blockchain.
We are excited to announce that we have partnered with Web3 Berlin to host a thrilling Hackathon starting on June 10th at 2 PM PST until 2PM PST on June 17th.
To ensure a smooth and successful participation in the hackathon, we have prepared some essential resources that you will need to get started:
1. Hackathon Registration
2. Züs SDK
Before diving in, make sure to familiarize yourself with our SDK. Visit our GitHub repository here and get a grasp of how it works.
3. Sample Apps
Learn by example! Explore our sample apps for better understanding and inspiration. Check them out here:
4. GitHub Repositories
We have made the source code of our sample apps on GitHub. This can guide you in integrating the Züs SDK into your projects. Check out the links below:
Prepare yourself for an unforgettable experience of innovation and development. We cannot wait to see the remarkable projects our community builds. Let’s build the future together!
Last week, the team actively focused on closing backend issues, resulting in the closure of 22 PRs in 0chain, 12 PRs in gosdk, and 9 PRs in blobber. Additionally, the team made significant efforts and successfully passed the load tests phase 5. Check for more details below:
The team optimized the storage rest endpoint /get_blocks, but found limited room for more improvements, deciding to leave it as it is for now.
Max token supply validation
Also, the team raised an issue to add max token supply validation on block verification. They recognized the importance of checking the transaction value upon receipt and during block verification to prevent malicious miners from accepting transactions with overflowed values and including them in a block for notarization. As observed in previous instances, failing to validate the value during block verification would result in panic.
payFees smart contract
In addition, the team conducted a benchmark to optimize transactions by primarily targeting the payFees smart contract. They actively optimized the execution time of the payFees smart contract from 8ms to around 1.6ms by passing reward sharder IDs from the smart contract input. However, they acknowledged the potential vulnerability of allowing malicious attackers to choose to conspire sharders for rewards selectively. Consequently, the team abandoned this optimization, resulting in a slightly increased transaction execution time of around 2.5ms. Despite this setback, the team implemented several optimizations, including eliminating duplicate access to items in the Merkle Patricia Trie (MPT). Previously, the team retrieved all sharders from the MPT to obtain the IDs, selected live nodes from them, and retrieved them from the MPT again, leading to duplicate item acquisition. In response, they optimized the process by retrieving only the sharder IDs from the MPT, excluding the killed ones, selecting a specific number of IDs, and obtaining the sharder nodes for those selected IDs from the MPT. This optimization ensured that only the selected sharders were read from the MPT once, avoiding unnecessary access.
The team also actively updated the benchmark test code to allow running individual cases, enabling targeted benchmarking of the minersc.payFees smart contract. This eliminated the need to run all smart contracts in the minersc package and wait for their completion to analyze the results. Furthermore, the team proactively refactored the code to enable running the benchmark with a profile, facilitating faster smart contract optimization in the future.
PRs successfully closed
In addition to the smart contract optimizations, the team successfully closed the following core PRs:
- PR #2492 – Used consistent time in creating benchmark MPT.
- PR #2493 – Fixed transaction errors.
- PR #2472 – Fixed challenge errors related to allocation expiry and partition.
- PR #2490 – Allowed empty allocation root.
- PR #2497 – Marked all remaining challenges as passed for expired allocation.
- PR #2491 – Cleaned up past transactions.
- PR #2488 – Updated blobber, removed double stake pool access.
- PR #2509 – Fixed errors in costs config.
- PR #2507 – Fixed settings obtained from config rather than MPT.
- PR #2506 – Fixed authorizer conductor test.
- PR #2513 – Fixed transaction management.
- PR #2518 – Added context to event db.
- PR #2495 – Added paginated endpoint to get allocations related to a specific blobber.
- PR #2508 – Fixed counter merge operator.
- PR #1021 – Fixed panic in gosdk.
- PR #1023 – Returned last response.
- PR #1018 – Fixed nested move.
- PR #1017 – Added proper error handling.
- PR #1031 – Exposed multiple operation in winsdk.
- PR #1006 – Fixed MultiOp conflicts.
- PR #1014 – Fixed download status callback and writes.
- PR #1036 – Fixed zboxDownloadFromAuthTicketByBlocks.
- PR #1120 – Added redeem readmarker endpoint.
AMA | Hackathon | Blockchain updates
We are so excited for what the future holds, and to demonstrate our energy and dedication, we cannot wait to share our progress with you. With updates and new features that we have added, our AMA tomorrow will be a great opportunity to share with you what our team has been working on over the last couple of weeks. The hackathon this month also provides an opportunity for you to get involved as well! We invite everyone to tune in tomorrow and take part in our AMA. Do not forget to set a reminder!