Chronicle-Decentred

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.

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)

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

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.

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.

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.

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

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.

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

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

minborg/Chronicle-Decentred