Happy Wednesday! In this post we will discuss the status of the Active Set, blockchain updates and how to ensure that your most sensitive information remains secure. The future of business data security is here, and it is called encrypted file sharing. Let’s get started.
Active Set:
We are making great progress with The Active Set onboarding! All sharders have finished step 1. Out of 104 miners, only about 18 are left to complete their part. The community is buzzing with excitement as we edge closer to the testing phase, paving the way for our Mainnet release. Keep an eye out for more updates coming soon. Stay tuned!
Encrypted File Sharing: The Future of Business Data Security
In today’s digital world, businesses face a big challenge: how to share large amounts of data easily and keep it safe at the same time. The best way to do this? Encrypted file sharing. This method turns sensitive information into a code that cannot be read, and it can only be unlocked with a special key. It is the right mix of making data available and keeping it secure.
The Züs Network is leading the way in this area. We are more than just another platform; we are setting new standards in data protection. By combining top-level encryption with easy-to-use interfaces, Züs gives businesses a tool that is both efficient and super secure.
But this is just the beginning. At Züs, we are dedicated to changing the way businesses think about data security. Find out how Züs is shaping the future of secure data sharing in our blog post.
Blockchain Updates:
Last week, the blockchain team’s primary focus was on resolving the earnings APIs in 0box and examining the NFT royalty fees on the 0chain end. Several issues were identified within the earnings APIs, causing the subgraph creation to fail, subsequently leading to API call failures.
The first discrepancy was in the naming convention for the subgraph. Initially, nft_contract_address/token_Id was the chosen naming format. However, the inclusion of the / between the two variables rendered the subgraph service endpoint invalid, especially given the standard URI structure of https://graphnode.dev.zus.network/subgraphs/name/${subgraphname}/graphql?. Using the previous naming convention would result in an impractical URL structure resembling https://graphnode.dev.zus.network/subgraphs/name/contract-address/token-id/graphql? .
Contract Address String
A subsequent attempt to rectify the issue by simply removing the / did not yield success either. On further analysis, it became apparent that using the contract address string, which starts with 0x, as a part of the name would lead to subgraph creation failure. The solution emerged in the form of hashing: MD5($nft_contract_address-$tokenId) resolved the persistent issue of the invalid subgraph name.
After addressing the subgraph name, the team faced challenges with the manifest. Although the subgraph creation API indicated a successful operation, the balance acquisition API was still malfunctioning. A deeper probe revealed that the team had not been checking the results from the subgraph creation API.
The previously checked error would always return as nil, as long as the remote graph node remained active. The genuine error lay within the response entity. By incorporating error-checking mechanisms, the team could discern the actual issue and streamline the debugging process. Further examination highlighted parsing errors in the provided manifest file.
The primary concerns were:
- A missing parameter that led to subsequent parameters being misplaced, resulting in a corrupted manifest file.
- A field value error that required IPFS links to be encapsulated within.
- The API was being called with the incorrect contract address. Instead of the created NFT contract address, the Chalk app was mistakenly using the factory contract address.
With these issues addressed, the subgraph was successfully created and began its indexing process. However, the data querying APIs proved challenging due to the need to retrieve the latest Ethereum block number with each API call. Given parameters such as from, to, and data-points, with the former two indicating block numbers for data querying and the latter suggesting the volume of data return, the team made adjustments.
Now, if all these parameters are set to 0, all records are returned. Further adjustments will be made as necessary, with priority given to establishing the earnings UI.
In addition, several PRs across 0chain, gosdk, and blobber repositories were closed and merged.
Here are the details:
- PR #2690: Logs of open challenges were cleaned.
- PR #2691: Build breaks were fixed.
- PR #2645: SQL query was corrected.
- PR #2661: The addition of id and type in user stake pool stat was made.
- PR #2687: Blobber terms allocation issues were rectified.
- PR #2676: Chimney blobber rewards endpoints were fixed.
- PR #2665: Blobber query was enhanced.
- PR #2664: Differentiation between expiry and cancellation was clarified.
- PR #2695: Pass rate issues were addressed.
- PR #2696: Endpoints for delegate rewards retrieval were added.
- PR #2700: ThirdPartyExtendable was set to true by default.
- PR #2698: Count discrepancies in authorizers were resolved after deletion.
- PR #2702: Issues on the diagnostics page were fixed.
- PR #1157 in gosdk: First responsive blobber is used as mutex when locking.
- PR #1147 in gosdk: Issues with the resume upload progress bar were resolved.
- PR #1165 in gosdk: A wasm function for createfreestorage was introduced.
- PR #1169 in gosdk: Upload issues were resolved.
- PR #1205 in blobber: Validator diagnostic page was fixed.
- PR #1203 in blobber: ‘Get ref’ issues were addressed.
- PR #1195 in blobber: Conductor tests for blobber and validator were added.
- PR #1202 in blobber: Indexes were updated.
Encrypted File Sharing / Blockchain Updates/ Active Set Testing
As the Active Set continues to move forward with their testing stage, there is reason for the team to be hopeful about the upcoming Mainnet release. With our tech team’s experience and dedication, we hope to address any last-minute issues effectively and promptly. Also, the security of encrypted file sharing will protect businesses from potential harm and foster healthy collaboration across teams. Thank you for following along on this journey with us!
