Recap
Following last week’s exciting update of our initiative with Huawei Cloud x Morpheus Labs via their Launch Pad, this week we provide more technical insight into team progress and touch on our View Change protocol. We hope you enjoy it!
Sculptex’s Use Case of The Week: Staking and View Change Protocol
This week I’m gonna dig into our SP staking plus View Change Protocol. (Note: I am using the term ‘miner’ but might be described as a validator etc. depending on the particular platform).
With a PoW BlockChain, miners compete with brute force hashing power to hash each Block. The set of competing miners naturally fluctuates with the rewards value, miners often jumping their hashing power to another BlockChain if it sees a sudden increase.
For PoS BlockChains, a more static set of miners is required with stakeholders effectively ‘betting on their own horse’ to ensure Service Provision. But because places are limited, potential new miners often aren’t able to get a chance to participate. dPoS has the ability to help circumvent this potential stagnant set of wealthy miners by allowing others to delegate to the competition for the limited miner places.
Through Züs’ protocols, we have the particular consideration that the miners perform a useful function — that is performing challenges to help ensure the integrity of the Blobber storage. With all this considered, we not only need a way to allow the Active Set of Miners to get shuffled, we also need to ensure miners are performant and able to scale the set if required.
The squared-staking is an elegant way of giving competing miners a chance of participation but eliminating Sybil attacks. Delegation for poor performing miners will also naturally be dropped and switched to performant or new potential miners promising a more stable reward for delegation. But how to shuffle the active miners while taking into account all the above? This is where View Change comes into play.
Every so often (maybe every few days), performing miners and potential miners are ‘randomly’ selected with a chance of being selected being proportional to their stake squared. In practice this will likely result in mostly the same miners as the previous set (maybe 5% change), but will also exclude dysfunctional miners so that the Active Set is always heavily staked and highly functional.
Initial Onboarding
The initial onboarding of the Active Set will ultimately use the same functionality of adding miners albeit the instead of competing with stake, the Fuji set will be pre-approved.In the event that the storage capacity becomes large or the BlockChain (sharder) demands are under stress, more miners could be added. This will also utilize the same View Change process.
So what is the complication getting the Active Set onboarded? Well as per Saswatas recent post, there is a persistent BlockChain bug that manifests itself during the View Change Process.
So why can’t we launch without View Change enabled? That would be a bit like packing soaking wet clothes after camping! You know you will have to unpack it sometime, and the longer you leave it the more likely it will be full of mold. The comparison being that the task will be much more difficult to sort the longer it is left behind
Besides that, there is still the onboarding process itself. This involves a complex handshake process between each miner with each other and the VC smart contract itself. These handshakes (known as ‘Shares or signs’) facilitate a trustless secure method for miner identity verification.
For a public network, these handshakes need to be created securely since each operational wallet is kept private. But this is a big part of what View Change Protocol does! So removing View Change would create a whole new problem of how to achieve this. Trying to partially implement just this feature might not be easy either and would certainly draw developer resources away from resolving the ‘bug’.
So by now you will have gathered that I believe the best course of action is to wait for the ‘VC bug’ to get resolved. Last week, I noticed promising improvements relating to ‘mutex’ issues from the developers. The size of the active set in testing has also been able to be increased.
It’s still undetermined how much longer this will take, but I believe that once we launch successfully, View Change will one day be regarded as one of our major achievements admired (and perhaps imitated) by other platforms!
(Note: the above is my simplified understanding of View Change, please excuse any technical inaccuracies in my attempt to simplify a very complex topic!)
Non-Dev Updates
The biggest developments this week are related to app development. We have signed on a UI/UX development team that has done work for Apple, Uber, Tinder, and more. They will begin their work to redesign the 0Wallet and 0Box apps such that they flow in a more intuitive way and follow a template that is consistent with the rebrand.
This is important because most people, on average, will interact with the Züs network on their mobile devices. Providing an in-app user experience that not only eliminates pain points but also exceeds expectations will drastically improve our ability to impress new users and retain existing users.
Development Team Updates
What is View Change Protocol, How is it being addressed
As has been discussed in other media previously, the full View Change protocol is planned for phase 2 (Kilimanjaro), however, a subset of the protocol that facilitates the onboarding of nodes to the network is required by the initial active set to kick off Fuji.
During test runs of VC onboarding at scale, it was discovered that the blockchain would move very slowly and/or stall after ~x number of nodes were running. Eventually, no new nodes could join and older nodes were kicked from the network. This is the high-level issue commonly referred to as the “View Change bug” which is delaying mainnet launch.
At a lower level, the “view change bug” moniker is inaccurate. The problem consists of many smaller inter-related issues (performance issues or bugs), each negatively affecting chain behavior, and requiring a large amount of effort and skill to find, debug, fix and test. In many cases, the above process leads to another issue being discovered elsewhere. Newly discovered issues also take time to resolve, and so the cycle continues.
Fixes
These fixes manifest as “performance improvements and bug fixes” on the weekly update, which we know is not very interesting at first glance, but every one of these fixes contributes directly to a more scalable, stable, and resilient blockchain. These are not buzzwords. Enterprises (our main target market) require this as a standard. Scalability ensures that the chain keeps moving quickly as the load (or nodes) increase. Stability ensures that each operation (or node) works as intended without crashing. Resiliency ensures that when something does go wrong, the operation (or node) recovers quickly without negatively affecting points 1 or 2.
TL;DR: When “TPS/CPU load/optimization/retry/bug” fixes are mentioned in the blockchain section, be sure that this is directly related to fixing the “view change bug”.
This delay has been far from ideal and we’ve been asking ourselves “how can we prevent more issues from being introduced in the future?”, hence the “test additions/process improvements” mentioned in almost every weekly update, the result of some of this is now public in the new Züs System Tests Repo which we are adding to every day.
We hope this clears up any lack of clarity and helps to give context to any future weekly updates.
0Box
Over the past week, the 0Box team has fixed up a few minor bugs on 0Box Android and 0Box IOS. UI regression tests are nearly completed across both platforms. Updates have also been made to our blobber server to improve a few areas including file renaming, and folder changes while also scaling our system testing.
0Wallet
No significant code updates over the past week. However, the 0Wallet team has been preparing for UI regression tests, planning to perform them in the next sprint
Blockchain
This past week, further progress has been made on our blockchain network resulting in the successful scaling of our internal testing. This testing was performed under conditions that limited miner CPU usage. This is important because previously, at times, certain processes would cause miners’ CPU usage to rapidly elevate which can slow down the miner or impact hardware. Improving ticket usage and efficiency has improved miner speeds. This has resulted in the chain being able to move more quickly even with CPU restrictions. The team will turn back to review the code this week, implement further updates and continue with testing. As progress continues, we will scale the testing cluster.
Blobber
Powered with Docker
Reduced Complexity
SSL Secured
Integrated Infrastructure Layer
About Züs
Züs is a high-performance storage platform that powers limitless applications. It’s a new way to earn passive income from storage.
