README
¶
hermez-node 
Go implementation of the Hermez node.
Developing
To contribute to this codebase you must follow the branch model and development flow.
Go version
The hermez-node has been tested with go version 1.14
Build
- Build the binary in the local environment for you current OS and check the current version:
$ make
$ ./dist/heznode version
- Build the binary in a docker container for all supported OS and check the current version (only docker needed):
$ make docker-build
$ ./dist/heznode_<LOCAL_OS>_amd64/heznode version
- Build the binary in the local environment for all supported OS using Goreleaser and check the current version:
$ make goreleaser
$ ./dist/heznode_<LOCAL_OS>_amd64/heznode version
Run
First you must edit the default/template config file into cmd/heznode/cfg.buidler.toml, there are more information about the config file into cmd/heznode/README.md
After setting the config, you can build and run the Hermez Node as a synchronizer:
$ make run-node
Or build and run as a coordinator, and also passing the config file from other location:
$ MODE=sync CONFIG=cmd/heznode/cfg.builder.toml make run-node
To check the useful make commands:
$ make help
Run as a service
$ sudo make install
After, update the config file manually at /etc/hermez/config.toml
$ sudo service heznode start
To check status
$ sudo service heznode status
To stop
$ sudo service heznode stop
If you just kill the process systemd will restart without asking.
Unit testing
Running the unit tests requires a connection to a PostgreSQL database. You can run PostgreSQL with docker easily this way:
$ make run-database-container
Afterward, run the tests:
$ make test
There is an extra temporary option that allows you to run the API server using the Go tests. It will be removed once the API can be properly initialized with data from the synchronizer. To use this, run:
$ make test-api-server
It is also possible to run the tests with an existing PostgreSQL server, e.g.
$ PGHOST=someserver PGUSER=hermez2 PGPASSWORD=secret make test
Lint
All Pull Requests need to pass the configured linter.
To run the linter locally, first, install golangci-lint.
Afterward, you can check the lints with this command:
$ make gocilint
Usage
Node
Proof Server
The node in mode coordinator requires a proof server (a server capable of
calculating proofs from the zkInputs). There is a mock proof server CLI
at test/proofserver/cmd for testing purposes.
Usage of test/proofserver/cmd:
USAGE:
go run ./test/proofserver/cmd OPTIONS
OPTIONS:
-a string
listen address (default "localhost:3000")
-d duration
proving time duration (default 2s)
Also, the Makefile commands can be used to run and stop the proof server in the background:
$ make run-proof-mock
$ make stop-proof-mock
/tmp as tmpfs
For every processed batch, the node builds a temporary exit tree in a key-value
DB stored in /tmp. It is highly recommended that /tmp is mounted as a RAM
file system in production to avoid unnecessary reads a writes to disk. This
can be done by mounting /tmp as tmpfs; for example, by having this line in
/etc/fstab:
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
Directories
¶
| Path | Synopsis |
|---|---|
|
Package api implements the public interface of the hermez-node using a HTTP REST API.
|
Package api implements the public interface of the hermez-node using a HTTP REST API. |
|
coordinatornetwork
Package coordinatornetwork implements a comunication layer among coordinators in order to share information such as transactions in the pool and create account authorizations.
|
Package coordinatornetwork implements a comunication layer among coordinators in order to share information such as transactions in the pool and create account authorizations. |
|
stateapiupdater
Package stateapiupdater is responsible for generating and storing the object response of the GET /state endpoint exposed through the api package.
|
Package stateapiupdater is responsible for generating and storing the object response of the GET /state endpoint exposed through the api package. |
|
cmd
|
|
|
Package common float40.go provides methods to work with Hermez custom half float precision, 40 bits, codification internally called Float40 has been adopted to encode large integers.
|
Package common float40.go provides methods to work with Hermez custom half float precision, 40 bits, codification internally called Float40 has been adopted to encode large integers. |
|
apitypes
Package apitypes is used to map the common types used across the node with the format expected by the API.
|
Package apitypes is used to map the common types used across the node with the format expected by the API. |
|
Package coordinator handles all the logic related to forging batches as a coordinator in the hermez network.
|
Package coordinator handles all the logic related to forging batches as a coordinator in the hermez network. |
|
Package db have some common utilities shared by db/l2db and db/historydb, the most relevant ones are: - SQL connection utilities - Managing the SQL schema: this is done using migration files placed under db/migrations.
|
Package db have some common utilities shared by db/l2db and db/historydb, the most relevant ones are: - SQL connection utilities - Managing the SQL schema: this is done using migration files placed under db/migrations. |
|
historydb
Package historydb is responsible for storing and retrieving the historic data of the Hermez network.
|
Package historydb is responsible for storing and retrieving the historic data of the Hermez network. |
|
kvdb
Package kvdb provides a key-value database with Checkpoints & Resets system
|
Package kvdb provides a key-value database with Checkpoints & Resets system |
|
l2db
Package l2db is responsible for storing and retrieving the data received by the coordinator through the api.
|
Package l2db is responsible for storing and retrieving the data received by the coordinator through the api. |
|
health
|
|
|
Package node does the initialization of all the required objects to either run as a synchronizer or as a coordinator.
|
Package node does the initialization of all the required objects to either run as a synchronizer or as a coordinator. |
|
Package synchronizer synchronizes the hermez network state by querying events emitted by the three smart contracts: `Hermez.sol` (referred as Rollup here), `HermezAuctionProtocol.sol` (referred as Auction here) and `WithdrawalDelayer.sol` (referred as WDelayer here).
|
Package synchronizer synchronizes the hermez network state by querying events emitted by the three smart contracts: `Hermez.sol` (referred as Rollup here), `HermezAuctionProtocol.sol` (referred as Auction here) and `WithdrawalDelayer.sol` (referred as WDelayer here). |
|
txsets
Package txsets contains Til sets of transactions & Transactions generation that are used at tests of other packages of hermez-node
|
Package txsets contains Til sets of transactions & Transactions generation that are used at tests of other packages of hermez-node |
|
Package txprocessor is the module that takes the transactions from the input and processes them, updating the Balances and Nonces of the Accounts in the StateDB.
|
Package txprocessor is the module that takes the transactions from the input and processes them, updating the Balances and Nonces of the Accounts in the StateDB. |
|
Package txselector is responsible to choose the transactions from the pool that will be forged in the next batch.
|
Package txselector is responsible to choose the transactions from the pool that will be forged in the next batch. |