Architecture of Litentry Oracle

This page discusses a high level overview of the architecture and functionality of Litentry.

PreviousProblem & Solution NextUse Cases

Last updated 4 months ago

Architecture of Litentry Oracle

This page discusses a high level overview of the architecture and functionality of Litentry.

Litentry identity oracle utilizes an infrastructural architecture where identity data progresses from a disordered and scattered state to a structured and utilizable state. The Identity Oracle computation network consists of three core layers that create a verifiable, privacy-enhancing identity computation process. They are:

Identity Oracle Input: Identity data is aggregated from various sources (Etherscan, The Graph, Subquery, Onfinality, and other data providers) and imported into the Litentry ecosystem. Both aggregated and imported identity data are stored in a decentralized manner, ensuring security, privacy, and user control over their personal information. The identity data is then parameterized to create structured profiles that can be used across different applications and services. This allows for customized identity management and facilitates secure and efficient verification and authentication processes.

Processor Unit:

The Litentry Identity Oracle's data flow involves multiple stages from input to processing, with distinct paths for on-chain and off-chain computation. The off-chain computation can either be native via Litentry’s TEE-based Sidechain or externally via ZKP prover, AI-agent, or other cloud computation platform.

Processor Logic (how is computation logic defined):

The Litentry Identity Oracle processes identity data using a combination of on-chain and off-chain computation logic. The on-chain logic is primarily handled by the pallet/runtime logic and smart contracts (EVM/WASM), while off-chain computation involves the Trusted Execution Environment (TEE) and external computational resources. The Oracle can leverage both Ethereum Virtual Machine (EVM) and WebAssembly (WASM) based smart contracts and pallets - a modular piece of runtime logic. Using the Identity Graph, the processor unit generates an output (verifiable credentials or performs a weighted score calculation).

Output:

The Oracle output can serve as proofs and actions based on the processed identity data. These outputs ensure the integrity, validity, and utility of identity information within the ecosystem. Proofs generated by the Litentry Identity Oracle provide verifiable evidence of identity-related claims such as Identity ownership, Identity qualification, and recognition. Actions triggered by the Litentry Identity Oracle are responses to certain events or conditions. These actions can automate processes and improve the functionality of dApps. Examples are Post SBT (Soulbound Token) and trigger notification

The 3 stages of the Litentry Protocol functionality

The functionality of the Litentry protocol is divided into three main stages. These stages are interrelated and they interact together to ensure the privacy of user data.

Linking sensitive identities: The Litentry Protocol starts with the creation of an aggregated identity. In the Identity Hub, the user can prove ownership of their various accounts. The relationships between these accounts are stored in the form of an identity graph inside a Trusted Execution Environment (TEE). This TEE is a hardware black box where the sensitive account relationships are stored, managed, and calculated. It cannot be tampered with and is only visible to the root user.
Generating scores and credentials: When an identity score is requested from a specific user's identity graph, the necessary web2 and web3 data is fetched in real-time. The score or credential is calculated inside the TEE and issued as a verifiable credential without exposing any root accounts or metadata. The verifiable credential simply states the truth. It is stored encrypted on Litentry's parachains for verification purposes and sent to the user's local storage.
Issuance of verifiable credentials: Litentry uses W3C Verifiable Credential standards as the format for sharing identity scores or labels outside the Identity Hub. This allows for privacy-preserving, selective disclosure of identity data according to a self-sovereign identity framework.

PreviousProblem & Solution NextUse Cases

Last updated 4 months ago

Processor Unit:

Processor Logic (how is computation logic defined):

Output:

The 3 stages of the Litentry Protocol functionality

The functionality of the Litentry protocol is divided into three main stages. These stages are interrelated and they interact together to ensure the privacy of user data.

Linking sensitive identities: The Litentry Protocol starts with the creation of an aggregated identity. In the Identity Hub, the user can prove ownership of their various accounts. The relationships between these accounts are stored in the form of an identity graph inside a Trusted Execution Environment (TEE). This TEE is a hardware black box where the sensitive account relationships are stored, managed, and calculated. It cannot be tampered with and is only visible to the root user.
Generating scores and credentials: When an identity score is requested from a specific user's identity graph, the necessary web2 and web3 data is fetched in real-time. The score or credential is calculated inside the TEE and issued as a verifiable credential without exposing any root accounts or metadata. The verifiable credential simply states the truth. It is stored encrypted on Litentry's parachains for verification purposes and sent to the user's local storage.
Issuance of verifiable credentials: Litentry uses W3C Verifiable Credential standards as the format for sharing identity scores or labels outside the Identity Hub. This allows for privacy-preserving, selective disclosure of identity data according to a self-sovereign identity framework.