1# node cli
  2
  3This is the main cli for the node
  4
  5## Go version
  6
  7The `hermez-node` has been tested with go version 1.14
  8
  9## Usage
 10
 11```shell
 12NAME:
 13   hermez-node - A new cli application
 14
 15USAGE:
 16   node [global options] command [command options] [arguments...]
 17
 18VERSION:
 19   v0.1.0-6-gd8a50c5
 20
 21COMMANDS:
 22   version    Show the application version
 23   importkey  Import ethereum private key
 24   genbjj     Generate a new BabyJubJub key
 25   wipesql    Wipe the SQL DB (HistoryDB and L2DB) and the StateDBs, leaving the DB in a clean state
 26   run        Run the hermez-node in the indicated mode
 27   serveapi   Serve the API only
 28   discard    Discard blocks up to a specified block number
 29   help, h    Shows a list of commands or help for one command
 30
 31GLOBAL OPTIONS:
 32   --help, -h     show help (default: false)
 33   --version, -v  print the version (default: false)
 34```
 35
 36The node has two main modes of running:
 37- `sync`: Synchronizer mode.  In this mode the node will only synchronize the
 38  state of the hermez smart contracts, mainly processing the transactions in
 39  the batches.
 40- `coord`: Coordinator mode.  In this mode, apart from doing all the
 41  synchronization work, the node will also act as a coordinator, accepting L2
 42  transactions in the pool, and trying to forge batches when the proper
 43  conditions arise.
 44
 45## Configuration
 46
 47The node requires a single configuration file to run.
 48
 49You can find a testing working configuration example at
 50[cfg.buidler.toml](./cfg.buidler.toml)
 51
 52To read the documentation of each configuration parameter, please check the
 53`type Node` and `type Coordinator` at
 54[config/config.go](../../config/config.go).  All the sections that are prefixed
 55with `Coordinator` are only used in coord mode, and don't need to be defined
 56when running the coordinator in sync mode
 57
 58When running the API in standalone mode, the required configuration is a subset
 59of the node configuration.  Please, check the `type APIServer` at
 60[config/config.go](../../config/config.go) to learn about all the parametes.
 61
 62### Notes
 63
 64- The private key corresponding to the parameter `Coordinator.ForgerAddress` needs to be imported in the ethereum keystore
 65- The private key corresponding to the parameter `Coordinator.FeeAccount.Address` needs to be imported in the ethereum keystore
 66- The public key corresponding to the parameter `Coordinator.FeeAccount.BJJ` can be generated with the command `genbjj`
 67- There are two sets of debug parameters (`Debug` for all modes, and
 68  `Coordinator.Debug` for `coord` mode).  Some of these parameters may not be
 69  suitable for production.
 70- The parameter `Coordinator.Debug.BatchPath`, when set, causes the coordinator
 71  to store dumps of a lot of information related to batches in json files.
 72  This files can be around 2MB big.  If this parameter is set, be careful to
 73  monitor the size of the folder to avoid running out of space.
 74- The node requires a PostgreSQL database.  The parameters of the server and
 75  database must be set in the `PostgreSQL` section.
 76
 77## Building
 78
 79*All commands assume you are at the `cli/node` directory.*
 80
 81Building the node requires using the packr utility to bundle the database
 82migrations inside the resulting binary.  Install the packr utility with:
 83```shell
 84cd /tmp && go get -u github.com/gobuffalo/packr/v2/packr2 && cd -
 85```
 86
 87Make sure your `$PATH` contains `$GOPATH/bin`, otherwise the packr utility will
 88not be found.
 89
 90Now build the node executable:
 91```shell
 92cd ../../db && packr2 && cd -
 93go build .
 94cd ../../db && packr2 clean && cd -
 95```
 96
 97The executable is `node`.
 98
 99## Usage Examples
100
101The following commands assume you have built the node previously.  You can also
102run the following examples by replacing `./node` with `go run .` and executing
103them in the `cli/node` directory to build from source and run at the same time.
104
105Run the node in mode synchronizer:
106```shell
107./node run --mode sync --cfg cfg.buidler.toml
108```
109
110Run the node in mode coordinator:
111```shell
112./node run --mode coord --cfg cfg.buidler.toml
113```
114
115Serve the API in standalone mode.  This command allows serving the API just
116with access to the PostgreSQL database that a node is using.  Several instances
117of `serveapi` can be running at the same time with a single PostgreSQL
118database:
119```shell
120./node serveapi --mode coord --cfg cfg.buidler.toml
121```
122
123Import an ethereum private key into the keystore:
124```shell
125./node importkey --mode coord --cfg cfg.buidler.toml --privatekey  0x618b35096c477aab18b11a752be619f0023a539bb02dd6c813477a6211916cde
126```
127
128Generate a new BabyJubJub key pair:
129```shell
130./node genbjj
131```
132
133Check the binary version:
134```shell
135./node version
136```
137
138Wipe the entier SQL database (this will destroy all synchronized and pool
139data):
140```shell
141./node wipesql --mode coord --cfg cfg.buidler.toml 
142```
143
144Discard all synchronized blocks and associated state up to a given block
145number.  This command is useful in case the synchronizer reaches an invalid
146state and you want to roll back a few blocks and try again (maybe with some
147fixes in the code).
148```shell
149./node discard --mode coord --cfg cfg.buidler.toml --block 8061330
150```