Function X
Published in

Function X

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.

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.

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.

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.

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.

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.

--

--

A scalable, open, and decentralized ecosystem, enabling all to build entirely on and for the blockchain.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store