Skip to content

Chronicle Decentered

What is Chronicle Decentered?

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.

Open Source Features

  • Peer to peer chains running concurrently

  • A near unlimited number of chains (the theoretical limit is one billion chains forevery person in the world)

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

  • Latencies down to single digit milliseconds (depending on network connectivity)

  • Testing tools for creating new transaction types

  • Simple decentralised consensus strategy (PoIP - Proof of IP)

  • Simple exchange of value

  • Supports bursts of millions of messages per second

  • Tighter latencies (sub-millisecond 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

Enterprise Features

  • Peer to peer chains running concurrently

  • A near unlimited number of chains (the theoretical limit is one billion chains forevery person in the world)

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

  • Latencies down to single digit milliseconds (depending on network connectivity)

  • Testing tools for creating new transaction types

  • Simple decentralised consensus strategy (PoIP - Proof of IP)

  • Simple exchange of value

  • Supports bursts of millions of messages per second

  • Tighter latencies (sub-millisecond 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 authority 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, consumption 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 consensus 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 which 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 choosing 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

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
Chronicle Community Photo 2

Our partners

We partner with some of the industry's most trusted brands

Partner Logo - MTree
Partner Logo - Lenovo
Partner Logo - Speedment Logo
Partner Logo - Red Hat
Partner Logo - Reactive Markets
Partner Logo - Nvidia
Mellanox Partner Logo

Want to learn more? See the benefits of Chronicle's products in action

At Chronicle, we believe less is more. Learn more about why and how Chronicle can support your business and how it can increase efficiency and streamline your systems and workflows by speaking with one of our experts.

We can also offer you our release notes.

By completing this form, I agree that Chronicle Software may keep me informed of its products, services and offerings. To view our privacy policy, click here. To unsubscribe click here.