arnaubennassar 90126a03a2 | 3 years ago | |
---|---|---|
.. | ||
.gitignore | 3 years ago | |
README.md | 3 years ago | |
cfg.api.toml | 3 years ago | |
cfg.buidler.toml | 3 years ago | |
load-sk-example.sh | 4 years ago | |
main.go | 3 years ago |
This is the main cli for the node
The hermez-node
has been tested with go version 1.14
NAME:
hermez-node - A new cli application
USAGE:
node [global options] command [command options] [arguments...]
VERSION:
v0.1.0-6-gd8a50c5
COMMANDS:
version Show the application version
importkey Import ethereum private key
genbjj Generate a new BabyJubJub key
wipesql Wipe the SQL DB (HistoryDB and L2DB) and the StateDBs, leaving the DB in a clean state
run Run the hermez-node in the indicated mode
discard Discard blocks up to a specified block number
help, h Shows a list of commands or help for one command
GLOBAL OPTIONS:
--help, -h show help (default: false)
--version, -v print the version (default: false)
The node has two main modes of running:
sync
: Synchronizer mode. In this mode the node will only synchronize the
state of the hermez smart contracts, mainly processing the transactions in
the batches.coord
: Coordinator mode. In this mode, apart from doing all the
synchronization work, the node will also act as a coordinator, accepting L2
transactions in the pool, and trying to forge batches when the proper
conditions arise.The node requires a single configuration file to run.
You can find a testing working configuration example at cfg.buidler.toml
To read the documentation of each configuration parameter, please check the
type Node
and type Coordinator
at
config/config.go. All the sections that are prefixed
with Coordinator
are only used in coord mode, and don't need to be defined
when running the coordinator in sync mode
Coordinator.ForgerAddress
needs to be imported in the ethereum keystoreCoordinator.FeeAccount.Address
needs to be imported in the ethereum keystoreCoordinator.FeeAccount.BJJ
can be generated with the command genbjj
Debug
for all modes, and
Coordinator.Debug
for coord
mode). Some of these parameters may not be
suitable for production.Coordinator.Debug.BatchPath
, when set, causes the coordinator
to store dumps of a lot of information related to batches in json files.
This files can be around 2MB big. If this parameter is set, be careful to
monitor the size of the folder to avoid running out of space.PostgreSQL
section.All commands assume you are at the cli/node
directory.
Building the node requires using the packr utility to bundle the database migrations inside the resulting binary. Install the packr utility with:
cd /tmp && go get -u github.com/gobuffalo/packr/v2/packr2 && cd -
Make sure your $PATH
contains $GOPATH/bin
, otherwise the packr utility will
not be found.
Now build the node executable:
cd ../../db && packr2 && cd -
go build .
cd ../../db && packr2 clean && cd -
The executable is node
.
The following commands assume you have built the node previously. You can also
run the following examples by replacing ./node
with go run .
and executing
them in the cli/node
directory to build from source and run at the same time.
Run the node in mode synchronizer:
./node run --mode sync --cfg cfg.buidler.toml
Run the node in mode coordinator:
./node run --mode coord --cfg cfg.buidler.toml
Import an ethereum private key into the keystore:
./node importkey --mode coord --cfg cfg.buidler.toml --privatekey 0x618b35096c477aab18b11a752be619f0023a539bb02dd6c813477a6211916cde
Generate a new BabyJubJub key pair:
./node genbjj
Check the binary version:
./node version
Wipe the entier SQL database (this will destroy all synchronized and pool data):
./node wipesql --mode coord --cfg cfg.buidler.toml
Discard all synchronized blocks and associated state up to a given block number. This command is useful in case the synchronizer reaches an invalid state and you want to roll back a few blocks and try again (maybe with some fixes in the code).
./node discard --mode coord --cfg cfg.buidler.toml --block 8061330