📖
Dev Documents
  • README
  • Basic Concepts
    • TEA Developer Prerequisites
    • The TEA Economic Revolution for Developers
    • The Future of Layer-2s
    • What Makes a Web3 App?
    • Magic of the State Machine
  • Step by Step Tutorial
    • Install Dev Environment
    • Hello World
      • Step 1: Build sample-actor and Run Unit Test
      • Step 2: Start the Local Dev Environment
      • Sample Actor Code Walkthrough
      • Sample Front-end Code Walkthrough
      • 025_understand_request_and_response
    • Deploy Hello World on Testnet
    • Add Login Feature
      • Sample-actor Code Walkthrough - Login Branch
        • tea_sdk_utils
      • Sample Front-end Walkthrough - Login Branch
    • SQL
      • Sample Txn Executor
      • Sample Actor
      • Sample Front-end
    • Reward Fund Transfer
      • Sample Txn Executor
    • Retweet Task
      • Retweet Frontend
      • Retweet Sample Actor
      • Retweet Txn Executor
      • Retweet FAQ
    • Gas Fees
      • Query logs
      • A deep dive into gas measurement and settlement
    • Summary
  • Billing
    • Billing FAQ
    • Gas Fee Billing
    • Gas & Fuse Limits
    • Local Debugging Environment
    • State Maintainer Billing
    • TApp Billing
  • Example TApps
  • Advanced TApps
    • TEA Party TApp Intro
    • TEA Party Code Walkthrough
  • Functions
    • Actors vs Functions
    • Function Calls Between Native & Wasm
    • Native vs Wasm Functions
  • Glossary
    • Actor
    • Adapter
    • App AES Key
    • AuthKey
    • back_end_actor
    • Birth Control
    • Blockchain Listener
    • Capability
    • CML Auctions
    • Commands
    • Consensus
    • Context
    • Conveyor
    • Conveyor: Mutable vs Immutable
    • enclave
    • Followup
    • Front-end
    • GlueSQL
    • GPS
    • Hosting Actor Handlers
    • Hosting CML
    • hosting_profitability
    • Magic of WASM
    • mini-runtime
    • OrbitDb
    • Order of Txns
    • party-actor
    • party-fe
    • Party-state-actor
    • Providers
    • Public Service
    • queries
    • Remote Attestation
    • Staking to Hosting CML
    • Staking to TApp
    • State
    • State Machine
    • State Machine Actor
    • State Machine Replica
    • TEA ID
    • TPM
    • Transactions
    • VMH - Virtual Messaging Hub
    • Where Messages are Stored
Powered by GitBook
On this page
  • Privacy protection
  • Sync
  • Cost
  • Eventual consistency
  1. Glossary

OrbitDb

Previousmini-runtimeNextOrder of Txns

Last updated 2 years ago

is a Peer-to-Peer Database for the Decentralized Web

is a serverless, distributed, peer-to-peer database. OrbitDB uses as its data storage and to automatically sync databases with peers. It’s an eventually consistent database that uses for conflict-free database merges making OrbitDB an excellent choice for decentralized apps (dApps), blockchain applications, and offline-first web applications.

In the TEA Project, every has an OrbitDb instance running outside of the enclave.

OrbitDb is used to store large data blobs. OrbitDb provides limited non-relational database features but at a much lower cost. For a relational database, developers can use . For more essential account balance (money) data, we'd suggest using instead.

Privacy protection

IPFS is open to the public. Anything stored in the IPFS can be accessed by anyone. OrbitDB is no exception. How do we protect the data in the OrbitDB? We use the

The data used in one applicaiton is encrypted using this application AES key inside enclave. When the data is saved to the OrbitDB, it has been encrypted. It will be decrypted when again loaded into the enclave by the same application. Other application cnanot decrypt because they do not have such .

The is stored inside the which is consider the top security of the whole TEA Project network. When a new applicaiton host instance starts, it will request such a AES key to the state machine. After a restricted scurity check, the instance can receive such AES key. Because the AES key only live inside enclave (both state machine or hosting nodes.), it is unknown to outside world.

Sync

For every TApp, there are multiple hosting nodes. Every node has their own OrbitDB instance running inside the node (outside of the ). They sync with each other using the standard OrbitDB sync algorithm. Please visit for more details on the sync method.

Because all of these instances share the same , the data is the same across all nodes as they take advantage of the duplication provided by IPFS/OrbitDB.

Cost

Since OrbitDB lives outside of the and is stored on a hard disk (actually IPFS), using it would be much cheaper compared to the (whose data stays inside the RAM of the ). Of course, the state machine would be a much more limited resource and be much more expensive than hard disk space outside of the enclave.

Eventual consistency

OrbitDB provides , which means you could get temporary inconsistency across all nodes. Your TApp has to handle this possible scenario in its business and UI logic.

If your data is very time sensitive and requires , please use the more expensive instead.

OrbitDb
OrbitDB
IPFS
IPFS Pubsub
CRDTs
hosting_cml
gluesql
state
app_aes_key
app_aes_key
app_aes_key
state machine
enclave
orbitdb.org
app_aes_key
enclave
state machine
enclave
eventual consistency
strong consistency
state machine