APEX Network — Pre Mainnet Development Progress Update
We are close!
In our last development progress update in February we announced the launch of phase two of the APEX Testnet. Since then we have been hunkered down in APEX HQ running tests and discussing optimization proposals and additional functionality to be included in the next release. As we are now fast approaching mainnet we would like to take some time to update you all on some of the technical changes and optimizations we have been working on during the last two months and leading up to the launch of our initial mainnet.
Optimizing the block explorer and web wallet
As most of you have noticed, the first version of our block explorer was recently launched, and generally well received by the community. Upon its launch we mentioned that we were working on integrating the voting feature to elect block producers, and this work has now been completed. The web wallet we have integrated in the block explorer now supports voting and redemption of votes for block producers, and the transaction details for such voting will be accessable through the transaction details option. We have also been performing some upgrades of the explorer’s backend service, which is the cause for intermittent service disruptions recently. On the esthetic side of things, we finally found time to tone down the initial moony skin, making its appearance more sleek and professional.
Upgrading the CLI, additional features
The APEX blockchain CLI tool enables the user to conduct transactions and issue a wide variety of commands for smart contracts. Detailed updated documentation for the CLI has now been uploaded to GitHub at the following address:
During the last two months we have been reauditing every single command of the CLI to ensure proper functionality. Another addition is the ability to convert the private key to a different format, regardless of the original format the user inputs.
As an additional security option, we now also support offline signed transactions. Offline signed transactions are basically at a level of security comparable to a hardware wallet, ensuring that those who do not have or wish to purchase a hardware wallet will still have an option available to transact on the blockchain with maximum security. To properly understand this, it is important to touch on some technical aspects regarding offline signing of transactions.
The basic procedure is as follows: Using the CLI in offline mode, the wallet owner enters the transfer address, amount to be transferred, gas limit and gas price to compute the transaction information using his or her private key. Doing this in an offline environment ensures the private key is not exposed in a networked environment to be picked up by malicious actors. The CLI will then broadcast the computed transaction information to be processed by the network nodes. We do realize that this may sound somewhat complicated to the average user, but rest assured it is simply an additional security measure available that is not intended to replace other functionality such as later hardware wallet support.
Dynamic Blockchain Expansion
One major change we have been working on is optimizing the characteristics of the dynamic expansion function of the blockchain, for which the most current version is found in the Proposal section of the CLI commands. To put it simply, this functionality allows for the block producers to change certain parameters of the block consensus to optimize the network without causing hard forks or having to manually update each node to the new state.
The way we have designed the dynamic expansion governance is to arrange a weekly cyclic election process, where the nodes producing the top 21 number of blocks are elected to the governance committee of the blockchain. This means that to be able to propose changes to the block consensus, a candidate node will first have to be voted in (see the previous section on the voting feature), and then remain in production mode for long enough to come out as one of the top 21 producers for the current week. This election will take place every week in the early hours of Monday UTC time. It is our opinion that this design ensures that only block producers that have experience on the network are able to submit suggestions for optimization, instead of random nodes proposing changes that might not at all be beneficial for network functionality or stability.
Examples of parameters that the governance committee members can propose changes to include such characteristics as lower gas limit for transactions, maximum block size and maximum size for individual smart contract. The latter limit is imposed to eliminate the risk of malicious large contracts causing stability issues on the blockchain.
Once a proposal is submitted, the nodes comprising the governance committee will vote on the proposal and at which block height it will come into effect if approved. Approval requires a 2/3rd majority, otherwise the proposal will be rejected. Once a proposal has been approved by a 2/3rd majority of the committee member nodes, the proposal will automatically go into effect at the prearranged block height as each node will automatically record the approved proposal and its decided upon block height. This removes the need for cumbersome manual updating of the nodes and ensures smooth operation of the nodes and thus the blockchain.
We are continuing to work on the dynamic expansion feature of the blockchain — it’s close to complete due to the addition of the features described in the previous section, but we still have some polishing we would like to do before the official launch.
Stability improvements, bug squashing & fast synchronization
The past two months of testing after the launch of phase 2 of the testnet has brought significant stability improvements to the network. We found a bug in a voting contract which could have potentially caused the blockchain to stall due to the backend not being able to catch a certain exception — this issue has now been rectified and has been working smoothly since. No other major issues have been encountered.
Another addition is that of a fast synchronization mode. This is a mode which is configured in a node before launch. It causes the node to periodically and proactively delete unnecessary transaction data and only save the latest status data of the blockchain, allowing the node to run using a smaller amount of resources. This is similar to a function found in the Ethereum blockchain.
We fully expect the necessary work before mainnet can be launched to be completed in the upcoming weeks, keeping us nicely on track with a Q2 2019 launch of the intial version of our APEX Network mainnet. After that we will continue to work on stability and functionality upgrades, striving towards perfection — development efforts will never stop. Once this work has been completed, we will open the initial APEX Network mainnet to allow community nodes to join the network. When we open the network, we plan to select some supernodes to be able to participate in block production and testing of the network.
We are looking very much forward to launching our initial mainnet, marking the completion of one of the most significant milestones of any project. During the development phase we have been studying other blockchains to assess the most important features and vulnerabilities, all the while comparing the solutions proposed by others to our goal of creating a blockchain tailor made for the needs of B2C enterprises. A mainnet is nothing without customers using it of course, and while we continue further development of the underlying tech with elements such as encapsulation of the blockchain services to create a «plug and play» solution for enterprises, we will also shift focus towards the actual integration of our target customers. Our gratitude goes out to all those who follow our efforts — we believe you will be as pleased as us to watch the evolution of the ecosystem in the months and years ahead!