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:
- Neon-wallet-db
- Neon-js
- Neo-cli
Then is the dismissal part, namely the author completes the feat Preparation environment:
- 4 Debian virtual machines, all running consensus nodes
- 4 virtual machines provide an interface to run as a
RPC
node /rpc
- Another running project in 4 virtual machines
neon-wallet-db
neon-wallet-db
the 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. NEO
The 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.
- Guaranteed to be installed.
heroku cli
- Installation
MongoDB
, all using the default configuration, running the service can
- Install
Redis
, use the default configuration, run the service to
- Can be installed again
Memcache
, but I do not want to challenge more than one database, directly ignore can also
- 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:
- /RPC node Server (NEO-CLI)
- Chunk data Service side (NEON-WALLET-DB)
- 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