Look back the year of 2018, DxChain’s white paper wrapped up and seed-stage financing completed in February, DxChain Team founded in April, the private sale completed in May and the public sale completed in August. We also gradually launched MVP, Testnet Beta, Testnet 1.0, SDK and first decentralized storage product - DxBox. There’s no doubt that DxChain has the determination and capability to build a public chain, which is the world’s first decentralized big data and machine learning network powered by a computing-centric blockchain.

On the occasion of our 1st anniversary, DxChain successfully released Testnet 2.0, which greatly improved the fundamental performance based on the previous Testnet. In the next few months, DxChain will proceed with the upgrade and testing of the large-scale storage system based on Testnet 2.0 and the Mainnet development process steadily.

The Introduction of DxChain Testnet 2.0 and Development Update of 2019 Q1

On April 2, 2019, the DxChain team released Testnet 2.0 with a series of Automation Deployment Toolkit developed. Please refer down below for the introduction to Testnet 2.0 and the development progress updates.

DxChain 2019 Q1 Development Update

1. Smart Contracts Supportive
2. JSON RPC Improvements
   2.1. WebSocket
   2.2. Unix Socket IPC
   2.3. Protocol Buffer
3. P2P Network Feature Enhancement
4. Additional Commands Implementation
5. Automation Toolkit
   5.1. Local Node Deployment
   5.2. Chain Explorer Deployment
   5.3. Program and Resource Monitoring
   5.4. Program Testing
6. Javascript Console Supportive
7. DB Performance Analyzing

1. Smart Contracts Supportive

Based on the feedback getting from community developers, we designed and implemented the smart contracts feature for the Testnet 2.0, laying a solid foundation for the next phase of blockchain storage application productization.
There are several important implications for the combination of DxChain Testnet 2.0 smart contracts and storage contracts:

• The original storage contract only supports automated contract renew and money distribution. However, by combining it with the smart contract, more features can be implemented. Any developer can add features and create new products accordingly without modifying the source code.

• Based on our testing, the smart contract feature we developed in Testnet 2.0 is 100% compatible with the Ethereum Virtual Machine, that means for any DApps running on the Ethereum can directly run on the DxChain as well. It saves developers tons of time on solving issues occurred while migrating the application from Ethereum to DxChain.

• The current Ethereum smart contract cannot be used for storage transactions or applications. Even though the Swarm, a distributed storage platform, is developed based on the Ethereum, it is highly unstable. The smart contract developed by DxChain can be fully combined with the storage contract, adding more flexibility to the original storage contract and making the off-chain storage operations more efficient.

• Currently, most distributed applications are developed based on Solidity. Learning and using a new language to develop smart contracts will greatly increase development costs. By adding the smart contract feature, developers can easily build DApps without learning any new materials.

2. JSON RPC Improvements

The system only supports HTTP RPC method in Testnet 1.0. For the Testnet 2.0, new RPC methods are implemented, which are:

• WebSocket
• Unix Socket IPC

2.1. WebSocket

By adding WebSocket implementation, subscription feature is able to be implemented. The client can subscribe to an event, and the server will automatically send the results back to the client once the event is triggered. In the blockchain system, we can take the blockchain changes as an event and enable the node's subscription to these changes.

For instance, the change on the blockchain is an event that can be subscribed by the peers. In our previous implementation, it will be broadcast to all the peers when the change occurred, regardless if they need the information or not. By using the subscription system, the changes on the blockchain will only be sent to peers who subscribed this event, lowering down the network traffic and improve the data transmission speed.

2.2. Unix Socket IPC

Besides WebSocket, Unix Socket IPC implementation is added in this release as well to improve the efficiency on the interprocess communication since there is no need to establish a network connection on communication among processes on the same server.

2.3. Protocol Buffer

In addition, research is also conducted to compare the performance of two data serialization mechanisms: JSON and Protocol Buffer, where the former one is used in our current RPC system. Our research shows that the protocol buffer is more efficient in data compression than JSON, meaning that the data transmission speed will be improved when there is a large amount of data transmitted through the network. Currently, we are considering switching the JSON RPC implementation to gRPC implementation based on the results. However, more tests need to be done to figure out the data size threshold that can cause a significantly different transmission speed between two mechanisms.

