Go Node and SDK for the NEO blockchain
Find a file
Roman Khimov 49be753850 core: spread storeBlock actions to three goroutines
Block processing consists of:
 * saving block/transactions to the DB
 * executing blocks/transactions
 * processing notifications/saving AERs
 * updating MPT
 * atomically updating Blockchain state

Of these the first one is completely independent of others, it can be done in
a separate routine easily. The third one technically depends on the second,
it just doesn't have data until something is executed. At the same time it
doesn't affect future executions in any way, so we can offload
AER/notification processing to separate goroutine (while the main thread
proceeds with other transactions).

MPT update depends on all executions, so it can't be offloaded, but it can be
done concurrently to AER processing. And only the last thing actually needs
all previous ones to be finished, so it's a natural synchronization point.

So we spawn two additional routines and let the main one execute transactions
and update MPT as fast as it can. While technically all of these routines
could share single DAO (they are working with different KV sets) benchmarking
shows that using separate DAOs and then persisting them to lower one actually
works about 7-8%% better. At the same time we can simplify DAOs used, Cached
one is only relevant for AER processing because it caches NEP-17 tracking
data, everything else can do just fine with Simple.

The change was tested for performance with neo-bench (single node, 10 workers,
LevelDB) on two machines and block dump processing (RC4 testnet up to 50825
with VerifyBlocks set to false) on i7-8565U. neo-bench creates huge blocks
with lots of transactions while RC4 dump mostly consists of empty blocks.

Reference results (06c3dda5d1):

Ryzen 9 5950X:
RPS ≈ 20059.569   21186.328   20158.983   ≈ 20468   ±  3.05%
TPS ≈ 19544.993   20585.450   19658.338   ≈ 19930   ±  2.86%
CPU ≈    18.682%     23.877%     22.852%  ≈    21.8 ± 12.62%
Mem ≈   618.981MB   559.246MB   541.539MB ≈   573   ±  7.08%

Core i7-8565U:
RPS ≈ 5927.082   6526.739   6372.115   ≈ 6275   ± 4.96%
TPS ≈ 5899.531   6477.187   6329.515   ≈ 6235   ± 4.81%
CPU ≈   56.346%    61.955%    58.125%  ≈   58.8 ± 4.87%
Mem ≈  212.191MB  224.974MB  205.479MB ≈  214   ± 4.62%

DB restore:
real    0m12.683s 0m13.222s 0m13.382s  ≈ 13.096 ±  2.80%
user    0m18.501s 0m19.163s 0m19.489s  ≈ 19.051 ±  2.64%
sys      0m1.404s  0m1.396s  0m1.666s  ≈  1.489 ± 10.32%

After the change:

Ryzen 9 5950X:
RPS ≈ 23056.899   22822.015   23006.543   ≈ 22962   ± 0.54%
TPS ≈ 22594.785   22292.071   22800.857   ≈ 22562   ± 1.13%
CPU ≈    24.262%     23.185%     25.921%  ≈    24.5 ± 5.65%
Mem ≈   614.254MB   613.204MB   555.491MB ≈   594   ± 5.66%

Core i7-8565U:
RPS ≈ 6378.702   6423.927   6363.788      ≈ 6389   ± 0.49%
TPS ≈ 6327.072   6372.552   6311.179      ≈ 6337   ± 0.50%
CPU ≈   57.599%    58.622%    59.737%     ≈   58.7 ± 1.82%
Mem ≈  198.697MB  188.746MB  200.235MB    ≈  196   ± 3.18%

DB restore:
real    0m13.576s 0m13.334s 0m12.757s  ≈  13.222 ±  3.18%
user    0m19.113s 0m19.490s 0m20.197s  ≈  19.600 ±  2.81%
sys      0m2.211s  0m1.558s  0m1.559s  ≈   1.776 ± 21.21%

On Ryzen 9 we've got 12% better RPS, 13% better TPS with 12% CPU and 3% RAM
more used. Core i7-8565U changes don't seem to be statistically significant:
1.8% more RPS, 1.6% more TPS with about the same CPU and 8.5% less RAM
used. It also is 1% worse in DB restore time.

