APEX Network blockchain development progress
Development status report — #1
During the outwardly quiet times leading up to a new release — whether it concerns code updates, feature implementations or product releases — it can be hard for community members to know exactly what’s going on. That is, unless it’s possible to peek through the curtains and get an impression of what is going on over here in Shanghai.
To remedy this we would like to share with you excerpts from the weekly memos in the blockchain division, outlining completed and ongoing work on a granular level as the year progresses. In this article you will find a short summary of the development progress during the last six weeks — and more of these may be shared in the future.
Development focus, weeks 22–27 (May 25th — July 3rd)
- Redesigned APEX Federated Learning (AFL) code logic to increase the scalability of subsequent models
- Fixed an APEX Network light node memory overflow vulnerability
- Completed the AFL distributed RSA Intersection server search service (identifies the intersection of consumers between enterprises, on the premise of not divulging other consumers’ data)
- Ran tests on the AFL distributed intersection service; Initially too low efficiency, increased raw intersection and rewritten to rectify this
- Implemented the design and code of the APEX Network supernode permission splitting (a measure to ensure the safety of producer funds), tested and verified changes
- Tackled various optimizations to deal with network overfitting problems and added general hyperparameter adjustments
- Optimized the AFL XGBoost algorithm complexity through reducing calculation and communication complexity
- Enhanced the AFL XGBoost algorithm to support regularization, sub_sample, sub_features, early stop, random seed and multiple other features. AFL XGBoost will support regularization of trees
- Found classification faster than regression for the AFL XGBoost algorithm, identified the issue and found a solution to optimize this
- Observed that AFL XGBoost multi-process support and multi-process efficiency is not as good as single thread. Hypothesized that the cost of opening the interpreter is too high and optimizing this
- Unit tested the core and CLI after multiple optimizations had been implemented, located a couple of issues which were solved and afterwards tested (CLI failed to create wallet and obtain account information, produced a nonce error for transactions — all solved). Investigated and solved failed unit tests for the core, refactoring the code in the process
In summary the remaining issues identified on the main chain and CLI have been dealt with, and we will be starting our work on the Ledger integration next week. As you will see above a lot of focus has been on AFL XGBoost — this work is nearly done, and we are running further tests. The training cost of the federated learning model is high, so the model cannot be easily overfitted. It is subject to Python’s global interpreter lock (GIL) — Python is computationally intensive and must use multiple processes.
Another important task we will be focusing on shortly is to design the AFL smart contract, which will help CPX capture its value. Before designing this contract we will be releasing the federated learning module without the smart contract for community testing.
Obviously there have been quite a few changes made to the code, and we are preparing to release these updates to Github as well as implementing them on the public chain.
For a non-technical community member who is not intimately familiar with our blockchain or the federated learning module the points above may be hard to decipher. To sum it all up in a single sentence: Development is progressing well, and we are identifying and optimizing functionality and performance as we go!
Thank you for your time,