There is a lot of fun to be had when you are above average interested in the technology behind a blockchain. A precious few of us can read code, but there are other ways to engage and gain insight into what is actually “under the hood”. In the Apex Network node ecosystem the supernodes are the validator nodes for our dPOS consensus mechanism, and they are the nodes under which most community members will stake our CPX.
With this in mind, what could be more interesting than trying to deploy a supernode and synchronize with our guys in Shanghai to take part in block production and transaction validation on the network?
Shortly after Apex Network announced its initial mainnet technology launch, yours truly started working to achieve this. This served the added purpose of testing decentralization aspects of the network along with synchronization speed among other things. Currently the JaypexNetwork supernode is fully synchronized with the other nodes and blocking away on the official Apex Network blockchain — here’s how it happened:
Ingredients:
- A handful of friendly Shanghai devs (Alex, Shan & Jude)
- An awesomely helpful programming wunderkind (Aldo)
- A slightly confused but persistent community manager (Jay)
- A dedicated server in France with the following specs:
CPU: Intel Xeon E3–1270v6–4c/ 8t — 3.8GHz/ 4.2GHz
RAM: 32GB DDR4 ECC 2133MHz
SSD: 2x SSD NVMe 450GB Datacenter Class Soft RAID
Bandwidth: Unlimited traffic — 500Mbps bandwidth
OS: Ubuntu 18.04
- Software for communicating with the server (MobaXterm for desktop, JuiceSSH for mobile)
Having deployed several nodes during the testnet phase in collaboration with other community members, the initial setup was fairly straight forward. The server came with a blank Ubuntu 18.04 installation, but needed a couple of other bits of software before code could be compiled and nodes deployed:
Git: Allows you to clone a Github repository among other things
Gradle: Compiles the code for the blockchain core (node) and CLI
Java (JDK8): Necessary to be able to run the compiled code
With these installed it’s an easy process of just a few steps to get the code for the core (the node itself) and the CLI (the wallet) compiled
Once the code has been compiled, the node must be configured to be able to connect with the other nodes. This entails telling the node which other nodes exist on the network (IPs) and which ports they like to chat on. One’s own IP and port must also be specified, and your private key must be provided if you want to have any chance of becoming a block producer.
For the nodes to know that they are supposed to build blocks on the same chain, the timeStamp of the Genesis block and other parameters must also match. All the necessary information along with a sample settings file were provided by the devs, and mine and Aldo’s public IPs were whitelisted on the running nodes.
With everything compiled and configured the node was launched and started synchronizing.
However, after a few hundred thousand blocks the synchronization speed seemed to taper off and eventually stall. Aldo went diving into the code, and logs from the server were sent to Shanghai for analysis.
After some minor code updates I could recompile and redeploy the node. Synchronization speed between France and Shanghai gradually became more stable, and focus could shift to shortening the time it takes to synchronize a new full node from scratch. The guys in Shanghai are quite fond of logging everything to continually debug — at one point they got a little eager with their debug log settings:
With the help of Aldo some additional proposals were written out and sent over to Shanghai.
Through log analysis and minor code improvements speed was doubled within a few days, and at the time of writing a new full node is able to maintain an intercontinental synchronization speed of ~5,5x the speed with which the chain grows (~650 blocks per minute vs 120 blocks generated per minute).
Further planned improvements include the fast synchronization mode as well as several other proposals that are being discussed to ensure future fresh nodes are able to quickly catch up to a growing blockchain.
The improved sync speed allowed my node to catch up with our guys in Shanghai on July 3rd — converting from receiving and confirming batches of old blocks, to receiving freshly produced blocks live and appending them to the local chain
Naturally, this was appropriately celebrated with a Telegram GIF party.
Being fully synchronized meant that I could use my node to query the blockchain for transaction data and broadcast transactions through the CLI. For a full list of available CLI commands, check out the Github overview.
Next up was trying to register the node as a block producer candidate and getting voted in to actually start producing blocks. This involves a couple of steps.
- Make sure you have funds in your wallet — a helpful friend in Shanghai is useful to have for this step:
2. Broadcasting a node registration request with information about the node:
Link: Verification of the smart contract invocation after registering the node:
3. Voting for the node as a block producer in collaboration with the guys in Shanghai:
Link: Verification of a vote for a producer:
4. …
5. Profit!
Naturally, such an event must be appropriately celebrated with a Telegram GIF & sticker party.
The deployment would not have been possible to perform successfully in such a short amount of time were it not for the very generous assistance from and brainstorming sessions with our community developer Aldo, along with an engaged and friendly dev team in Shanghai, always on the ball and quick to respond with suggestions and fixes. I’ll be continuing collaborating with the dev team to test different aspects of decentralization, optimizing synchronization of new nodes and various other parts of the technology throughout phase 1.
I’m sure there are more of you that would like to take part in this process — there’s no set time, but community members being able to sync up with Shanghai is something they’re working on.
Note: This does not mean that the node deployed is a permanent supernode — the application and voting process for this has not launched and details are unknown. This node is merely deployed for testing purposes for a limited time with the goal of learning as much as possible about the tech and helping our hard working guys in Shanghai test certain things.
Until next time,
Jay,
Community Manager, APEX Network
APEX Network
- Visit our Website
- Follow us on Twitter
- Join our Telegram Community
- Subscribe to our Announcements Channel
- Subscribe to our Subreddit