The result is somewhat expected, on a powerful machine with lots of spare
cores we get 10%+ better results while on average resource-constrained laptop it
doesn't change much (the machine is already saturated). Overall, this seems to
be worthwhile.
2021-07-30 15:45:17 +03:00
.circleci circleci: fix image build with latest alpine 2021-07-07 20:21:52 +03:00
.docker core: rename Neo.Crypto.CheckMultisig interop 2021-05-11 18:38:14 +03:00
.github circleci/workflows: drop vet run 2021-05-13 00:08:42 +03:00
cli wallet: truncate file when writing 2021-07-29 17:11:49 +03:00
config config: update mainnet magic 2021-07-21 14:42:26 +03:00
docs Merge pull request #2093 from nspcc-dev/states-exchange/drop-nep17-balance-state 2021-07-29 19:08:42 +03:00
examples examples: add missing permission methods in manifests 2021-06-24 16:00:45 +03:00
internal core: implement dynamic NEP17 balances tracking 2021-07-29 10:23:01 +03:00
pkg core: spread storeBlock actions to three goroutines 2021-07-30 15:45:17 +03:00
scripts config: add InitialGASSupply, fix #2073 2021-07-20 16:59:54 +03:00
.dockerignore Fix build node and docker-image 2019-08-26 19:32:09 +03:00
.gitignore .gitignore: add compiler outputs in example dir 2021-04-06 22:50:42 +03:00
.gitmodules vm: update json tests to neo3 branch 2020-04-17 11:46:31 +03:00
.golangci.yml *: enable godot linter and fix all its warnings 2021-05-12 23:17:03 +03:00
.travis.yml drop support for Go 1.12 2020-08-06 16:29:55 +03:00
CHANGELOG.md CHANGELOG: release 0.96.1 2021-07-23 13:26:00 +03:00
CONTRIBUTING.md CONTRIBUTING: trivial fix 2021-07-23 18:15:43 +03:00
Dockerfile Dockerfile: use make to build neo-go 2021-05-13 17:16:27 +03:00
go.mod go.mod: update ishell package 2021-07-21 23:28:26 +03:00
go.sum go.mod: update ishell package 2021-07-21 23:28:26 +03:00
LICENSE.md LICENSE.md: rename from LICENCE.md 2019-08-20 18:47:08 +03:00
Makefile Makefile: drop vendoring 2021-05-13 17:22:10 +03:00
neo-go.service.template service file templating 2019-11-13 15:05:13 +03:00
README.md docs: add more info about running a CN node on public networks 2021-07-15 12:21:07 +03:00
ROADMAP.md CHANGELOG: release 0.96.0 2021-07-21 16:57:08 +03:00

logo

Go Node and SDK for the NEO blockchain.


codecov CircleCI GithubWorkflows Tests GithubWorkflows CodeQL Report GoDoc GitHub release (latest SemVer) License

Overview

This project aims to be a full port of the original C# Neo project. A complete toolkit for the NEO blockchain, including:

This branch (master) is under active development now (read: won't work out of the box) and aims to be compatible with Neo 3. For the current stable version compatible with Neo 2 please refer to the master-2.x branch and releases before 0.80.0 (0.7X.Y track). Releases starting from 0.90.0 contain Neo 3 code (0.90.0 being compatible with Neo 3 preview2).

Getting started

Installation

NeoGo is distributed as a single binary that includes all the functionality provided (but smart contract compiler requires Go compiler to operate). You can grab it from releases page, use a Docker image (see Docker Hub for various releases of NeoGo, :latest points to the latest release) or build yourself.

Building

To build NeoGo you need Go 1.14+ and make:

make build

The resulting binary is bin/neo-go.

Running a node

A node needs to connect to some network, either local one (usually referred to as privnet) or public (like mainnet or testnet). Network configuration is stored in a file and NeoGo allows you to store multiple files in one directory (./config by default) and easily switch between them using network flags.

To start Neo node on private network use:

./bin/neo-go node

Or specify a different network with appropriate flag like this:

./bin/neo-go node --mainnet

Available network flags:

  • --mainnet, -m
  • --privnet, -p
  • --testnet, -t

To run a consensus/committee node refer to consensus documentation.

Docker

By default the CMD is set to run a node on privnet, so to do this simply run:

docker run -d --name neo-go -p 20332:20332 -p 20331:20331 nspccdev/neo-go

Which will start a node on privnet and expose node's ports 20332 (P2P protocol) and 20331 (JSON-RPC server).

Importing mainnet/testnet dump files

If you want to jump-start your mainnet or testnet node with chain archives provided by NGD follow these instructions (when they'd be available for 3.0 networks):

$ wget .../chain.acc.zip # chain dump file
$ unzip chain.acc.zip
$ ./bin/neo-go db restore -m -i chain.acc # for testnet use '-t' flag instead of '-m'

The process differs from the C# node in that block importing is a separate mode, after it ends the node can be started normally.

Running a private network

Refer to consensus node documentation.

Smart contract development

Please refer to neo-go smart contract development workshop that shows some simple contracts that can be compiled/deployed/run using neo-go compiler, SDK and private network. For details on how Go code is translated to Neo VM bytecode and what you can and can not do in smart contract please refer to the compiler documentation.

Refer to examples for more NEO smart contract examples written in Go.

Wallets

NeoGo differs substantially from C# implementation in its approach to wallets. NeoGo wallet is just a NEP-6 file that is used by CLI commands to sign various things. There is no database behind it, the blockchain is the database and CLI commands use RPC to query data from it. At the same time it's not required to open the wallet on RPC node to perform various actions (unless your node is providing some service for the network like consensus or oracle nodes).

Developer notes

Nodes have such features as Prometheus and Pprof in order to have additional information about them for debugging.

How to configure Prometheus or Pprof: In config/protocol.*.yml there is

  Prometheus:
    Enabled: true
    Port: 2112

where you can switch on/off and define port. Prometheus is enabled and Pprof is disabled by default.

Contributing

Feel free to contribute to this project after reading the contributing guidelines.

Before starting to work on a certain topic, create an new issue first, describing the feature/topic you are going to implement.

Contact

License

  • Open-source MIT