How about that APEX wallet?

The wallet development has been a learning experience for us. The latest version of the wallet has seen less bugs due to a comprehensive upgrade of the stability, availability and error tolerance of the backend services combined with improving the usability of the app. Future versions will see more focus put towards the data service of the app, which naturally is a core functionality considering the vision of APEX Network.

Impression of the APEX Wallet with full functionalities

Four of the main challenges we encountered during development so far relates to the nature of the Ethereum and NEO blockchains, these are;

The acquisition of nonce while making ETH/ERC20 transactions can be difficult to control, especially when making multiple transactions continuously.

The full node synchronization of the Ethereum blockchain was not synchronized to the latest block on the whole network. We later used a third party Parity open source client to solve this problem. We have also upgraded the backend service architecture and use both fast and full nodes to ensure stable operation.

NEO transaction analysis can be problematic at times, as the block explorers such as Neoscan and Neotracker have intermittent difficulties with the transaction records. So far we have mostly overcome this issue after several iterations of code.

NEO’s node synchronization is occasionally unstable, and it has been difficult to find the exact cause of this. To compensate for this we added multiple nodes to ensure the stability of the backend service.

The APEX wallet will gradually become more biased towards the main purpose of APEX Network. Product Manager Qi Zhen Zhang is working diligently on the top-level design of this, to create a new business model that allows consumers, enterprises and service providers to achieve proper value. The next big version update is planned for early next year, combined with launching on the app stores. The main focus is working on the link between the wallet and the APEX Network blockchain.

Testing… Testing… Testnet!

The testnet is currently very stable, producing new blocks every 0.5 seconds and blocks being confirmed by the consensus nodes within a few seconds. Compared to Ethereum’s 15 second blocks and EOS’ 0.5 second blocks we are on par with the leaders of the industry. The consensus module is actually the part of the blockchain code that we have been the most satisfied with so far. It is extremely important to get this part right in the early stages to avoid cumbersome attempts to update it later.

Node log screenshot from one of the testnodes run by a community member

The current version of the testnet website allows users to view the latest blocks and amount of transactions, recent trading volumes and number of active accounts. These statistics may help users better understand the status of our testnet. We are working on the development of the full public block explorer. To facilitate data collection during this testing phase, our back-end server has a special module to parse the block generated by the main network and write the block data to the database.

Some may be wondering whether the APEX Network mainnet will be prone to forking issues. To avoid this we have adopted a consensus model similar to that of the EOS mainnet (instead of BTC, BCH etc), which basically has no major fork issues.

Developing a quality blockchain does not come without its challenges, and during development we have encountered two relatively large difficulties. Firstly, the block rollback mechanism. Whenever there is a fork during block production, you may want to roll back the block produced at this point in time. The logic of block rollback is very strict. While the logic itself may be very simple, the actual operation can cause problems. Secondly, the block consensus. It is very difficult to produce new blocks in as little as 0.5 seconds while ensuring to the greatest extent possible that there are no forks. After repeated code iterations we feel confident that these issues have been resolved.

We still have a lot of work ahead of us, optimizing the current testnet and adding essential functionality. The critical smart contract module is expected to take around three months to complete, and supporting Turing’s complete virtual machine development is also a work intensive task. While some components of the smart contract architecture are easy to complete like the logic layer, others are more complex. The logic layer is basically similar to an oracle, and the oracle is connected to an external network.

Over the next few months we will focus heavily on smart contract support as well as developing the economic model of the ecosystem. To illustrate; Ethereum introduced gas, and EOS introduced memory, CPU and bandwidth. The way the economic model of APEX Network is designed will contribute to the sustainable operation of the ecosystem. The proper operation of the data cloud nodes are dependant on the implementation of smart contract support, hence they are not yet operational.

Encrypted data is routed from the blockchain (using SHA-256 hash) and stored offchain in a DHT (distributed hash table) run by a collection of Data Cloud Nodes

Lots of people focus on TPS when evaluating blockchains, so it seems fair to mention what we are working towards in this area. As some of you may know, the world’s fastest processing system by far is Alibaba’s transaction processing system, with a TPS of approximately 390,000. Our mainnet TPS will gradually achieve this goal.

As far as programming languages go, we recognize that Go is a very effective language. Scala brings important aspects to the table though, and is a good fit to satisfy the need of APEX Network’s mainnet to support big data applications. Scala integrates various features of object-oriented and functional programming, providing important functionality for the bottom layer of our blockchain. This is also the reason why our blockchain division has a large number of expert level Scala developers.

Keeping in mind the developers in the community, we are considering introducing support for more programming languages to lower development threshold for smart contracts. The aim is to gradually build a technical community, and to harness the power of the community to aid in providing support for the various languages. Whether we use Ethereum’s EVM or EOS’ WebAssembly, support for various languages is naturally very convenient for developers.