3. P2P Network Feature Enhancement

Our new P2P network model implemented the features introduced by static and trusted nodes, which enhanced the stability of the connection established between storage renter and host. The features are briefly introduced as follows:

• static nodes: the connection will always be maintained, restrictions will not be applied to those nodes
• trusted nodes: the restrictions will not be applied, but the connection is not always maintained

In addition, IP whitelist is another feature added to the P2P network. By using the command ipwhitelist introduced in the next section, the user can choose which IP address is allowed to establish the connection to the local node, gives user maximum privilege on improving system security by limiting and controlling access only to trusted nodes.

4. Additional Commands Implementation

Previously, only limited commands are supported by the system, such as accessing blockchain status, sending transactions, uploading files, etc. Now, we have implemented additional commands to support more operations:

5. Automation Toolkit

To improve the code quality, system reliability, and stability, we have implemented automation toolkit which supports automated program deployment and testing. The scripts are all written in python and will be open sourced in the future to help developers test their private chain. Here is a brief introduction on what this toolkit is capable of:

• Local Node Deployment
• Chain Explorer Deployment
• Program and Resource Monitoring
• Program Testing

5.1. Local Node Deployment

For the local node deployment, the tool will build the gdxc executable based on the program stored on the local machine, and upload it to the developer-defined remote servers (supports deployment on multiple servers). Once the uploading process finished successfully, a terminal multiplexer will be created where the gdxc program will be executed. The node will automatically connect to the bootstrap nodes pre-established by the DxChain Network and synchronize the blockchain. All the node configurations, such as bootstrap nodes and IP whitelist, will be read from the configuration file defined by the developer.

5.2. Chain Explorer Deployment

After the node is up and running, the chain explorer provides a convenient way to observe the node’s status. The explorer is a web application which connects to the node and is used to get all blocks’ information, such as block height, parent hash, transactions, nonce, etc.

5.3. Program and Resource Monitoring

To ensure the availability and overall performance of the program, the monitoring system is implemented. For example, if the program crashed due to unexpected errors, an email will be sent to the developer with the specific error traceback information. In addition, if the system resources usage reached a limit, such as CPU usage reaches 100%, a warning will also be sent to the developer, so he or she can take immediate actions.

5.4. Program Testing

Last but not least, various tests will be performed regularly once the node is up and running. Types of tests supported by the toolkit are listed as follows:

• Regression Testing
• Performance Testing
• Unit Testing
• Integration Testing
• Reliability Testing

By performing those tests regularly, the stability and reliability of the program will be improved significantly.

6. Javascript Console Supportive

Currently, most web DApps are implemented based on the Javascript libraries, therefore, to make our program more developer-friendly, we have added the Javascript Interpreter feature.

The interpreter is implemented based on the otto Golang package. Once the Javascript code was sent to the interpreter, the code will be converted into Golang code and got executed. The result will be sent back after the execution.

By adding this feature, we can implement Javascript libraries in the future to support convenient DApp development. For any web developers, they can develop their own DApps without knowing much about how blockchain works.

7. DB Performance Analyzing

There are two popular key-value databases in Golang, which are:

• LevelDB
• BoltDB

LevelDB implemented the log-structured merge-tree, where the key-value pair will be stored sequentially in different files. Those files will be regularly checked and merged into a bigger file in order to optimize the reading performance. Based on our testing, when there is an increasing amount of keys, the reading performance will be affected negatively a lot, where the writing performance remains almost the same.

BoltDB, on the other hand, is implemented based on the B+ tree, it fits better in read-heavy usage because it supports data reading concurrently (no locks). Unlike LevelDB, BoltDB only creates a single file that is used to store key-value pairs.

Currently, our system uses BoltDB as the database engine in Testnet 2.0, however, we will continuously perform tests to evaluate the performance of those two databases. If the clear advantage can be observed from one of them, we will make modifications to the database engine implementation accordingly to improve the overall system performance.

Thank you for your confidence in our team, and for your support for this project.