What is DUST?
DUST is a nodejs based framework for building distributed, decentralized applications.
DUST is made of three helper packages:
- Garama: an event signing and validation library.
- EventLocker: a graph database specifically designed to represent a the relationships of events and their confirmations.
- NetShout: an abstraction layer for peer-to-peer communication of nodes in a DUST network.
The DUST-node package utilizes the above packages to allow the user to define a distributed database as a base-state and set of reducers.
How to I build an Application with DUST?
The dust-node npm package allows you to define a base state and a set of reducers, and gives you methods for sending events across a DUST network.
- The Base State is a representation of how your database should look when it's "brand new" - before any users did anything. If your application is a ToDo List (the defacto example for a web app these days) your base state might simple be an empty array waiting for ToDos to be added.
- An Event is a signed bundle of information representing an action by a user. Every event has at least a "type" and usually a "payload." Sticking with the above ToDo List example, a user might issue an event of the Type "add-todo" with the payload "buy milk". The dust-node package will ensure these events are spread across all nodes in the network. To learn more about how events are created and validated by other nodes check out the Garama article.
- Reducers are functions that describe how an event changes the base state. The "add-todo" event above would probably have a corresponding "add-todo" reducer the modified the state by adding an item to the array of ToDos.
Rather than update the state of the database every time an event happens, nodes in the network work together to ensure that each one has a complete record of all events that have been issued. When a node needs to query the database, it can use the base state, events, and reducers to determine the state at a given point. (The dust-node package handles this for you behind the scenes.)
How does DUST acheive consensus (make sure all the nodes agree on the state)?
Each event that is issued in DUST references 2 other events that the issuing node has received and validated in the past. This serves a dual purpose of confirming to other nodes know that event have been received and helping other nodes "notice" if they are missing older events. Because a node will only accept an event if it also has (or can get) the events it references, then confirming one event means you also confirm all the events it references. And the events they reference. And so on.
These chains of events and confirmations form a Directed Acylcic Graph (or DAG). Using this DAG, any nodes that choose a same "starting point" can follow the graph of confirmations and be sure that they'll arrive at the same set of events (in the same order). The idea of using a DAG for distributed ledgers was popularized by the cryptocurrency IOTA
The question then becomes how & when you choose that shared starting point, called a milestone. The DUST protocol and dust-node does not enforce a single framework for choosing milestones, but is easily compatible with a variety of consensus mechanisms. During development or a beta release it usually easiest to use a coordinator based consensus, but this creates a centralized semi-dependancy. In production, a form of Ripple Consensus limited to milestone candidates or a Domain Based Conensus mechanisms may be more appropriate.
Why call it DUST?
Dust - tiny little particles of something bigger - is a nice image to describe a distributed system.
In fact, "dust" has already been a term used among cryptocurrency enthusiats to describe "little unimportant stuff" and the idea of repurposing that to "ittle
important stuff" makes us smile. It was also easy to "Backronym" to