Having put the worst of the COVID19 crisis behind us here in Shanghai, it is time to take stock and share where we are at development wise. We know and appreciate that the community has been anxious to learn what has been going on, and are happy to share updated information about what has been going on and where we are headed.
Federated learning is the primary focus in our current work. Considering how we envision the ecosystem to work, a significant part of what we aim to achieve will and must start from federated learning. The development process of this module consists of the following four phases:
- Testing the federated learning component based on XGBoost
- Deploy data protocol based on APEX Federal Learning
- Build a Data Alliance based on APEX Federal Learning
- Develop our digital integration business based on the APEX Data Alliance
Considering the above four stage rocket it will be obvious that there are flywheel and network effects in the third and fourth stages. At present we have overcome approximately 70% of the technical difficulties involved with developing this module. As has been mentioned before, there is an encryption technology that prevents both sides in the federal learning process from knowing which consumers are public consumers, and we are further studying this technology.
We estimate that it will take another month or so, after which we will update the code for federal learning on the APEX Network Github. In addition we have found that the boost method in machine learning is the key to federal learning, and that based on the boost method federated learning can be extended to more machine learning methods. In our current work, we are basing our module on the federal learning module of XGBoost which has proven its leading position in Kaggle.
Our core product strategy at APEX Network is to first gather enough enterprises, then build these enterprises into an alliance before proceeding to grow a digital integration ecosystem. We’re confident that delivering this early joint learning data alliance can attract a significant number of enterprise users to achieve this goal.
The desktop client is positioned for enterprise users, and will integrate Ledger hardware wallet support. Focus will be shifted to desktop client development as soon as the federal learning module has completed. Our plan is for the first version of the desktop client to integrate support for the Ledger hardware wallet while supporting basic functionality such as transfers, balance queries and multi signature.
As we consider the various scenarios and need of enterprise users and consumers using CPX to significantly overlap, the desktop client will be available for both groups. In time we will consider developing a second, standalone consumer desktop wallet. Other modules such as the federal learning module and refining some aspects of the core chain take priority over this though.
Ledger integration takes time as there are multiple requirements that must be met before one can submit a proposal for review by the Ledger team. Some of this work is trivial, other parts not so much. The main components are the Ledger app itself which community developer Stephan has recently delivered, and the other is the companion app which is the desktop client currently in development. We are continuing our work to put all the pieces together to deliver Ledger compatibility for mainnet CPX holders.
We have been testing community developer Aldo’s dockerized Node Manager and find this integration tool to help users manage nodes more efficiently, giving a clear visibility into the operation of the node. This is helpful as enterprise customers definitely will not be using command line tools to run nodes, but need user friendly management tools with a good GUI.
Core chain and staking
We are working on optimizing a couple of aspects regarding the core chain in parallel with our other work at this time. For one, we have realized that the scalability of the RPC is not at the level we want it to be. As this scalability issue does not involve consensus it’s a secondary task, but it is an easy one to complete.
Another change that will be made is to split the authority of the supernode producer into an investor and a producer account. The investor account will be holding the stake and be able to withdraw the deposit and the rewards, while the producer account is used to sign the produced blocks only.
The third item we are currently looking into is optimizing the light node mode. We have noticed that this mode can sometimes cause exceptions, and will be running extensive tests to locate and resolve the issue.
The staking by ordinary CPX holders not running supernodes is essential to ensure the security of the mainnet in the POS consensus, and the super node operator and the individuals staking assume different but complimentary roles in the ecosystem. We are working on further developing the supernode’s smart contract to enable the supernode to share the obtained rewards with the individuals staking in support of it. In order to ensure free competition between nodes it has been decided that the ratio distributed will be adjustable, encouraging generous reward distributions to secure production status for the supernode.
Though we cannot provide an exact time for the token swap, we can shed some light on which elements of development must see completion before the token swap will be performed. There are two main items on this list, the first being to complete development and testing of APEX Federal Learning’s XGBoost algorithm. The second is to finalize the optimizations of the core chain mentioned above.
The intention is to perform the swap through a smart contract solution. This is not overly complicated, but from a project progress and ecosystem perspective it would not be a wise choice to launch the final iteration of our mainnet just yet. When we do go into production mode the AI customers of APEX will be among the first batch of enterprises trialing the chain and technical solutions, and these initial batches will then support our iterative blockchain products.
The developers’ perspective
As developers in a project team subscribing to the agile development approach, everyone needs to be familiar with all aspects of the core chain. One of our leading blockchain engineers, Fang, has for example been working on both smart contracts and the APEX VM for the last couple of months. One of the main perspectives that drives us forward is the promising future for this technology (adoption and monetization of the technological solutions) as it becomes more influential in the industry. Blockchain technology is essentially a new way of Internet support which does not require third party participation — and so long as the public chain captures an increasing number of payment scenarios, the value of the public chain will grow with it. The core team of the blockchain group has always had CPX rewards, and basically everyone holds CPX.
In addition to our perspective on the future of APEX Network’s public chain, we thrive on the challenges we encounter in our work as well as the satisfaction that comes along with being part of a creative and innovative team. To illustrate the atmosphere in our morning meetings where we share our recent work and learn from each other, we feel like we progress together much like classmates.
We hope you have found this development update informative. We do realize that some would like more exact timelines for when the different modules will be complete and released, but hope you appreciate the insight into current affairs that we have been able to share with you.
In appreciation of your ongoing support,
The developers at APEX Network