Split-Key Technology | Züs Weekly Debrief May 24, 2023
Happy Wednesday! This blog post will explore how Züs’ split-key technology works and why it is an optimal solution for protecting their cryptocurrency investments. Also, learn about the newest updates to the Züs blockchain, Mainnet, and apps.
Mainnet and Apps update:
We are working on the load test of our latest merges and stabilizing the networks, so that the community can use the apps. We uncovered some bugs during the merge and expect them to be completed by the end of the month.
Our next step is to pass the load test, and then continue with chaos and DDOS tests, and test the apps during this process to make sure they still perform well and there are no hidden bugs.
At this point, we will start the active set and repeat the tests and perhaps tweak some configuration for mainnet release, and then begin the countdown. The mobile apps are in the process of getting approval from the store, while the desktop apps may take 2 weeks to be on their respective stores. Chalk is expected by the end of the month.
Storm of the Week:
Welcome back to our series, “Storm of the Week!” Today, we are discussing the recent discussion regarding Ledger Wallet announcing a key recovery service. This announcement received significant criticism from the crypto community that was against storing recovery phrases on centralized storage systems.
The crypto community has had a lot to say about this. Some users see it as a handy backup if they ever need help finding their devices or falling prey to theft. But others aren’t so sure. They’re making a strong case for looking after your own keys and exploring more decentralized options. These critics are worried about a higher risk of hacks with this kind of system. Responding to these concerns, Ledger decided to put the launch on hold, promising to rethink their strategy.
Züs Split-Key Technology
However, this controversy has shed light on the Züs Split-Key technology. By splitting the private key into multiple shares and distributing them across various devices or locations, it offers a robust, decentralized approach to managing crypto wallet recovery. This system enhances security, minimizes single points of failure, and provides flexible recovery options, thus reducing risks associated with centralized services like Ledger’s proposed recovery phrase service.
The Split-Key technology protects against physical threats and losing your recovery seed completely. With flexible recovery options, if a user loses one of the shares or faces a device failure, they can still access their wallet by combining the remaining shares. This eliminates the dependency on a single recovery seed and provides more options for wallet recovery, giving users a greater sense of security for their funds.
As Ledger rethinks their recovery service, they are aiming for a sweet spot between convenience and security. But it seems the future might lean more towards decentralized solutions like our Split-Key technology. Anticipating this trend, we have integrated this feature into our own Bolt wallet, offering a secure and easy way to manage your ZCN tokens.
Blockchain Updates:
Last week, the team focused on testing a potential future transactions Byzantine case and conducting tests to determine if removing future transactions would speed up the transaction processing. The transaction’s nonce gap could prevent normal transactions from being executed.
Consider the scenario where a large number of future transactions stack up in the transaction pool; in such cases, miners cannot obtain valid transactions within the timeout period. Moreover, since these valid transactions have lower transaction scores, the transaction iteration would break due to the timeout before reaching them. Based on the conducted tests, it was observed that removing future transactions could slightly accelerate the load tests, but it would fail when sending all transactions concurrently from a single wallet. To address this, the team will impose limits on future transactions, allowing only a limited number of future nonces while removing past transactions immediately instead of waiting for transaction timeout.
In the meantime, an investigation was carried out on the panic logs that occurred during conductor tests. It was discovered that the shutdown process was not handled properly, resulting in database access after it had already been closed. Additionally, the permission issue on redis state saving was resolved. Further details can be found in the PR.
Another issue found was that adding challenge events could not be processed due to the duplication of the primary key. This was not the only case where the primary key duplication issue could arise. Theoretically, the challenge should only be added to the database once when finalizing the block, and finalizing a block should occur only once. However, in certain situations, the event could be successfully saved to the database before the block is finalized. If, for any reason, the block fails to be finalized (e.g., panic during block.Transactions saving), then the next time the sharder gets up, it will attempt to finalize the block again, resulting in a duplicate primary key issue. The team is currently addressing this problem by making the event database process rollback-able in case the block finalizing fails or a panic occurs.
Furthermore, several new issues were detected and will be resolved in the upcoming weeks before the mainnet launch:
- Sharders panic due to negative transaction value.
- Negative write pool value saved in event db.
PRs
In addition to the aforementioned tests and issues, the team closed 16 PRs in 0chain, 11 PRs in blobber, and 11 PRs in gosdk. Some of the notable PRs include:
- Fixed duplicate round=0 snapshot creation on sharders restarting ().
- Addressed the issue where mandatory transactions are stuck to a round .
- Updated miners/sharders handler endpoints to remove unnecessary handlers and putting some handlers in development mode only.
- Fixed challenge numbers to prevent negative open challenges from being saved to the event db.
- Added timestamp checking for rollback WriteMarker.
- Changed zcn config currency amounts by multiplying them by 100000000 to ensure consistency with other smart contracts.
- Removed unstake functions.
- Resolved a panic caused by a random blobber allocation out-of-range.
- Fixed nested move and copy in blobber.
- Fixed challenge and allocation numbers.
- Implemented a two-phase commit.
- Decoupled readmarker handling from the downloading process.
- Fixed GetFileMetaFromAuthTicket and DownloadFromAuthTicket in gosdk.
- Fixed lockBlobber sleep, reducing sleep time if the blobber is already locked and trying indefinitely if the lock status is pending.
- Increased error threshold when fetching the writemarkers from the blobber.
- Exposed revoke share to mobile SDK.
- Optimized the download process.
- Fixed listDir size/numblocks calculation.
Züs’ split-key technology is a major breakthrough in the crypto security field providing users with unprecedented levels of protection and confidence when investing in digital assets. It solves many criticisms people have with securing their investments. The development team behind this project has really gone above and beyond to create something unparalleled and ahead of its times. For those still following this fast-paced industry, stay tuned as we approach Mainnet!
