If you followed the APEX Project recently you know that we are in the process of developing an application to manage and extend the functionality of APEX Supernodes. In the following writeup we wanted to share features we had in mind for an initial release.

Architecture

Nodemanager Architecture

Producer Node Worldmap

As you see in the graphic there are multiple components that are part of the application. Those parts are served as docker images and wired together with a docker-compose configuration.

Spring-Boot Webapplication

This is the component that Nodemanager administrators actually interact with as it provides a grapical user interface that you can access using any browser when the app is running. It enables you currently to:

Login & Register as admin with mandatory 2FA authentication

Install, update, start and stop the supernode

Edit the blockchain configuration settings

APEX Core

This is the actual supernode component that represents the blockchain node. It is not present when you first start the application but must be installed after registration. It is embedded into the docker image of the webapplication on purpose because the blockchain and configuration data should be accessible over the graphical interface.

MongoDB

This is an additional NoSQL database that is used mainly for caching. As you might know the blockchain core itself uses currently a very lightweight and performance oriented key-value store database (Rocks DB). While thats perfectly suitable for raw block production its not very beneficial for interaction with those datasets, like specific queries etc. Thats why the APEX Supernode Core offers a MongoDB plugin that can be activated if there is an instance to interact with. If the plugin is activated block data gets stored parallel in both databases. Using MongoDB allows additional benefits like:

Advanced Queries

Avoiding additional load on the core itself by frequent view requests for example

Github

Possible Features

Additional functionality that would benefit the scope of supernodes

Key Management

The Nodemanager could offer to store keys in local keystores on the server. This would allow registered users or dApps to perform transactions without having to manage or hold private keys themselves. Of course that requires trust from the user registering at a certain supernode but on the other hand improves usability and also security as the key is never exposed outside of the nodemanager application process itself. For better understanding let’s take a look at a specific example. Imagine having a light wallet application.

If the Nodemanager provides keystores, the light wallet could register users there simply over username + password + 2FA authenticaton.

The Nodemanager generates a new key for each user on registration.

Afterwards users create transactions using the light wallet without the need for any private key.

The light wallet could then push unsigned transactions to the Nodemanager which first signs for the authenticated user and then passes them to the core.

REST API

General REST API that can be accessed by registered users or dApps in order to access blockchain data. Examples here could be additional block explorers. This also protects the RPC Endpoint of the core itself, as the Nodemanager functions as a proxy for data access in that case.

In addition provide endpoints that differentiate between syncronious and asynchronious processing of transactions.

Notification Support (Telegram / Email)

Provide functionality that allows notification of Nodemanager administrators over different channels when anything relevant is happening on the server. Examples could be simple login and health status notifications.

Localization

Support multiple languages in the Nodemanager

Visualize producers

World map of all supernodes with votes and status information

Special transactions

Provide easy graphical creation of special supernode related transactions like register, unregister, vote etc.

The Way Forward

We will be working on the Nodemanager application over the next few months, gradually adding new features and refining the code. As these features and updates are implemented, new versions will be released, and our supernode candidates as well as tech enthusiasts in the community are encouraged to test the application and provide user feedback.

With this application we are working completely open source, and the latest code will always be present on Github. The development process is open to community contributions, and we encourage anyone wanting to assist with different aspects like UI, UX, coding, testing and so forth to reach out to our admins in the APEX Network tech Telegram community.

Sincerely,

Aldo & APEX Team

APEX Network