Merge pull request #653 from hermeznetwork/feature/goreleaser-integration

Generating automatically releases with Goreleaser

.github/workflows/release.yml

@@ -0,0 +1,29 @@
+name: goreleaser
+
+on:
+  push:
+    tags:
+      - '*'
+
+jobs:
+  goreleaser:
+    runs-on: ubuntu-latest
+    steps:
+      -
+        name: Checkout
+        uses: actions/checkout@v2
+        with:
+          fetch-depth: 0
+      -
+        name: Set up Go
+        uses: actions/setup-go@v2
+        with:
+          go-version: 1.16
+      -
+        name: Run GoReleaser
+        uses: goreleaser/goreleaser-action@v2
+        with:
+          version: latest
+          args: release --rm-dist
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.goreleaser.yml

@@ -0,0 +1,36 @@
+before:
+  hooks:
+    - go mod download
+
+builds:
+  - main: ./cli/node/main.go
+    binary: node
+    id: node
+    goos:
+      - linux
+      - darwin
+      - windows
+    hooks:
+      pre: make migration-pack
+      post: make migration-clean
+
+archives:
+  - replacements:
+      darwin: Darwin
+      linux: Linux
+      windows: Windows
+      386: i386
+      amd64: x86_64
+
+checksum:
+  name_template: 'checksums.txt'
+
+snapshot:
+  name_template: "{{ .Tag }}-next"
+
+changelog:
+  sort: asc
+  filters:
+    exclude:
+      - '^docs:'
+      - '^test:'

Makefile

@@ -3,8 +3,8 @@
 # Project variables.
 PACKAGE := github.com/hermeznetwork/hermez-node
 VERSION := $(shell git describe --tags --always)
-BUILD := $(shell git rev-parse --short HEAD)
-BUILD_DATE := $(shell date +%Y-%m-%dT%H:%M:%S%z)
+COMMIT := $(shell git rev-parse --short HEAD)
+DATE := $(shell date +%Y-%m-%dT%H:%M:%S%z)
 PROJECT_NAME := $(shell basename "$(PWD)")
 
 # Go related variables.
@@ -23,7 +23,7 @@ CONFIG ?= $(GOBASE)/cli/node/cfg.buidler.toml
 POSTGRES_PASS ?= yourpasswordhere
 
 # Use linker flags to provide version/build settings.
-LDFLAGS=-ldflags "-X=main.Version=$(VERSION) -X=main.Build=$(BUILD) -X=main.Date=$(BUILD_DATE)"
+LDFLAGS=-ldflags "-X main.version=$(VERSION) -X main.commit=$(COMMIT) -X main.date=$(DATE)"
 
 # PID file will keep the process id of the server.
 PID_PROOF_MOCK := /tmp/.$(PROJECT_NAME).proof.pid
@@ -94,11 +94,11 @@ install:
 	@echo "  >  Checking if there is any missing dependencies..."
 	$(GOENVVARS) go get $(GOCMD)/... $(get)
 
-## run: Run Hermez node.
-run:
+## run-node: Run Hermez node.
+run-node:
 	@bash -c "$(MAKE) clean build"
 	@echo "  >  Running $(PROJECT_NAME)"
-	@$(GOBIN)/$(GOBINARY) --mode $(MODE) --cfg $(CONFIG) run
+	@$(GOBIN)/$(GOBINARY) run --mode $(MODE) --cfg $(CONFIG)
 
 ## run-proof-mock: Run proof server mock API.
 run-proof-mock: stop-proof-mock

README.md

