WORK IN PROGRESS

This document will describe the new design of the TrustChain ledger, from a technical perspective. Therefore, this document is mostly aimed towards developers interested in the inner working of TrustChain, and application developers utilising the accountability primitives of TrustChain.

We achieve clear separation between an event level and application level. When transaction is received it will be put to the Block DB and the validity of the transaction is application depending.

TrustChain is designed around the following design goals:

• Simplicity
• Lightweight accounting
• Scalability in terms of throughput and participants
• Resistant against selfish participants

• Casual event ordering
• Ad-hoc collaboration
• Lazy verification
• Event-driven architecture
• Security through random audits
• Tamper-proof data structure through peers entanglement
• No global consensus
• Application-depended validation logic

Network message:

• Subject: Public key

This module ensures that message is replicated enough and cannot be removed without being noticed by other peers. This is achieved by using cryptographic primitives.

• Linear Hash Log: Blocks are linked with blocks of other participants
• Merkle trees: TBA
• ...

• Block store:

• Append-only persistent storage
• Simple (key/value?) store
• Stores block in raw format(for network exchange)
• O(1) for fetching block and all related blocks (confirmations, linked blocks)

• Index Store:

• Application depended
• Subscriber on a block store
• Fetches block, deserialises and applied to the database
• Used for application-depend validation

Auditing refers to a explicit verification of a peer according to the specified auditing rules. Witnesses is a selection function that ensures that malicious peer will be detected.

TBA.

This module ensures that any conflict will be resolved in a deterministic way. TBA.

• Message level validation - verify that message is known and not malformed

• Signature validation - verify that message is signed correctly with matching public key. If the message is not valid it will not be consider further (not put to the local DB).

• Application validation. Each method call has a mapping to a validation function. Lazy evaluation.

• We ship the base class for the method calls
• Get must be Async
• Base Class ...

Peers when interacting with each other verify and match that they have the same methods calls.

---

1. Bandwidth accounting

Record pairwise exchanges of bandwidth.

• Exit node customer selection
  • Based on the relative ranking of the candidates
  • Address possible sybil attacks
• Freerider detection ...

2. Currency accounting

Record pairwise exchanges of bandwidth.

• Market
• Auctions
• Credit system

3. Identity

Attributes and attestation accounting

4. Reputation Accounting

• Media market

5. **Orders/ Interest recording **

• Used in matchmaking