Happy February! This week we will take a look at Blimp and some dev updates. Stay tuned in the social channels, as demos will soon be finalized!
Last week our CEO, Saswata Basu, presented our Blimp App on Ecclesia #8. Make sure to watch it here to learn more. The following Cloud Cover AMA (Ecclesia #9) will be hosted in the coming week on Thursday, February 9th, at 9 am PST. Now let’s dive into this week’s update!
Blimp
Blimp is an enterprise-focused App that goes beyond S3 storage. The dApp is so flexible that it can support Apps and websites with the most demanding needs while being simple and effortless. It also provides higher security, privacy, performance, and data availability. Looking for convenient and affordable readings – Blimp features free readings!
Notably, the Blimp app enables users to customize how they want to store data. Users can select the allocated servers based on performance, geo-distribution, jurisdiction, and availability. The user can choose how they want to configure their uptime and availability and choose their service providers based on their needs.
In addition, the storage is completely transparent in the blockchain while remaining entirely private. With its transparency in the blockchain, users can generate privacy reports of data written, updated, deleted, and read for customer files – making it GDPR compliant.
Also, to make it simpler, Blimp has an AWS migration tool where users can migrate their data without code change. More platforms (Oracle, Azure, etc.) are being added to facilitate migration are being added in the future. Read more about Blimp in last week’s update here.
Storm of the Week
OpenAI just released a new tool to identify AI-generated texts
Have you ever wondered if what you are reading is AI generated? OpenAI just released a new tool to help people discern texts written by humans and AI. Even though the tool cannot reliably detect all texts that AI writes, it can help prevent academic dishonesty, misinformation campaigns, or those pretending to be humans. You can test out the tool here.
GoogleFI Data Breach
Another data breach! Google just notified its users from GoogleFI, a telecommunication service, that their data was breached. Even though Google claims that the breach had limited personal information, it is another alarm that our data is not safe in the hands of big tech, and the urgent need to move to Decentralized Storage solutions like Züs, which do not have a single point of failure for those to happen.
Blockchain Update:
Last week the team continued focusing the remaining issues toward the Mainnet launch. You can check the progress of the remaining issues here.
Chain Stuck issue
The team fixed a chain network stuck issue caused by a sharder stuck in an endless syncing state changes retry loop. The sharder mainly caused this needing the worker to handle the missing state changes synching. After setting up one worker, the issue was fixed.
Another issue was the debugging of another case that caused the chain network to be stuck. It was again the ‘state hash mismatch’ error that sharders and miners do not have the same state root after computing the same block. This bizarre behavior seems the same as before, which was thought to be mainly caused by the bug in the partition package. However, this time it was not caused by it. However, after performing tests, including unit tests and fuzz tests, to check if running the same transaction multiple times would lead to different states. All resulted from the same state that was always the same. So far, the team is investigating it, but there are a few possible places that could lead to inconsistent states have been detected.
Another cause of the problem is now being investigated. The state hash mismatch error most likely may have been caused by the genesis block re-entry issue. Which has not been fixed yet. Theoretically, re-entering the genesis block should not affect the current round state, as the state root is different. But the reason for this assumption is that it should not be possible that the current transaction could lead to an inconsistent state. Also, because miners who successfully computed the block would also fail to get a ‘state hash mismatch’ error after restarting. There might be an issue, which will first be fixed to prevent the error from happening again. Besides, the team can add more debug logs in the failed transaction SC. This ensures even if the issue is not fixed, they can see more logs for further debugging.
Other Fixes
The team updated blobber after a new allocation is created. This update fixed an issue on ‘zbox ls-blobbers` that the allocated capacity is not updated. Also, they cleaned up logs, normalized the logging type, and fixed blobber conductor tests. Also, the team updated the exempt list, added mint transactions to be exempt, removed health check transactions from the list, and cleared `add_miner,` `add_sharder,` and `sharder_keep` from the list.
In addition, the team introduced a new dev to do event database migration. Also, the team fixed testNodeStat and changed it to support miners and sharders with no stake pools. SQL + gorm returns an empty delegate pool object when the object has no stake pools. Error messages are improved to show the errors from event database API.
Also, the team detected and partially fixed a panic issue caused by concurrent accessing a map in a block without lock protection.
Gosdk
The dev team added demos: ‘Get Balance’and ‘GetAllocation, fixed the thumbnailPath issue on UploadFile, and added ‘GetFileStats’in win SDK. Moreover, they exposed SdkGetLookupHash in mobile SDK, exported ‘created_at’and úpdated_at’on ‘list-all,’ and fixed ‘InitSDK’ and ‘ GetFileStats’ in win SDK. Lastly, the team added the mobile SDK and ZCN package and improved Makefile for building mobile SDKs.
Read Züs’ most recent article:
Züs believes that their blockchain could be used to create a decentralized fan club where Taylor would have more control over her albums, tickets, and interactions with her fans, without the need for an outside entity. Read more in Blockchain (Taylor’s Version)
