Introduction

Distributed Ledgers

Distributed ledger technology (DLT) for fair play in a globalized world. A distributed ledger is a database for processing transactions and storing data in a way that makes them useful for solving today’s complex economic challenges. A distributed ledger has three core distinguishing ideas:

  1. Everywhere is the same.
  2. The record is permanent.
  3. No one is in charge.

These three properties allow us to build self-reconciling processes that empower trustless participants to construct complex agreements and reconciliation workflows between each other, with assurance on the integrity and provenance of all interactions.

Distributed ledgers can also run programs called contracts, which model workflows across the entire network involving other DLT participants to read and write to shared processes and assets.

Secure Multiparty Databases

The key problem with today’s enterprise data solutions is that they consist of a network of ad-hoc data silos that are synchronized via a manual set of processes across many counterparties’ databases. By constructing a single self-synchronizing shared database that binds data and reconciliation logic into its fabric, we eliminate an entire class of workflows around integrating and reconciling data.

By moving to a shared distributed database, businesses and institutions can eliminate cost and data inconsistencies and redundancy involved in traditional data workflows.

Building a Network

To create a network, first run a validating node as described above. This will allow the network to accept transactions and create blocks comprised of those transactions. Any node in the network can issue transactions, but only validating nodes can create and broadcast blocks to the network. Once a validating node is running, other validating or non-validating nodes can be run, with the ability to issue transactions to the network. To run two non validating nodes:

In a different console window, run the same command as above, but without pointing to a validator node private key and with differing P2P and RPC ports specified as command line arguments:

$ uplink chain init -c config/node.config.local -b "leveldb://uplink2" -d node1 -p 8002 --rpc-port 8546 -v

In yet another console window, run the same command as above, with differing RPC and P2P ports:

$ uplink chain init -c config/node.config.local -b "leveldb://uplink3" -d node2 -p 8003 --rpc-port 8547 -v

When prompted whether we want to provide a private key, we can enter n.

To check that the we are indeed running a network with three peers, we can use the Uplink console as follows:

$ uplink console --hostname 127.0.1.1

Running the command listPeers in the Uplink console should give us a list containing the three peers we just started.

In order for nodes to recognize each other as peers on the network, they must be using the same configuration files, for example: node.config and chain.config.