Framework for building Secure Scalable Microservices on Distributed Ledger Technology
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
docs Add images for documentation. Aug 27, 2018
examples Add a genesis block test Sep 5, 2018
rfc Update Decentred-Address.adoc Aug 30, 2018
src TODO FIX Nov 21, 2018
.gitignore Initial commit Aug 17, 2018
LICENSE.adoc Initial commit Aug 17, 2018
README.adoc Update README.adoc Sep 5, 2018
pom.xml Fix a test to pass the checker. Nov 21, 2018

README.adoc

Chronicle-Decentred

XCL Banner

Chronicle Decentred is a framework for building a peer to peer Secure Scalable Microservices on Distributed Ledger Technology.

The purpose of this library is to make it easy to create many high throughput microservices which can be run in a decentralised manner.

What features will be supported in the open source version

The open source version will

  • peer to peer chains running concurrently

  • a near unlimited number of chains. The theoretical limit is one bllion chains for every person in the world.

  • 25K - 500K transactions per second per chain depending on hardware.

  • latencies down to single digit milli-seconds (depending on network connectivity)

  • testing tools for creating new transaction types

  • simple decentralised consensus strategy (PoIP - Proof Of IP)

  • simple exchange of value

  • supports digital and fiat currencies including XCL (Chronicle Accelerate’s token)

What features will the Enterprise version have

The Enterprise version is designed to add features a commercial operator would like

  • supports bursts of millions of messages per second.

  • tighter latencies (sub-milli-second for Proof of Receipt)

  • more options for exchange of value including continuous auctions.

  • more pluggable consensus strategies

  • doesn’t require a digital currency to run.

Lifecycle of a chain

There is one registry chain for finding the nodes providing any individual chain. This is required for peer chains to find each other but not to run.

  • A private/public key pair for an address is created. The address includes the IPv4 address and port of the first node and is the last 6 bytes of the public key.

  • This address must be verified by a majority of nodes running the registry chain.

  • Once verified, the address can delegate authorirty to run the chain the initial nodes. After that a majority of nodes need to agree a transaction occurred for them to be considered to have happened.

  • This chain can create any number of tokens for use in transactions on this chain. Each token has a home chain which created it.

  • Peer chains can also hold value and perform transaction on these tokens.

  • A chain can set the costs, comsumption rate and reward rate for any token.

Single pass transaction lifecycle

A transaction which only needs the authority of one address can be confirmed in a single pass of the blockchain.

  • The holder of a private key creates a Request with an always increasing micro-second timestamp and signs the message using it’s private key.

  • The Request is passed to one or more nodes in the cluster running the chain.

  • Any transaction which has the same (or earlier timestamp) is ignored.

  • The Request is validated by the gateway of the nodes receiving the request, and possibly rejected with a Response to the sender.

  • If valid, the Request is passed to the chainer to be added to the block created by that node.

  • The blocks created by each node are socialised throughout the cluster and through a consesnus model agreed as to the order of those blocks.

  • Once the order of blocks has been agreed by a majority of nodes, every node processes those blocks in the same order and publishes any results.

Double pass transaction lifecycle

A transaction whcih requires the authority of the majority of nodes running in the cluster requires two passes.

  • A Request is created which follows the single pass lifecycle above, however

  • The results of the transactions on each node are socialised to every other node.

  • The outcome is only confirmed by a majority of nodes chosing the same result, this is published as another event with the events from each node attached as proof.

Examples of single and multi-pass transactions

Transaction

Passes

Transfer within a chain using a single address

Single pass

Transfer between a peer chain and the home chain of a token

Two passes on the peer chain and a single pass on the home chain

Transfer between a peer chain and another peer chain for a token which is homed by a third chain

Two passes on the source peer chain, two passes on the home chain and one pass on the destination chain

How does the chaining work?

XCL Chain
Figure 1. Workflow for transactions on the blockchain
  • A client connects to a server over TCP.

  • The gateway receives the transaction and verifies its signature

  • The gateway can process the request or query and send a reply, or it can pass the request onto the blockchain.

  • Transactions passed to the blockchain are batched into blocks. Each node creates a block concurrently (as needed)

  • Blocks are replicated across nodes via TCP.

  • Each node gossips about the blocks it has.

  • Each node votes on which blocks to include in the next round.

  • Once a majority of node vote the same way, those blocks are included in the next round.

  • Transaction in the next round are processed in order.

  • The results of those transactions are published on all nodes.

  • Events to pass back to the client are returned over TCP.

Getting started

Under examples/appreciation there is a module containing tests for transaction.

A more complex example is examples/exchange for transfer and exchange of value.