Tech dive: building blocks for Litentry’s chain abstraction services

As announced previously, Litentry is marching steadily with a strategic move onto chain abstraction services. While the ultimate vision looks very appealing, it’s never easy to build it — the whole system will be backed by a set of sophisticated yet exquisite components in order to accomplish that. I’ll try to give a sneak peek into it in this article.

In a nutshell, we are building a blockchain scheme that consists of both on-chain and off-chain services.

1. On-chain services

we own a substrate-based, EVM-compatible L1 DPoS main-net that has been running smoothly for over two years. This chain is completely decentralized, thus the consensus, including the runtime logic change can only be done in a democratic way (on-chain voting).

The main-net serves as the cornerstone for the chain abstraction service, especially wherever decentralization, transparency, and traceability are demanded. Concretely, it provides the following services/features:

Modularity, security and flexibility based on substrate

Compared to other L1 chains, the whole mainnet stands out thanks to Substrate Framework:

• Modular: the core components of a blockchain system (network, consensus, runtime etc) are fully customisable and one can choose or adapt the new logic as required
• Security: it’s fully decentralized, thus no single authority can alter the chain state without going through the on-chain governance. The decentralized validation-staking-slashing mechanism combined with a large amount of backed LIT tokens (currently 9M) makes it economically infeasible to attack the network.
• Flexibility: with runtime defined as WebAssembly (Wasm), the runtime logic can be changed on the fly without requiring disruptive network upgrades. It is also future-proof to easily adopt new technologies.

OmniAccount Management

Whichever account you use to log onto our system, a native on-chain account will be generated (derived) we call it — OmniAccount. We ensure that this OmniAccount has no private key and thus can only be controlled by its backed accounts. By utilizing Substrate primitives, you’ll be able to easily manage and control this account — including balance transfer, contract calls, or sending any other on-chain transaction.

Intent lifecycle tracking

User requests are stored as “intents”, which stands for the intention of what the user eventually wants to accomplish (similar to requests sent to AI model to some extent). Users only raise the intention but don’t care about how it’s processed and fulfilled in the background.

Intents can be very concrete:

I want to call the smart contract 0x12fa on the ETH network with these parameters and value

or more generalized:

I want to bridge my 1 USDT from ETH to Polygon

I want to use my 1 BTC as collateral and lend out stable coins and eventually stake them in an dApp on Arbitrum

or even more generalized:

I want use my 1 BTC to generate at least 10% APY

Such intents will be stored and tracked on-chain, but processed off-chain. Users can have a transparent view of the whole intent lifecycle — when it’s initiated, when it’s processed, when it’s finalized — and what is the processing result.

Settlement layer and roll-up finalisation

Going through the decentralized consensus, the mainnet works as the settlement layer of intent-based transactions. It functions as the single source of truth for off-chain services — both as inputs and outputs.

Additionally, it accepts, verifies and finalizes roll-up transactions from off-chain services to ensure that the state being mutated is final and trackable.

Multi-Asset Management

For use cases that go through or land on the Litentry mainnet, the assets might need to be bridged to Litentry temporarily or permanently. We accept assets from different foreign chains; they will all be manageable under the OmniAccount to provide a unified and seamless UX.

With the help of multi-asset management, users can have various options to pay for service fees, either with main-net native token, or tokens within the multi-assets.

Account Aggregation

Users can add more member accounts (web3 or web2) to their OmniAccount to form an “Account Store”. The accounts are stored on-chain as encrypted by default. Users can, however, publicize them at any time.

The benefits are:

• you’ll be able to control the OmniAccount with any account from the store, the requests can even come from different devices — imagine you can authorize and send transaction using web3 wallet on PC while you are at home, or use Face ID to authorize if you are on your mobile phone.
• allow users to impose more complicated/strict rules to access OmniAccount — e.g. requires both BTC signature and email verification code.
• a full user profile that can be generated for different purposes (e.g. credit computation, proof of humanity), with complete sovereignty from users — they can control which accounts to leak and share.
• verifiable credentials can be generated to prove your ownership of accounts or on-chain activities.

Enclave Management

The chain manages the off-chain service workers (running within enclaves), including their registration, remote attestation, heartbeat and upgrade.

2. Off-chain Services

Off-chain services is equally important to the on-chain logic, as this is where the cross-chain execution and intent-based request is actually handled. Please note all our services run within a Trusted Execution Environment (TEE), so they are intrinsically integral, verifiable, and privacy-preserving.

The components of off-chain services include:

Omni-Authenticator

It’s the authentication layer of the OmniAccount.

It’s an RPC service that:

• listens to user requests (intents)
• verifies and authenticates the ownership of OmniAccount, users can authenticate themselves with any of the account types that we support:

1. web3 wallet signature, e.g.: BTC / EVM / Substrate.

2. web2 authentication: e.g. google account / Email.

3. off-chain or on-device authentication: e.g. FaceID / Phone SMS.

• bring the request on-chain to initiate the intent processing.

Omni-Translator

It listens to the mainnet, reads intents from the blockchain storage, and translate them into block transactions. In complex scenarios, a single intent can be converted into multiple transactions, including a mix of native and cross-chain transactions. These transactions will then be sent to the executor and/or mainnet for execution.

Omni-Custodian

It’s not a single instance; it’s a cluster of TEE nodes to ensure maximum security and availability. They cooperate to generate a custodial account on the given target network by deriving it from the OmniAccount. By using SMPC (Secure Multi-Party Computation) and TSS (Threshold Signature Scheme), we ensure that no single node can hold the complete private key, and the node network must collaborate to generate the aggregated signature before dispatching it.

An example of this would be BTC Musig2.

Omni-Executor

Its main tasks include:

• executeing the requests from Omni-Translator by submitting transactions to the target network, using the aggregated signature from Omni-Custodian.
• monitoring the lifecycle of the intent and synchronizing it to the main-net
• calculating the fees (for both success and interruption/abortion) and bring the settlement and finalization on-chain