Skip to content

Dapos

Jump to bottom
Avery-H edited this page Jun 19, 2018 · 1 revision

Table of contents

Overview

The dapos package provides the services for using Delegated Asynchronous Proof-of-Stake (DAPoS) consensus for transactions.

DAPoS is a new consensus algorithm developed by the Dispatch team for use in the Dispatch protocol. By electing Delegates to validate transactions. DAPoS Delegates can write as many transactions per second to their chain as their hardware is capable, improving scalability over stepwise blockchain consensus algorithms.

For a deep dive into DAPoS, check out the white paper. add link to whitePaper

The main actors in dapos are delegate and transaction. There is of course communication and synchronization between nodes, but the validation of a transaction and maintenance of the ledger are the most important operations of this package.

Genesis

⚠️🚧 | Work In Progress | 🚧⚠️

Create two wallets create a new transaction with the private key of wallet 1 and from to with w1.address and w2.address with a timestamp provides the signature

Transaction

A transaction contains all of the information to validate and persist an immutable operation. The transaction contains the following attributes:

Attribute Description Data Type
Hash The hash is constructed from the other attributes in the transaction string
Type Support for different types of transactions ( only 1 at the moment ) int64
From The Wallet Address of the original sender string
To The Wallet Address of the recipient string
Value Numeric value for quantity to transfer int64
Time Timestamp of the transaction from the sender Time
Sender The Node that sent the transaction to the current delegate node. This would be the original sender (From) or could be the address of the delegate that sent to another delegate string
Signature The Signature is a cryptographic hash of the original senders private key and the transaction hash. The private key is NEVER sent over a wire (This is a non-breakable law) string

Validation

Validation starts with verifying the hash values from the transaction. If the computation does not match, then either some data is lost, or the transaction was tampered with.

If the transaction was already processed by the delegate, it skips doing validation again. The node then constructs the balance for the address in the From and verifies that it is in order and that time is ok and that the balance is valid for the value of the transaction.

A complete detailed write-up of this is available here link to new paper when published

The Ledger

⚠️🚧 | Work In Progress | 🚧⚠️

The Ledger is critical. It holds the history of all transactions.

As of this writing, the ledger is implemented as a linked list of immutable transactions with a validation hash and timestamp.

The details of how we reconcile the ledger and its full behavior are still a work in progress and the documentation will progress with the implementation.

Performance

** Ask Avery to update text for new Parallel sorting algorithm **

⚠️🚧 | Work In Progress | 🚧⚠️

The Actors

Delegates

⚠️🚧 | Work In Progress | 🚧⚠️

Delegates are elected periodically and there is a bounded number of delegates at any given time. Delegates are responsible for validating transactions and coming to consensus with other Delegates.

Bookkeepers

⚠️🚧 | Work In Progress | 🚧⚠️

Once Delegates have achieved consensus, the bookkeepers take over the responsibility of adding transactions to the ledger.

Elections

⛔ Definition coming soon ⛔

Design Approach

One of the main things we want to accomplish is a simple, pluggable API. For consensus, we have two major things:

  • Communication protocol. - gRPC and HTTP are the currently supported protocols.
  • Consensus algorithm. - DAPoS is our consensus, but we believe that making the system flexible in a simple way will provide us with an easier road to either changing or upgrading the algorithm.

The design follows a pluggable implementation for what implementation the node should use on startup. We follow a builder pattern to set this configuration of the system at startup time.

The builder options are specified in the file that has the IService implementation. So you will notice that dapos service includes a function named withGRPC(). This registers the corresponding transport protocol to use when running the system.

Because dapos depends on disgover, we need to make sure that disgover is up and running prior to starting dapos. For this we have an Event strategy. Dapos will register as a subscriber to an event. When disgover completes startup, the event is triggered so that dapos is able to start successfully.

The Packages section provides more details how this is implemented

Getting Started Sample

To use Disgover, you will need to at least have the commons package for loading node configuration

A functional server and client implementation are available to try it out:

A simple service that runs dapos

A simple gRPC client that runs dapos

Packages

  • core - main package for DAPoS consensus logic
  • proto - protobuf generated code for communication over GRPC

Base dapos Package

The base dapos package contains the service implementation that handles all of the request/response actions. It follows the Service Implementation pattern.

At this time, dapos supports GRPC and HTTP protocols. GRPC is used for the node to node communication and the HTTP protocol is currently being used for testing, but will be able to support thin clients.

The package consists of the following files:

  • dapos service
    • Provides the implementation of the IService interface
    • Includes builder functions for the desired transport protocol(s) to use

see the godoc for details of the implementation

  • dapos api

    • Provides the concrete implementation of the functions that perform the business logic. For DAPoS it is the entry point for calling the consensus algorithm, which is implemented in ./core/node.go

  • dapos transport grpc

    • Provides the GRPC functions for communicating to other nodes.
    • Each public function converts the proto structure type to a domain structure type as described in the Service Implementation

see the godoc for details of the implementation

  • dapos transport http Add when migrated from disgo to appropriate place in dapos

see the godoc for details of the implementation

  • delegate * The delegegate code for consensus

see the godoc for details of the implementation

Clone this wiki locally