APEX Behind the Scenes #2 — Guest Post by CTO Richard Wang — Part 2
Hello guys, it’s Richard again. It’s been quite a busy week, much like what I described in my last post, but I did manage to squeeze in some time to finish my guest post. I have received quite a bit of positive feedback on the first post, and I must say it was nice to be able to share some of my thoughts with the community. We want you all to be as up to date and knowledgeable about the tech we are developing as possible, and this is one of the steps we are taking to achieve that. Now, last time I mentioned that we would touch on the nodes, so here we go…
So how about those nodes?
First a short overview: The node ecosystem design is not actually designed by me but our Founder and CEO, Jimmy, though I do know the rationale that goes behind it. Supernodes are basically the block producers in the DPOS-based consensus network, but voternodes also play a crucial role and should have a well-designed incentive structure. A 4-tiered voternode system allows various types of investors, both from the community and small partners, to get involved and have a “stake” in the ecosystem. Data cloud nodes will have application-level value to the network, supporting the decentralized storage and management of consumer data, and it is also the lowest entry barrier method to get involved with the network. The node ecosystem is set up with long-term ecosystem growth in mind.
Voter nodes, tiers and a healthy network
The voter nodes are absolutely critical to the network, but we have to make a clear distinction here — a tiered voter node incentive system is not required, but rather something we decided to add. The breakdown of the number of nodes of each voternode tier under each supernode does not affect the functioning, whether on a network level or an application use-case level, of the blockchain in any manner.
Super computing data cloud nodes — do you need high end equipment?
In short; No, but more powerful equipment is likely to be used more and thus may earn more fees. The Data Cloud Nodes are recommended to have at least medium system specs, but really have no real hard-set requirements. However, the lowest spec nodes would potentially never be used on the network (and hence would never receive any fees). This is because, to ensure use-case requirements are met, we are implementing a performance and reputation system that takes into consideration a variety of factors including latency, storage capacity, computation speed and uptime. I know some have mentioned the Raspberry Pi — I love the Raspberry Pi, and I don’t see why it would not be possible to run a Data Cloud Node using one.
How to choose which node to run to maximize rewards — Data Cloud Node or voter node?
I heard a lot of people have been asking about the size of rewards, what to expect from a Data Cloud Node versus a voter node. Accurately calculating this is not possible yet, but there is no need to worry if you hold an amount of CPX that is at or just above a voter node tier threshold. I am happy to inform you that the staking requirement is not exclusive, but inclusive. What this means is that if you had 20k CPX, you could run both a T3 voternode (no CPX requirement) and a Data Cloud Node. Similarly if you had 70k CPX, you could run a T2 voternode and a Data Cloud Node. Yes please, I’ll take them both.
Mainnet comes first, but what about sidechains, sidechain consensus and scalability? Can we have the DEX ready on mainnet launch?
Our original roadmap stated that mainnet was planned for Q2 2019. However, due to the productivity within the team as well as the rapid expansion of the team I am now very confident that we can achieve deployment of the mainnet in Q1 2019. We will as a matter of course work with external organizations to review the code, ensuring the quality of the code and the security and stability of the blockchain. After mainnet launch we can focus on the deployment of sidechains, and based on where we are at now, I aim to have us ready to deploy the first sidechains in Q2 2019.
While on the subject of sidechains, it’s important to note a few aspects about their consensus mechanism. The sidechains will run a Proof-of-Stake (PoS) mechanism that the enterprise’s Supernode on the main network has no role in validating. Rather, the sidechain will be validated by a different set of decentralized nodes which Apex Network’s core development will provide the infrastructure for via the voter node ecosystem. Alternatively, if the enterprise wishes to host its own sidechain infrastructure, they also have an option to do so, and it would essentially become like a hybrid borderline private network. Note that given all technical and use-case nuances are taken into consideration, it is not our job to argue with the enterprise users on issues such as these in priority of adoption.
Typically with projects like ours, everything looks good in design as well as conceptually. Real scalability testing is however done through battle testing while the piece of tech is running in production mode. We are currently in the process of moving a team of 3–4 testing engineers from Apex Technologies to the blockchain team for this purpose, to get ready for when testnet comes around. The 3-layer smart contract architecture helps in the long run when a sizable number of applications are run on the network, but this is not really the crux of the problem. You can be assured that we have a realistic view on this, and are planning to deploy ample resources within the company to solve any scalability issues that could arise.
The DEX is on the roadmap for Q3/Q4 2019, but this could possibly change depending on the speed of both development and adoption / deployment of sidechains. A DEX protocol in itself is not difficult to build — it would require that the mainnet and the virtual machine is up and running reliably first. I think the challenge of this module is that it’s actually sort of an ecosystem in itself with quite a few moving pieces. You need a certain number of tokenized enterprise assets first, and then the reserve holders who provide the liquidity.
Some thoughts on enterprise integration and consensus on the sidechains
Apex Network is all about the enterprises using it. They will adopt and provide value to the network only if they see it as a natural extension of their existing solutions. Therefore it’s our job and goal to make it as simple as possible for enterprise users to integrate protocol-level features of Apex Network in their backend systems, B2C applications, online/offline customer touchpoints, and in general the entire consumer experience. The service layer (SDK/APIs) exist specifically for that purpose. The DEX is not necessarily an application-level feature, but rather more of a protocol-level service that can be integrated into both the Apex Wallet and any other applications that require the DEX protocol. It gives the enterprise user the freedom to integrate it in a manner that fits the existing application the best, and in a way that does not disrupt the existing customer experience but rather enhances it.
Final words
That’s it from me for now guys. I hope you have enjoyed learning more about who we really are, and the work we do here at Apex Network’s blockchain team. I would like to thank everyone who took the time to read and digest this information — I hope it will strengthen your confidence in our ability to realize our vision, and that you will take pride in being a part of the Apex Network community. I’m not yet sure who will be the next one up, whether it’s Tiger or Robert, but I’m sure they will have valuable insights for you about their part in the puzzle that is Apex Network. Until next time!
Sincerely,
Richard Wang
CTO, Apex Network and Apex Technologies
