Skip to content

Home

Jump to bottom
Brian Woods edited this page Nov 5, 2018 · 39 revisions

Table of contents

Welcome to disgo!

Boogie down with Dispatch Labs as we build disgo, the initial Golang implementation of the Dispatch protocol. If you're a developer interested in submitting pull requests, let's party like it's 1975.

Overview

The best place to begin with understanding Dispatch is the whitepaper, but we'll give some cliffs notes here. The Dispatch protocol is built with 3 core principals in mind:

  • Dispatch is scalable.

    Using our own DAPoS consensus, we can achieve high transaction throughput, with no transaction fees

  • Dispatch is backwards-compatible with Ethereum smart-contracts and the EVM.

    By using a modified version of the EVM, Dispatch the Dispatch protocol is compatible with most Dapps currently under development

  • Dispatch handles lots data.

    Most business logic involves data too big to fit in a shared ledger. We extend the functionality of Ethereum smart-contracts to support accessing big off-chain data we call artifacts

Development

Disgo is still in Testnet Alpha development. We are an open-source project and encourage community contribution! We're excited to talk to developers and will happily help curious engineers get aquatinted with the code base. Curious minds are encouraged to email us at devs@dispatchlabs.io.

If you're not a developer, but still want to follow along, check out our development blog for weekly updates.

API

The Disgo API is organized around REST. To learn more about our API check out our API Reference.

Modules

The disgo repository is composed of several smaller "building block" modules. The goal is to create usable components of common blockchain architectures, so future blockchain projects don't have to start from scratch.

Commons

Commons contains the common code that multiple components depend on. All projects in the repository depend on Commons.

DisGover

DisGover is our node discovery module. Built using libp2p, disgovery should solve the distributed system bootstrapping problem of finding other nodes in the network. Eventually, we'll expand on this module to support the discovery of non-node entities, like artifacts.

DAPoS

The Dispatch protocol is built using a novel Delegated Asynchronous Proof-of-Stake consensus algorithm called DAPoS. The dapos repo is the modular implementation of the consensus implemented in Go.

DVM

The DVM(Dispatch Virtual Machine) handles our state and transaction execution. It is backwards compatible with the EVM(Ethereum Virtual Machine). This is where our smart contracts live.

Design Approach

One of the most important decisions is to ensure that the system is simple to develop on and flexible enough to change direction or have multiple options for the different components of the system.

The approach to accomplishing this was to use builder patterns to specify things like: the protocol to use for communication in the system or which algorithm to use for particular operations.

The individual components of the overall system are "pluggable". The intent is to make it possible to use these components individually, or pick and choose which ones to use, and avoid monolithic code.

Getting Started with Disgo

Disgo is the Dispatch Node

Run this code to be part of the best business enabling, open-source chain on the planet. Period.

Run

  • Install Go for your platform. The 1-2-3 steps are here

Dev Box

-go get github.com/dispatchlabs/disgo
-cd ~/go/src/github.com/dispatchlabs/disgo
-go run main.go

As Service with Docker
$ docker-compose build
$ docker-compose up -d

View log output:

$ docker logs --tail=400 disgo-service

As A Stand-Alone Service
  • go get github.com/dispatchlabs/disgo
  • cd $GOPATH/src/github.com/dispatchlabs/disgo
  • go build
  • sudo mkdir /go-binaries
  • sudo mv ./disgo /go-binaries/
  • sudo cp -r ./config /go-binaries/
  • sudo nano /etc/systemd/system/dispatch-disgo-node.service
[Unit]
Description=Dispatch Disgo Node
After=network.target

[Service]
WorkingDirectory=/go-binaries
ExecStart=/go-binaries/disgo -asSeed -nodeId=NODE-Seed-001 -thisIp=35.227.162.40
Restart=on-failure

User=dispatch-services
Group=dispatch-services

[Install]
WantedBy=multi-user.target
  • sudo useradd dispatch-services -s /sbin/nologin -M
  • sudo systemctl enable dispatch-disgo-node
  • sudo systemctl start dispatch-disgo-node
  • sudo journalctl -f -u dispatch-disgo-node
  • sudo systemctl daemon-reload if you change the service

Develop

protoc (used for gRPC bindings in Disgover & DAPoS)
  • Install protoc compiler manually or by homebrew
  • $ brew install protobuf
  • Install protoc-gen-go plugin:
  • go get -u github.com/golang/protobuf/protoc-gen-go
  • Build Go bindings from .proto file.
For Disgover component:  
  $ cd dispatchlabs/disgover
  $ protoc --go_out=plugins=grpc:. proto/disgover.proto

For DAPoS component:  
  $ cd dispatchlabs/dapos
  $ protoc --go_out=plugins=grpc:. proto/dapos.proto

Development tools

VS Code

  • mkdir .vscode
  • cp helpers-files/vscode-launch.json .vscode/launch.json

Migrating a Disgo Node to become a Delegate

First, this is section is only for the Alpha release as the Election cycle for Delegates has not yet been completed. (Testnet 2.0 has set delegates, this will not effect that)

  • Setup a Disgo Node - see Setting up a the Disgo Node above

  • If you are updating your previous Node, please remove config/config.json and save your changes. A new config/config.json will be generated and then you will be able to put your changes back in.

  • In this section of the JSON

  • "IsDelegate": false - Set this to "true"

  • "DaposDelegates": [ "test-net-delegate-1", "test-net-delegate-2", "test-net-delegate-3", "test-net-delegate-4" ], - This is for reference `

  • "NodeId": "" - Set your NodeId to a unique name. Do NOT use a name from the DaposDelegates list above

  • Restart your node. It's now a Delegate

Packages

Base Disgo Package

The base package only contains main.go to start the Disgo node.

Core Package

The core package has the base startup functionality for the disgo node. It provides the code to start the services and register the transport protocols to use. It also defines which HTTP endpoints to expose at runtime along with the HTTP handlers that have the communication and request/response logic.

  • server.go is the entry point to starting the node. It includes all of the configuration setup registering services and startup of services to listen for requests. The server is started by calling the NewServer function which provides a handle to the server. View the GoDocs for details
  • api.go registers the http endpoints to expose at runtime. View the GoDocs for details
  • bootstrap.go reads in the config file and sets up all of the encryption requirements. If the required key files do not already exist in the config directory, bootstrap will generate all of the required files. View the GoDocs for details
  • pingpongservice is useful test code that allows for validating the communication between nodes. There is an exposed endpoint in api.go for calling this service and validating communication.

Other directories

The other directories under Disgo are not runtime packages. These directories contain files for automating the setup of environments or assist in testing features. A brief description is provided for each.

helper-files

  • curls directory contains curl commands that can be used to test a running disgo node from the command line. The JSON could also be pasted into something like postman to do the same tests.
  • docker directory contains docker files for running disgo in a docker container. We are running these inside a Kubernetes cluster to easily manage multiple instances.
  • config json files are default configuration files to use in a Kubernetes cluster
  • run-kubernetes-nodes.sh does what you would expect. We want to make it easy for anyone to be able to spin up their own Kubernetes cluster and run with it!

config

This directory is created the first time you start the Disgo node. As mentioned above, the bootstrap.go code will persist encryption keys and a configuration JSON file that dictates some of the behavior of the node when running. This directory is expected to only be created once unless of course it is deleted. For an example of modifying the config file to run locally as a delegate see the section Migrating a Disgo Node to become a Delegate above.

Clone this wiki locally