Use Neon-wallet-db + Neon-js + NEO-CLI/RPC to build a light wallet server

This article will build a NEO light purse that does not have any function, and all the effort is focused on successfully running the neon-wallet-db project and serving the light purse client with a full node neo-cli /rpc interface.
There are several items that need to be prepared first:

1. Neon-wallet-db
2. Neon-js
3. Neo-cli

Then is the dismissal part, namely the author completes the feat Preparation environment:

1. 4 Debian virtual machines, all running consensus nodes
2. 4 virtual machines provide an interface to run as a RPC node /rpc
3. Another running project in 4 virtual machines neon-wallet-db
4. neon-wallet-dbthe prerequisites for running the project are as follows:
   4.1 Running the mongodb service side
   4.2 Running the redis service side
   4.3 Installation python Environment (the author is 3.6.3) (recommended with pyenv+virtualenv)
   4.4 Installation heroku cli Follow-up will use the heroku local run project

The necessity of the NEON-WALLET-DB project

Neon community-maintained neon light purse The project is actually a react + electron Web project that neon-js interacts with the test network and even the main network internally by invoking the provided API.
Then think about how a light purse can be done without synchronizing a full node transaction .
The answer is no. The light purse here is just a remote call to the /rpc interface, the whole node is maintained by remote neo-cli .
So the question is, since all operations are actually calling the /rpc interface, what is neon-wallet-db the project for? This has to do nel-cli with what interfaces are provided:

That's all there is, and a neo-based Dapp is going to do things with so many interfaces. Where the deal goes and does not say, focus on how to query transactions (that is, the blockchain technology is widely circulated utxo), there is no doubt that these utxo are contained in the block and stored in the full node, it needs an interface to obtain the block information, that is, the above getblock interface:

Call method is to take the block index to check the block information, how to achieve the query of the balance of an address? Using the interface provided above is getbalance very beautiful, this interface is based on the premise is to open the wallet, that is, only to get the balance of the neo-cli wallet opened in this. The real thing is--traverse all the blocks and utxo count them all. This is why it is necessary to neon-wallet-db traverse and store the Uxto data in advance, so as long as the interface that it provides is requested, it can directly get the convenient data that it has processed, without having to traverse the block information of all the millions (up to the current test network) of Neo.

Run a private chain consensus node

The operation of the private chain is relatively simple, download the official neo-cli release can, run if there is a problem (very likely) need to actively browse official documents and github README troubleshooting.

The configuration of the 4 consensus nodes protocol.json must be consistent, with the node IP address and the corresponding public key of the consensus address, in order to establish a minimum consensus and then generate chunks.

Also choose a consensus node to run the /rpc interface, the command is dotnet neo-cli.dll /rpc , and then the actual RPC interface used is http://192.168.1.x:20332 ( rpc node IP and default port).

The official private chain is a bit of a jump in the document, making it confusing when to use neo-cli it or not neo-gui . In fact, the return to the literal consensus is nothing more than 4 neo-cli nodes agreed to add a block every 15 seconds, no neo-gui matter. NEOThe actual test network is also estimated protocol.json that several nodes are running neo-cli , and then the vast majority of developers use cli or gui go to connect. That is the same as the private chain, 4 sets of consensus node is essential (what consensus can be reduced to 3 sets of such words directly ignored).

This is the author of the 4 Linux virtual machine, and then under the external windows connected to this private chain:

Then just ensure that the four nodes of the block data consistent, protocol.json configuration consistent, you can arbitrarily connect to the private chain, and even delete all the chunk data to reset the private chain.

Configuring Neon-wallet-db and Neon-js

The operation of the consensus node is fundamental to the entire private chain, using the interface it provides to /rpc do everything, and it neon-wallet-db is used to cache chunk data in the private chain to exempt certain operations that need to traverse chunk data (such as querying balances).

First directly clone these two items:

git clone https://github.com/CityOfZion/neon-js.gitgit clone https://github.com/CityOfZion/neon-wallet-db.git

Modification of NEON-JS

Neon-js default is to set several remote /rpc service side and running neon-wallet-db service side.
src/api/neonDB.js src/api/neoscan.js This method is directly modified here:

This address is the neon-wallet-db address of the project that was later run.

Modification of NEON-WALLET-DB

Neon-wallet-db is very powerful, used heroku to build, a command to heroku local do, and then to a clean Linux system to solve the error of the report.

First of all, it's a bit trickier to install under Windows than Linux, because it involves python , heroku and several non-relational databases.

1. Guaranteed to be installed.heroku cli
2. Installation MongoDB , all using the default configuration, running the service can
3. Install Redis , use the default configuration, run the service to
4. Can be installed again Memcache , but I do not want to challenge more than one database, directly ignore can also
5. Installation python 3 , the author is 3.6.3 , with thepyenv + virtualenv

When you are ready, make sure that the Python environment in the NEON-WALLET-DB directory is 3.6.3 , and then

pip install -r requirements.txt

Modify api/util.py :

Modify api/db.py :

Disable memcache :

Questions:

The code involved in os.environ.get the operation of the method throws an exception, which is limited by the author python 's understanding of the project is insufficient, so directly all deleted, write dead configuration.

The next step is to manually synchronize the chunks and create a new one rebuild.py :

from apscheduler.schedulers.blocking import BlockingSchedulerfrom rq import Queuefrom api import redis_db as connfrom api.blockchain import storeLatestBlockInDB, getBlockCount, blockchain_db, storeBlockInDB, checkSeeds, get_highest_nodefor i in range(0,5) :  storeBlockInDB(i)

For the range(0, 5) height that you want to traverse, that is, to manually store the data of the chunk of the pass, directly execute it python rebuild.py . For large chunks of data, you can do this by storing the data yourself, then running the entire project and then continuing from the stored height. In order to do this, we have to match the block height values in several areas of the project:

And then what can be done

If all goes well heroku local , you should see a log of three colors beating. Then make sure that there are no errors in log and try to access the interface /v2/block/height , which is perfect if the height matches the true height of the private chain.

We now have three artifacts:

1. /RPC node Server (NEO-CLI)
2. Chunk data Service side (NEON-WALLET-DB)
3. Neon-js

The relationship between them is expressed in a picture:

Where the yellow part is the bottom node and the interface, the green part is the /rpc cache interface that updates the data periodically, the pink part is the light purse client, it does not save the chunk data, but it is saved in the cache interface.

As for how to develop a light purse, that is, to use a light purse to make a transaction transfer, a contract to invoke these practical things, there is a lot of space to say:)

Use Neon-wallet-db + Neon-js + NEO-CLI/RPC to build a light wallet server