@@ -25,13 +25,13 @@ there are more information about the config file into [cli/node/README.md](cli/n
 After setting the config, you can build and run the Hermez Node as a synchronizer:
 
 ```shell
-$ make run
+$ make run-node
 ```
 
 Or build and run as a coordinator, and also passing the config file from other location:
 
 ```shell
-$ MODE=sync CONFIG=cli/node/cfg.buidler.toml make run
+$ MODE=sync CONFIG=cli/node/cfg.buidler.toml make run-node
 ```
 
 To check the useful make commands:

cli/node/README.md

@@ -73,6 +73,9 @@ of the node configuration.  Please, check the `type APIServer` at
   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 `PostgreSQL` section.
+- The node requires a web3 RPC server to work.  The node has only been tested
+  with geth and may not work correctly with other ethereum nodes
+  implementations.
 
 ## Building
 

cli/node/main.go

@@ -35,18 +35,18 @@ const (
 )
 
 var (
-	// Version represents the program based on the git tag
-	Version = "v0.1.0"
-	// Build represents the program based on the git commit
-	Build = "dev"
-	// Date represents the date of application was built
-	Date = ""
+	// version represents the program based on the git tag
+	version = "v0.1.0"
+	// commit represents the program based on the git commit
+	commit = "dev"
+	// date represents the date of application was built
+	date = ""
 )
 
 func cmdVersion(c *cli.Context) error {
-	fmt.Printf("Version = \"%v\"\n", Version)
-	fmt.Printf("Build = \"%v\"\n", Build)
-	fmt.Printf("Date = \"%v\"\n", Date)
+	fmt.Printf("Version = \"%v\"\n", version)
+	fmt.Printf("Build = \"%v\"\n", commit)
+	fmt.Printf("Date = \"%v\"\n", date)
 	return nil
 }
 
@@ -421,7 +421,7 @@ func getConfigAPIServer(c *cli.Context) (*ConfigAPIServer, error) {
 func main() {
 	app := cli.NewApp()
 	app.Name = "hermez-node"
-	app.Version = Version
+	app.Version = version
 	flags := []cli.Flag{
 		&cli.StringFlag{
 			Name:     flagMode,

config/config.go

@@ -299,7 +299,8 @@ type Node struct {
 	} `validate:"required"`
 	PostgreSQL PostgreSQL `validate:"required"`
 	Web3       struct {
-		// URL is the URL of the web3 ethereum-node RPC server
+		// URL is the URL of the web3 ethereum-node RPC server.  Only
+		// geth is officially supported.
 		URL string `validate:"required"`
 	} `validate:"required"`
 	Synchronizer struct {

coordinator/coordinator.go

@@ -1,3 +1,43 @@
+/*
+Package coordinator handles all the logic related to forging batches as a
+coordinator in the hermez network.
+
+The forging of batches is done with a pipeline in order to allow multiple
+batches being forged in parallel.  The maximum number of batches that can be
+forged in parallel is determined by the number of available proof servers.
+
+The Coordinator begins with the pipeline stopped.  The main Coordinator
+goroutine keeps listening for synchronizer events sent by the node package,
+which allow the coordinator to determine if the configured forger address is
+allowed to forge at the current block or not.  When the forger address becomes
+allowed to forge, the pipeline is started, and when it terminates being allowed
+to forge, the pipeline is stopped.
+
+The Pipeline consists of two goroutines.  The first one is in charge of
+preparing a batch internally, which involves making a selection of transactions
+and calculating the ZKInputs for the batch proof, and sending these ZKInputs to
+an idle proof server.  This goroutine will keep preparing batches while there
+are idle proof servers, if the forging policy determines that a batch should be
+forged in the current state.  The second goroutine is in charge of waiting for
+the proof server to finish computing the proof, retreiving it, prepare the
+arguments for the `forgeBatch` Rollup transaction, and sending the result to
+the TxManager.  All the batch information moves between functions and
+goroutines via the BatchInfo struct.
+
+Finally, the TxManager contains a single goroutine that makes forgeBatch
+ethereum transactions for the batches sent by the Pipeline, and keeps them in a
+list to check them periodically.  In the periodic checks, the ethereum
+transaction is checked for successfulness, and it's only forgotten after a
+number of confirmation blocks have passed after being successfully mined.  At
+any point if a transaction failure is detected, the TxManager can signal the
+Coordinator to reset the Pipeline in order to reforge the failed batches.
+
+The Coordinator goroutine acts as a manager.  The synchronizer events (which
+notify about new blocks and associated new state) that it receives are
+broadcasted to the Pipeline and the TxManager.  This allows the Coordinator,
+Pipeline and TxManager to have a copy of the current hermez network state
+required to perform their duties.
+*/
 package coordinator
 
 import (

node/node.go

@@ -1,3 +1,18 @@
+/*
+Package node does the initialization of all the required objects to either run
+as a synchronizer or as a coordinator.
+
+The Node contains several goroutines that run in the background or that
+periodically perform tasks.  One of this goroutines periodically calls the
+`Synchronizer.Sync` function, allowing the synchronization of one block at a
+time.  After every call to `Synchronizer.Sync`, the Node sends a message to the
+Coordinator to notify it about the new synced block (and associated state) or
+reorg (and resetted state) in case one happens.
+
+Other goroutines perform tasks such as: updating the token prices, update
+metrics stored in the historyDB, update recommended fee stored in the
+historyDB, run the http API server, run the debug http API server, etc.
+*/
 package node
 
 import (

synchronizer/synchronizer.go

@@ -1,3 +1,35 @@
+/*
+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).
+
+The main entry point for synchronization is the `Sync` function, which at most
+will synchronize one ethereum block, and all the hermez events that happened in
+that block.  During a `Sync` call, a reorg can be detected; in such case, uncle
+blocks will be discarded, and only in a future `Sync` call correct blocks will
+be synced.
+
+The synchronization of the events in each smart contracts are done
+in the methods `rollupSync`, `auctionSync` and `wdelayerSync`, which in turn
+use the interface code to read each smart contract state and events found in
+"github.com/hermeznetwork/hermez-node/eth".  After these three methods are
+called, an object of type `common.BlockData` is built containing all the
+updates and events that happened in that block, and it is inserted in the
+HistoryDB in a single SQL transaction.
+
+`rollupSync` is the method that synchronizes batches sent via the `forgeBatch`
+transaction in `Hermez.sol`.  In `rollupSync`, for every batch,  the accounts
+state is updated in the StateDB by processing all transactions that have been
+forged in that batch.
+
+The consistency of the stored data is guaranteed by the HistoryDB: All the
+block information is inserted in a single SQL transaction at the end of the
+`Sync` method, once the StateDB has been updated.  And every time the
+Synchronizer starts, it continues from the last block in the HistoryDB.  The
+StateDB stores updates organized by checkpoints for every batch, and each batch
+is only accessed if it appears in the HistoryDB.
+*/
 package synchronizer
 
 import (