NNS

Decentralized applications (dApp) are programs that have been built with blockchain smart contracts embedded into the software. In the past few years, dApp development has been increasing in popularity at a rapid rate. With its rise in usage, developers have had to design and choose the kinds of system architecture that best incorporate smart contracts, and what platforms make the best use cases for dApp development.

An underlying thought about blockchain is that it’s simply a distributed database that returns data when a user makes a request. In a centralized and conventional database system, multiple users can make a large number of parallel requests. However, with blockchain a large amount of parallel requests will lead to a large delay in confirmations, or force the blockchain to timeout.

Additionally, the blockchain ledger differs from centralized systems in that it sacrifices efficiency for security. Meaning, a blockchain will have a block interval that ranges from a few second to a few minutes, as opposed to near instantaneous intervals of milliseconds with conventional database systems.

Therefore, decentralized blockchain ledgers can’t handle a large number of parallel requests, and have slower confirmation times compared to conventional database systems.

With the above assertions, we have designed a layering and refactoring methods within the dApp system architecture (using the NEO ecosystem as an example):

The dApp system architecture is implemented through three layers (streamed left to right in the image above):

the chain data layer,

2. the database cache layer, and

3. the front-end cache layer.

The original data located in the chain data layer is copied to the database cache layer at a ratio of 1:1. From the database cache layer, the data is expanded and processed into specific forms required by the front end architecture. The generation of each block will trigger a one-time (i.e. one-batch) data read. Once the block has been generated and the batch data read, the front-end cache layer synchronizes with the data cache layer at intervals of a fixed period of time (for example: 15 seconds).

This process greatly reduces parallel requests to the chain data layer, the amount of front-end operations required, and the complexity of development.

Refactoring Method

In order to verify the rationality of the dApp system architecture, we have reconstructed an exemplary front-end tool in the NEO Name Service (NNS) bidding contract.

After weeks of testing, we have identified the following problems in the current

version of NNS:

1. Fully identical data presents inconsistencies at different locations at the same time, and

2. A build up of pressure on both the back-end API and database leads to frequent jams.

To resolve the two issues of data inconsistencies and frequent jamming, we have developed a method to to efficiently maneuver the dApp system architecture called the “refactoring method.” The refactoring method will follow the process below:

1. Design a full data class to abstract into the auction contract.

2. Transform the data warehousing logic, and gradually fill the complete data class with the contract notification as a trigger.

3. Transform the front-end data presentation logic, as it’s the front-end that determines which auction lists will be shown to the user. Additionally, data rendering will only accept the front-end cache, and the data will be synchronized once in a block time.

Ultimately, the refactoring method strives to ensure data is completely consistent, with minimal pressure on the back-end, and provides the best front-end experience.

Next Steps

We are currently working on verification processes, and the design is expected to be completed in 2–3 weeks, at which point further testing is planned to occur.

System architecture optimization may delay the NNS Mainnet version launch on the previously scheduled timeline. In order to facilitate a more convenient integration with other wallets, we believe that it is worth spending more time on the system architecture up front.

Upon completion of the processes previously covered, NNS Mainnet will be ready to launch.