d625cc9287
- Add new command to the cli/node: `serveapi` that alows serving the API just
by connecting to the PostgreSQL database. The mode flag should me passed in
order to select whether we are connecting to a synchronizer database or a
coordinator database. If `coord` is chosen as mode, the coordinator
endpoints can be activated in order to allow inserting l2txs and
authorizations into the L2DB.
Summary of the implementation details
- New SQL table with 3 columns (plus `item_id` pk). The table only contains a
single row with `item_id` = 1. Columns:
- state: historydb.StateAPI in JSON. This is the struct that is served via
the `/state` API endpoint. The node will periodically update this struct
and store it int he DB. The api server will query it from the DB to
serve it.
- config: historydb.NodeConfig in JSON. This struct contains node
configuration parameters that the API needs to be aware of. It's updated
once every time the node starts.
- constants: historydb.Constants in JSON. This struct contains all the
hermez network constants gathered via the ethereum client by the node.
It's written once every time the node starts.
- The HistoryDB contains methods to get and update each one of these columns
individually.
- The HistoryDB contains all methods that query the DB and prepare objects that
will appear in the StateAPI endpoint.
- The configuration used in for the `serveapi` cli/node command is defined in
`config.APIServer`, and is a subset of `node.Config` in order to allow
reusing the same configuration file of the node if desired.
- A new object is introduced in the api: `StateAPIUpdater`, which contains all
the necessary information to update the StateAPI in the DB periodically by
the node.
- Moved the types `SCConsts`, `SCVariables` and `SCVariablesPtr` from
`syncrhonizer` to `common` for convenience.
node cli
This is the main cli for the node
Go version
The hermez-node has been tested with go version 1.14
Usage
NAME:
hermez-node - A new cli application
USAGE:
node [global options] command [command options] [arguments...]
VERSION:
0.1.0-alpha
COMMANDS:
importkey Import ethereum private key
genbjj Generate a new BabyJubJub key
wipesql Wipe the SQL DB (HistoryDB and L2DB), leaving the DB in a clean state
run Run the hermez-node in the indicated mode
help, h Shows a list of commands or help for one command
GLOBAL OPTIONS:
--mode MODE Set node MODE (can be "sync" or "coord")
--cfg FILE Node configuration FILE
--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.
Configuration
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
Notes
- The private key corresponding to the parameter
Coordinator.ForgerAddressneeds to be imported in the ethereum keystore - The private key corresponding to the parameter
Coordinator.FeeAccount.Addressneeds to be imported in the ethereum keystore - The public key corresponding to the parameter
Coordinator.FeeAccount.BJJcan be generated with the commandgenbjj - There are two sets of debug parameters (
Debugfor all modes, andCoordinator.Debugforcoordmode). Some of these parameters may not be suitable for production. - The parameter
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. - The node requires a PostgreSQL database. The parameters of the server and
database must be set in the
PostgreSQLsection.
Building
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.
Usage Examples
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 --mode sync --cfg cfg.buidler.toml run
Run the node in mode coordinator:
./node --mode coord --cfg cfg.buidler.toml run
Import an ethereum private key into the keystore:
./node --mode coord --cfg cfg.buidler.toml importkey --privatekey 0x618b35096c477aab18b11a752be619f0023a539bb02dd6c813477a6211916cde
Generate a new BabyJubJub key pair:
./node --mode coord --cfg cfg.buidler.toml genbjj
Wipe the entier SQL database (this will destroy all synchronized and pool data):
./node --mode coord --cfg cfg.buidler.toml wipesql
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 --mode coord --cfg cfg.buidler.toml discard --block 8061330