dosnetwork/core

Core Protocols, Libraries and Off-chain Clients

DOS Client and Core Libraries

Prerequisites:

Cloud Server / VPS Recommendations

• AWS Lightsail - Linux virtual server (1 cpu, 1GB memory, 40GB ssd, 2TB bandwidth)
• Google Cloud Platform - Compute Engine General purpose (N2)
• Vultr - Cloud Compute (1 cpu, 1GB memory, 25GB ssd, 1TB bandwidth)
• Digital Ocean - Droplet (1 cpu, 25GB ssd, 1TB bandwidth)
• Linode - Shared virtual Instances (1 cpu, 1GB memory, 25GB ssd, 1TB bandwidth)
• [Others]

Verified and recommended installation environment

• Ubuntu 18.04 x64 LTS or higher
• An IPv4 address
  • Run $ dig +short myip.opendns.com @resolver1.opendns.com
  • Or get it from cloud server providers. Most vps / cloud server
• With below ports open:
  • udp port 7946
  • tcp port 7946,9501
• It's recommended to generate ssh login key pairs and setup public key authentication instead of using password login for server security and funds safety:
  • Learn how to setup SSH public key authentication on Ubuntu 18.04 and disable password logins.

Bonding enough DOS tokens to run a node

• Acquire at least 800,000 DOS tokens, (and optional - acquire several DropBurn token to reduce (up to 30%) the amount of DOS tokens needed to start a node, distribution plan be out later).
• Replace your node ip address in config.json
• Node runners currently earn three types of incomes: (Self-bonded) staking rewards, (other delegators') staking reward shares, oracle request processing fees.

Register and setup Infura api key

• Register and get Infura api key
• Replace your infura api key in config.json

Run with docker image

• https://medium.com/dos-network/instructions-of-launching-a-node-in-dos-network-932e73a91a75

Building binary from source

• Install go1.11 or higher and setup golang workingspace like below:

  $ sudo apt-get install golang 
  $ sudo apt-get install build-essential

• Open ~/.bashrc and set $GOPATH and $PATH environmental variables:

  $ vim ~/.bashrc
    export GOPATH=$HOME/go
    export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
  $ source ~/.bashrc

• Download source code:

  $ mkdir -p $GOPATH/src/github.com/DOSNetwork
  $ cd $GOPATH/src/github.com/DOSNetwork && git clone https://github.com/DOSNetwork/core.git
  $ cd core
  $ git checkout v1.0.4-m

• Build:

  • $ GO111MODULE=on go mod download - to download building dependencies
  • Dev dependencies: solc-v0.5.17, abigen-v1.9.18-stable
  • $ make - to build release version client

• Run:

  $ ./dos.sh start

• Dev tips:

  • $ go fmt ./... to reformat go source code.
  • $ golint to fix style mistakes conflicting with effective go. (golint tool for vim users.)
  • $ make devClient to build develoment version client.
  • $ make updateSubmodule to fetch latest system contracts from repo, instead of making contract modifications locally.
  • $ make gen to generate binding files for system contracts.
  • $ make clean to remove built binaries or unnecessary generated files.
  • Use solc-select tool to select / pin to specific solidity compiler version.

core's Issues

get external ip from multiple services

Client redial to ETH when contracts is upgraded

Client should gets proxy,commitReveal and payment address from DOSAddressBridge and listen ProxyAddressUpdated,CommitRevealAddressUpdated and PaymentAddressUpdated events to redial to eth proxy.

goland cannot compile code

v1.0.0-m branch
config_test.go file:

test

Add a CLI command to create a new node address

Add a CLI command to create a new node address and generate a password protected keystore in credential directory.

Errors will happen when upgrading the library

(The purpose of this report is to alert DOSNetwork/core to the possible problems when DOSNetwork/core try to upgrade the following dependencies)

An error will happen when upgrading library urfave/cli:

github.com/urfave/cli

-Latest Version: v2.2.0 (Latest commit d648edd on 6 Mar)
-Where did you use it:
https://github.com/DOSNetwork/core/search?q=urfave%2Fcli&unscoped_q=urfave%2Fcli
-Detail:

github.com/urfave/cli/go.mod

module github.com/urfave/cli/v2
go 1.11
require (
	github.com/BurntSushi/toml v0.3.1
	github.com/cpuguy83/go-md2man/v2 v2.0.0-20190314233015-f79a8a8ca69d	
	…
)

github.com/urfave/cli/docs.go

package cli
import (
	"github.com/cpuguy83/go-md2man/v2/md2man"
)

This problem was introduced since urfave/cli v1.22.1 . . Now you used the version v1.20.0. If you try to upgrade urfave/cli to version v1.22.1 and above, you will get an error--- no package exists at "github.com/cpuguy83/go-md2man/v2/md2man"

I investigated the libraries' (urfave/cli >= v1.22.1) release information and found the root cause of this issue is that----

1. These dependencies all added Go modules in the recent versions.

2. They all comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:

A package that has migrated to Go Modules must include the major version in the import path to reference any v2+ modules. For example, Repo github.com/my/module migrated to Modules on version v3.x.y. Then this repo should declare its module path with MAJOR version suffix "/v3" (e.g., module github.com/my/module/v3), and its downstream project should use "github.com/my/module/v3/mypkg" to import this repo’s package.

3. This "github.com/my/module/v3/mypkg" is not the physical path. So earlier versions of Go (including those that don't have minimal module awareness) plus all tooling (like dep, glide, govendor, etc) don't have minimal module awareness as of now and therefore don't handle import paths correctly.

Note: creating a new branch is not required. If instead you have been previously releasing on master and would prefer to tag v3.0.0 on master, that is a viable option. (However, be aware that introducing an incompatible API change in master can cause issues for non-modules users who issue a go get -u given the go tool is not aware of semver prior to Go 1.11 or when module mode is not enabled in Go 1.11+).
Pre-existing dependency management solutions such as dep currently can have problems consuming a v2+ module created in this way. See for example dep#1962.
https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Solution

1. Migrate to Go Modules.

Go Modules is the general trend of ecosystem, if you want a better upgrade package experience, migrating to Go Modules is a good choice.

Migrate to modules will be accompanied by the introduction of virtual paths(It was discussed above).

This "github.com/my/module/v3/mypkg" is not the physical path. So Go versions older than 1.9.7 and 1.10.3 plus all third-party dependency management tools (like dep, glide, govendor, etc) don't have minimal module awareness as of now and therefore don't handle import paths correctly.

Then the downstream projects might be negatively affected in their building if they are module-unaware (Go versions older than 1.9.7 and 1.10.3; Or use third-party dependency management tools, such as: Dep, glide, govendor…).

2. Maintaining v2+ libraries that use Go Modules in Vendor directories.

If DOSNetwork/core want to keep using the dependency manage tools (like dep, glide, govendor, etc), and still want to upgrade the dependencies, can choose this fix strategy.
Manually download the dependencies into the vendor directory and do compatibility dispose(materialize the virtual path or delete the virtual part of the path). Avoid fetching the dependencies by virtual import paths. This may add some maintenance overhead compared to using modules.

As the import paths have different meanings between the projects adopting module repos and the non-module repos, materialize the virtual path is a better way to solve the issue, while ensuring compatibility with downstream module users. A textbook example provided by repo github.com/moby/moby is here:
https://github.com/moby/moby/blob/master/VENDORING.md
https://github.com/moby/moby/blob/master/vendor.conf
In the vendor directory, github.com/moby/moby adds the /vN subdirectory in the corresponding dependencies.
This will help more downstream module users to work well with your package.

3. Request upstream to do compatibility processing.

The urfave/cli have 1694 module-unaware users in github, such as: alena1108/cluster-controller, nathan-jenan-rancher/example-kontainer-engine-driver, containerd/containerd…
https://github.com/search?q=urfave%2Fcli+filename%3Avendor.conf+filename%3Avendor.json+filename%3Aglide.toml+filename%3AGodep.toml+filename%3AGodep.json

Summary

You can make a choice when you meet this DM issues by balancing your own development schedules/mode against the affects on the downstream projects.

For this issue, Solution 1 can maximize your benefits and with minimal impacts to your downstream projects the ecosystem.

References

• https://github.com/golang/go/wiki/Modules#semantic-import-versioning
• https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning
• https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Do you plan to upgrade the libraries in near future?
Hope this issue report can help you ^_^
Thank you very much for your attention.

Best regards,
Kate

Extract contracts into another repo and trufflize it before open-source contracts in alpha

• Extract contracts
• Reference contracts repo in core/
• Trufflize contracts repo
• Tag alpha and open source
• More tests and continuous integration