Orb DLT Architecture

Orb DLT is compromised of two major components: Core and Apollo.

Core

The Core layer provides a tamper-resistant ledger that can be used to implement permissioned, configurable economies. This is segmented into three main components: coin, account and audit.

The Core application is provided as a single binary. When executed with the correct parameters, it will provide one of the three components.
##Coin
Coin provides functionality for executing configurable transaction events and writing to the tamper-evident ledger. This component consists of three main packages: API, data and transaction engine.

The API package provides a REST-ful interface for clients to create transactions, request tamper-evidence verification information and query account balances.

The data package provides the required data structures for persisting transactions and creating the Orb DLT ledger.

The transaction engine is a purpose-built rules engine that will execute transaction events. It is called from the API package, and it utilizes the data package to prepare records to be persisted using the Apollo Transaction Manager.
##Account
account provides functionality for creating accounts and hierarchy of accounts. The base account created from this component does not provide any special functionality; it is used to establish an identifier that can be used by the other Core components. This component consists of two main packages: API and data.

The API package provides a REST-ful interface for clients to create accounts for use by other components.

The data package provides the required data structures for creating accounts using the Apollo Transaction Manager.

Audit

audit provides functionality for creating cryptographic proofs of transaction events executed by coin for providing tamper-evidence. These proofs can be persisted to a separate keyspace away from the main ledger data. This allows the audit service to be run in an isolated environment or by a third-party service provider. It is not mandatory to use the audit functionality, but it is highly recommended. This component consists of three main packages: API, data, and crypto.

The API package provides a REST-ful interface for clients to create tamper-evidence proofs of their ledger entries.

The data package provides the required data structures for persisting proofs using the Apollo Transaction Manager.

The crypto package uses a NaCl-compatible library to generate ciphertexts of ledger data. For security concerns, a one time use key-pair is generated for each proof. The new public key is stored with the ciphertext, but the private key is discarded. This is enough for the client to verify the ciphertext payload at a later date. For more information about tamper-evidence provided by Orb DLT see: tamper-evidence.

Apollo

Apollo is a middleware component that provides a standardized programming interface for storage systems for both OLAP and OLTP use cases. Apollo is designed with high availability, linear scalability, flexible data models and loose coupling of components in mind. Currently, it only provides support for Cassandra, but its components are built in a modular way in which other database and storage engines could be utilized. Apollo consists of three main components: thrift, storage, and transactions.

Thrift

The thrift package is an auto-generated RPC layer used to interact with the other underlying components. Orb supplies supported clients written in botJavava and Go, but compatibility with other programming languages can be made available using the thrift compiler. Currently, Orb supports v0.9.3.
##Storage
storage is a multi-dimensional map distributed to nodes by key-based partitioning. It is utilized via a simple CRUD interface for the underlying storage. Currently, storage assumes that the underlying storage implementation has some conditional mutation features such as conditional update only if there is an existing record.
##Data Model
Each record in the map is structured as follows, and each value in the map is an uninterpreted array of bytes.

(row-key, clustering-key, column-name) -> column-value

Characteristics

• Records are partitioned by row-key.
• Records with the same row-key are sorted by clustering-key (if clustering-key capabilities are implemented in the underlying storage engine).
• Slimilar to Google BigTable but it is a little more general. (less general than Cassandra)
  • The data model can be made to resemble Google BigTable by storing using a timestamp in the clustering-key.

Transaction

transaction is a decentralized and distributed transaction manager, which execute multiple transactions in a SI (Snapshot Isolation) or Serializable manner. transaction currently supports a proprietary transaction manager internally called ECG (Enhanced Cherry Garcia). ECG enhances and corrects the client-coordinated protocol described in "Scalable Distributed Transactions Across Heterogeneous Stores "[1], and it utilizes client-coordinated characteristics with decentralized storage to enable a decentralized transaction, which achieves not only scalable and high-available transactions but also a system owned by multiple, equal parties.

Originally, ECG guaranteed only SI (Snapshot Isolation), but currently, it also guarantees Serializable isolation by making it always write the data when a record is read. For the theory behind making snapshot isolation serializable, please see "Making Snapshot Isolation Serializable [TODS'05]"[2].

References
[1] https://ieeexplore.ieee.org/document/7113278/
[2] https://dl.acm.org/citation.cfm?id=1071615