1. Introduction

This document decribes the principles of the TrustChain architecture. It will describe a new secure communication layer on top of the existing network called IPv8, as well as the network protocol based on the CrawlRequest and HalfBlock message types. Incorporated into this blockchain implementation is a consensus protocol called CHECO (ref), which will be discussed but not elaborated in this document. Protocols have been moving slowlytowards the business layer in the pas decade, such as R3 Corda (ref) and IOTA (ref), and TrustChain as well, meaning it is network agnostic. This section introduces the core concepts of TrustChain, IPv8 and CHECO, which will be further described in further sections.

1.1 Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

1.2 Protocol Overview

TrustChain is a novel implementation of the multi-chain form of blockchain technology. In contrast to traditional blockchains, in multi-chain implementations every agent in the network has its own genesis node. Each interaction creates a new transaction block wich is based on the last block of the two (or more) concerned parties. This not only influences the block-creation speed, but also the amount of effort needed to verify a chain. Along with some other security properties, this is one of the implicit capabilities of this multi-chain implementation, wich is designed to be application neutral and simple.

By removing the proof-of-work mechanism needed for classic blockchain implementations, the multi-chain architecture yields inherent horizontal scalability. This is based on the assumption that both parties agree on the transaction before signing it, making tampering inherently easy to detect. One of the aspects that support this is the fact that a multi-chain is organised as a set of temporally ordered, intertwining chains, which form a Directed Acyclic Graph (DAG, ref). This is called a "bottom-up consensus model", giving the participants the responsibility to verify the correctness of the transaction in stead of a central (sometimes randomly chosen) elected leadership.

As is mentioned, Trustchain depends on signatures from all participants in a transaction, creating a n-to-n node. This system is extedible, as mentioned before, by extending the transaction description to providde specific properties. Each transaction is stored in a block, in true half block format, signed and sequenced so that each sequence number is unique in both chains. This general structure can be seen below.

[structure image]

1.3 IPv8 Overview

[Protocol overview]

[Identities (zowel short als long lived) en key attestation]

1.4 CHECO Overview

Since the dawn of the blockchain, verification and consensus have been a pillar upon which the usability and security of the ecosystem relied. In the classic sense, this needs a Proof of Work (PoW)(ref) and these needs to be a global consensus based on a majority vote. This is the bottleneck for throughput, since lowering the requirement would increase the throughput but decrease the security, limiting classic blockchains to about 7 transactions per second (tps). Increasing block size can not increase tps due to network bandwidth and latency, meaning only a max of 27 is achievable, leading to the conlusion that this is not scalable.

The basic principle for CHECO relies on an improved data structure that requires the addition of a special block, called a checkpoint block: these are blocks representing the validated state of the chain at a certain point in time in the form of a hash pointer. Reaching consensus is based on an existing Byzantine consensus algorithm, but running infinitely many times in parralel for a subset. This eliminates the limit imposed by the size of the validating peer set, leading to a horizontal scaling: adding more agents to the network results in higher transaction throughput. Each round, a random set of agents is selected, called facilitators, which collect checkpoint blocks from all other agents to be fed into the Byzantine consensus algorithm. After consensus is reached, they broadcast a set of new set checkpoint blocks called the consensus result. The agents receive the result and append a new checkpoint block, after which a new round begins.

Validation is intrinsically simple because to verify a transaction block, all you need is the section of the blockchain beginning and ending with checkpoint blocks, but contains the requested transaction block. Upon receiving the section, the checkpoint blocks are verified, by checking if both are in some consensus result; if this is found to be true, the transaction is valid.

[Improved data structure]