Orion is a key-value/document database with certain blockchain properties, including:
- Tamper Evident: Data cannot be tampered with without it going unnoticed. At any point in time, a user can request the database to provide proof for the existence of a transaction or data, and verify the same to ensure data integrity.
- Non-Repudiation: A user who submitted a transaction to make changes to data cannot deny submitting the transaction later.
- Crypto-based Authentication: A user that submitted a query or transaction is always authenticated using a digital signature.
- Confidentiality and Access Control: Each data item can have an access control list (ACL) to dictate which users can read from it and which users can write to it. Each user needs to authenticate themselves by providing their digital signature to read from or write to data. Depending on the access rule defined for data, sometimes more than one user needs to authenticate themselves together to write/update the data.
- Serialization Isolation Level: This ensures a safe and consistent transaction execution.
- Provenance Queries: All historical changes to the data are maintained separately in a persisted graph data structure so that a user can execute a query on those historical changes to understand the lineage of each data item.
Orion DOES NOT have the following two blockchain properties:
- Smart-Contracts: A set of functions that manage data on the blockchain ledger. Transactions are invocations of one or more smart contract's functions.
- Decentralization of Trust: A permissioned setup of known but untrusted organizations, each operating their own independent database nodes but connected together to form a blockchain network. As one node cannot trust the execution results of another node, ordering transactions must be done with a BFT protocol and all transactions must be independently executed on all nodes.
Figure 1 presents the high-level architecture of Orion.
Orion stores and manages the following five data elements:
- Users: Storage of users' credentials such as digital certificates and their privileges. Only these users can access the Orion node.
- Key-Value Pairs: Storage of all current/active key-value pairs committed by users of the Orion node.
- Historical Key-Value Pairs: Storage of all past/inactive key-value pairs using a graph data structure with additional metadata such as the user who modified the key-value pair, all previous and next values of the key, transactions that have read or written to the key-value pair, etc... This helps to provide a complete data lineage.
- Authenticated Data Structure: Storage of Merkle Patricia Tree where leaf node is nothing but a key-value pair. This helps in creating proofs for the existence or non-existence of a key-value pair and transaction.
- Hash Chain of Blocks: Storage of cryptographically linked blocks, where each block holds a set of transactions submitted by the user along with its commit status, summary of state changes in the form of Merkle Patricia's Root hash, etc... This helps in creating a proof for the existence of a block or a transaction.
The users of Orion can query these five data elements provided that they have the required privileges and they can also perform transactions to modify active key-value pairs. When a user submits a transaction, the user receives a transaction receipt from the Orion node after the commit of a block that includes the transaction. The user can then store the receipt locally to perform client-side verification of the proof of existence of a key-value pair, transaction, or a block.