Function X: March Hash Out
This session of Hash Out will talk more about hubs and zones. We will also discuss further topics the community raised in social media for Hash Out February.
Function X’s Hub and Zone
Let’s dive in more on Hub and Zone which we talked about in January’s Hash Out.
To recap, “Hub” is regarded as the parent chain, which is what we commonly call the Function X public chain. It is the backbone of communication between different blockchains in which call “Zone”.
A zone is the blockchain that has a specific functionality, such as a “payment” chain specifically catered for transactions of XPOS Point-of-Sales network. In this “payment” chain you will see the transactions of each XPOS device, from people buying cryptocurrency or spending cryptocurrency on the XPOS.
In a company analogy, “Hub” is used to coordinate and allocate resources, aka “management” while “Zone” is used for operations aka “department”.
Different zones can have different consensus rules. For example in the “logistics” zone, we might prioritize speed (liveness) over security as there is no double spend problem in data storage, while in the “finance” zone, we want to prioritize security over speed, as it is money we are talking about.
Who will set the consensus rules for zones?
The respective stakeholders in the zones, likely people who launches zone. For example if you set up a zone called Medical Zone and its usage is to issue certifications or medical records in a group of the medical institutions, then you as this zone owner will write the consensus, alongside your other stakeholders. You and the stakeholders are likely the ones that will setup validators in the zones too.
Example 1: Inter-zone communications: using services provided by other zone.
If zones are “different departments” in a company, how do zones talk to each other? Inter-zone communications are communications that happen between two or more zones.
Let’s take the service of “storage” zone for example. We can setup this zone with a decentralized storage powered by IPFS [*]. When other zones such as the “payments” wants to store XPOS transaction data in a cloud we could use the IPFS services offered in the “storage” zone.
During inter-zone communications, we will need to go through the hub By now it should be clear that the full nodes are sitting at the hub level, and service nodes sitting on the zone level. February Hash Out has more on full nodes and service nodes.
Example 2: Inter-zone communications: validating data between zones
This function can also be extended to sending digital assets between zones. For example. Bobby is in the “payment” department, as he is a stakeholder in that department. Alice is in the “storage” department as she is a stakeholder in the department. Now Bobby wants to send a Bitcoin to Alice. When Bobby sends the Bitcoin, it will first be verified by the “payment” department zone, and move to Hub, and finally to the “storage” department zone where Alice sits.
There are various other instances beyond storage and sending crypto assets that allow coordination between zones. Other instances can include voting, text messages, voice calls etc. Sometimes the concept of inter-zone communications are loosely termed as Inter Blockchain Communication (IBC). IBC is use to denote the idea of communication between chains rather than a set of fixed protocol.
Hash Out February Discussions
In February Hash Out, we have discussed about the requirement of becoming a full node, either using a fixed number, say, 100,000 FX tokens, or a fixed percentage to stake. Some have proposed 0.026% of total supply. At current supply 0.026% is 98,430 FX tokens, which is shy of 100,000 FX tokens.
The benefit of using percentage is that it reflects the true ratio to supply, the disadvantage is that a validator will constantly need to update the tokens staked in order to qualify for itself being a validator. For example, 0.0026% of total supply is 9,843 tokens today, but could mean more tokens in the future. The benefit of using fixed number is much easier for validators to know what they are expecting, as supported in Reddit discussion of February’s Hash Out on the pros and cons.
In February Hash Out Recap, we also discussed about the importance of non-malicious nodes, and why a penalty is required if there are malicious nodes gaming the system. One possibility of increasing the stability during the early stages or “pre-launch stage”. They will be invited to run to the software, and become testers before the software is released for public. To make participation attractive, there will be an incentive scheme [**]
[*] We will talk more about IPFS in the future HashOuts. It was previously mentioned in our Function X concept paper too.
[**] The scheme will partly come from what it has left from the token staking that allows NPXS/NPXSXEM holders to receive f(x).
Article contributions from Danny Lim and Pitt Huang. Suggestions by Dr. Yos Ginting, David Ben Kay and Indra Winarta.
