Interpreting the CKB Account Abstract Ecosystem: A Stepping Stone for BTC Mass Adoption

Since the AA narrative became popular in the Ethereum community in 2022, the concept of account abstraction has become popular in the Web3 community. It is actually a design concept for the account system, which aims to establish standards at a higher level and enhance the functionality of accounts. However, in mainstream blockchains such as Ethereum, due to the limitations of fixed rules, the flexibility and versatility of the account system are very poor. For example:

1. You must have Gas Tokens such as ETH in your account in advance, otherwise you cannot initiate a transaction, which is obviously very unfriendly to new accounts;

2. Public chains represented by the EVM system only support a single account system, and other public chains or Web2 users need to use new account tools and entrances.

The EIP-4337 proposal, which was popular in the Ethereum community, was believed to be able to solve the above problems. However, due to its technical model, historical baggage, ecological development, and developer cognition, the EIP-4337 patch is more like patching rather than fundamentally solving the problem. EIP-3074, which attempts to add new opcodes to EVM, is considered to have security risks. It has brought new problems while solving old problems, and its feasibility is controversial.

Due to various reasons, the Ethereum founding team did not consider the account system thoroughly at the beginning of the mainnet launch, leaving a lot of baggage, such as: the separation of EOA accounts and contract accounts, no support for gas-free transactions, and no support for multiple encryption primitives. These historical baggages have caused obvious obstacles to the implementation of Ethereum's AA roadmap. It can even be said that Ethereum's AA solution cannot make its account system surpass the new public chain that came later, but only make up for the gap between the two. If a public chain fully considers account design at the time of initial design, it will not have to take the same detour as Ethereum.

Unlike EVM-based public chains, Nervos has deeply considered the issue of account system at the beginning of its design. After conducting research, we believe that Nervos' account system is more inclined to the bottom layer and essence of AA. Its UTXO account model and OmniLock that supports multiple verification methods are deeply aligned with AA's goals from beginning to end. And without historical baggage, it naturally supports the account system of other public chains such as BTC, ETH and even Solana.

In addition, for the recently popular BTCFi, since it itself is to introduce Defi and other scenarios for native Bitcoin assets, in order to allow Bitcoin holders to obtain a seamless product experience, it is necessary to be compatible with mainstream Bitcoin wallets and other peripheral facilities, and CKB's native AA solution naturally achieves this, creating the necessary conditions for the large-scale adoption of BTCFi.

Below we will interpret Nervos' account abstraction system from multiple perspectives such as design concept, system architecture, application, and ecology.

Bitcoin UTXO and Nervos' Cell Model

Most people know that the data storage structure of the public chain based on the UTXO model is not based on the "account-balance" system, but adopts a unique form. Specifically, UTXO can be melted or minted like gold. Every transaction will destroy old UTXO and create new UTXO. In addition, UTXO data is not stored in a centralized address, but is decentralized in the transaction that generated the UTXO. It can only be found by reading the records of past blocks. Recommended reading: "Approaching BTC: Background knowledge required to understand BitVM (1)" It is no exaggeration to say that Bitcoin has created a storage paradigm that is different from the "account-information" system of the traditional Web2 platform, which can solve the problems of state explosion, low data reading and writing efficiency, and blurred ownership. Under the UTXO model, the storage location and ownership of asset data of different people are very clear, which is friendly to parallelism/concurrency, and is also convenient to support functions such as storage leasing, which can avoid many pitfalls of the traditional account system.

The account system of the Nervos public chain fully absorbed the advantages of Bitcoin UTXO at the beginning of its design. Its Cell model is actually an upgraded version of Bitcoin UTXO, providing Turing-complete programmability. In addition, both CKB and other assets are first-class assets, and they do not treat native assets and ERC-20 differently like the EVM public chain.

CKB's Cell is roughly the same as Bitcoin UTXO in terms of operating mechanism: both are driven by "locking scripts" and "unlocking scripts". Each UTXO/Cell will have a "locking script" when it is generated, just like a password lock; and the "unlocking script" is the corresponding key that can unlock the "locking script". As long as you can submit the "key" corresponding to the "lock", the associated UTXO will be at your disposal.

However, unlike Bitcoin UTXO, Cell adds a "TypeScript" field on top of the lock script. If LockScript is an authenticator that determines whether you are eligible to rewrite this Cell, then TypeScript is the smart contract attached to the Cell, and the code of DEX and lending protocols can be deployed in TypeScript.

If developers want to implement a liquidity pool similar to AMM on CKB, they only need to write the contract code in the TypeScript of a dedicated Cell, and then store the status information of the liquidity pool (such as the balance of various assets in the pool) in the Data field of this Cell, and then the user can interact with the code in TypeScript.

This design of CKB expands richer scenarios on the Bitcoin UTXO model, with much stronger programmability. Moreover, since CKB itself uses the RISC-V virtual machine and supports programs written in multiple programming languages, the various logics it can support are far more powerful than Bitcoin.

As for the Cell's lock script LockScript, it is positively related to our core topic today, AA. Because one of the major features advocated by AA is to allow on-chain accounts to support flexible and diverse authentication methods. For UTXO, to achieve this function, it is necessary to work hard on LockScript, which acts as an authenticator. CKB has launched the OmniLock script that specifically supports multiple authentication schemes.

Let's take a look at the specific design of OmniLock.

OmniLock and Account Abstraction

As we mentioned earlier, the usage permissions of CKB's Cell and Bitcoin UTXO are defined by the locking script. LockScript will determine who can rewrite this Cell, which plays the role of identity authentication. In order to support multiple authentication methods, CKB provides a universal locking script called OmniLock, which is compatible with multiple signature algorithms and verification mechanisms.

OmniLock modularizes different verification logics. As long as different parameters are set, different verification algorithms can be flexibly configured. Users can use accounts, wallets/authentication methods such as BTC, ETH, and even WebAuthn to directly manipulate assets on the CKB chain.

So how is OmniLock implemented and used? In fact, to explain it in a simple way, OmniLock is a piece of code that Nervos officials have directly arranged on the CKB chain. This code is written on a specific Cell and can be used by other Cells, just like the "system contract" in the EVM public chain. If a Cell wants to use OmniLock, it can declare a reference to OmniLock in its own locking script.

Below we can understand the working principle of the locking script and OmniLock through a pseudo code.

CKB's locking script contains three fields: Code hash, hash type, and Args. Since Code hash and hash type are not closely related to the content of this section, they are not explained here. Below we focus on the Args field. By flexibly configuring Args, you can use different verification algorithms defined in OmniLock.

The content corresponding to the Args field can be divided into two parts. One part is auth, which is specifically used for identity authentication. Its length is 21 bytes, including a 1-byte flag identifier and 20 bytes of authentication data. The authentication data of auth contains a preset public key hash. Only the owner of the public key corresponding to the public key hash can pass the identity authentication and is eligible to rewrite the data in the Cell.

The flag in Auth is an identifier used to select different authentication methods. The authentication method mentioned here not only refers to cryptographic signature verification, but also includes comprehensive processes such as information processing: for example, when the flag is 0x01, it represents the authentication method of Ethereum external messages. In addition to Ethereum, OmniLock also supports rich message verification forms such as Bitcoin, Dogecoin, Tron, and multi-signature.

The other part of Args is called Omnilock args, which is like a button that can be selected from the preset function modes of OmniLock, such as administrator mode (such as USDT's administrator freeze function), anyone-can-pay mode for small payments (used for small donations), time lock mode, etc. Anyway, as long as you adjust the Omnilock args, you can use the different functions pre-written in OmniLock.

In summary, we can enter different parameters in the Auth and Omnilock args fields of the Cell lock script to select the authentication method of different public chains or platforms, and introduce a variety of authentication methods for CKB. Of course, in addition to the several authentication methods pre-defined in OmniLock, developers can also define their own authentication schemes.

Nervos Account Abstraction Ecology: CCC, Mobit and JoyID

As we know above, OmniLock is the basis for Nervos to realize account abstraction, and wallets based on OmniLock such as Mobit, .bit, Omiga and middleware CCC (Common Chains Connector) constitute Nervos' rich BTCFi account abstraction ecology, in addition to Did.id, a DID platform that provides security, privacy protection and identity management services, and Dobby, a decentralized Dobs asset trading platform.

AA's good characteristics also bring great convenience to BTCFi ecological applications, allowing projects within the CKB ecosystem to directly support BTC wallet interactions, lowering the threshold for use. In the following, let's take a specific case to examine CKB's AA ecosystem.

Common Chains Connector (CCC)

First, let's take CCC as an example. This is a wallet connection middleware that specifically provides wallets and dApps with the operability of various public chains on CKB.

The following figure is the connection window of CCC. Here we take MetaMask as an example. If you have an Ethereum account, how to operate the corresponding account on the CKB chain.

When using CCC to conduct transactions on the CKB chain, the demo will call the MetaMask wallet's personal_sign  method to sign, which is used to sign a text message that is not directly on the chain.

We can see that the content of the information contains a series of hexadecimal codes of CKB transaction. The message signed by MetaMask will be submitted to the Nervos CKB chain and verified through mechanisms such as OmniLock.

As we mentioned earlier, Nervos itself supports verifying Ethereum's message format. It can be said that CKB has considered connecting to other public chain ecosystems from the bottom up. For users, you can enter the CKB ecosystem through existing and familiar entrances and tools;

For developers, Nervos has defined the OmniLock standard at the bottom level, and abstracted the implementation details of multi-chain wallets through CCC, which greatly reduces the difficulty of development, allowing upper-level application developers to better focus on the development of upper-level business logic without having to pay too much attention to underlying details.

Mobit

Mobit is a DID and asset management platform based on Nervos. If we use a metaphor, Mobit is like a door for the outside world to enter the Nervors ecosystem, and the threshold of this door is very low. With Mobit, users do not need any prior knowledge, and only need some simple operations to use accounts of other public chains to complete interactions in the Nervos ecosystem.

The following figure is the connection window of Mobit. It can be seen that Mobit currently supports the account systems of multiple mainstream public chains, and this list continues to expand.

Still take the Metamask wallet as an example. The connected interface can also see the user's EVM and CKB addresses, and display the Token and DOBs assets held by the address on the CKB chain.

Here is DOBs, which is unique to the Nervos ecosystem and is similar to NFT assets, but DOBs are fundamentally different from NFTs. First of all, the data of DOBs is completely stored on the chain, which can be regarded as "full-chain NFTs", while the data of many Ethereum NFTs is not completely stored on the chain;

In addition, each DOBs can set up a Chatbot, which can have interactive scenarios such as dialogue with the holder. With the different cultivation paths of different holders, each DOBs will have more significant individual differences compared to traditional NFTs.

As for Omiga, it is the trading platform for DOBs in the Nervos ecosystem. Users can directly jump into it on the Mobit Apps interface with one click.

Omiga also uses the account abstraction function of Nervos.

Mobit is simple to operate and has comprehensive functions, which will help the interaction of BTCFi. The essence of BTCFi products is to provide a diverse Defi experience for native Bitcoin assets. Whether it can be compatible with mainstream Bitcoin wallets will be an important factor that BTCFi's peripheral facilities need to consider, and CKB is now ready.

Adoption of WebAuthn

WebAuthn is a network standard jointly developed by the World Wide Web Consortium (W3C) and the FIDO (Fast IDentity Online) Alliance. The goal is to improve the security of user authentication, simplify the login process, and reduce reliance on traditional passwords or private keys.

The key management software built into some mainstream desktop or mobile operating systems such as iOS and Android can use local security modules or cloud storage to store keys and sign. At present, the mainstream practice of WebAuthn generally supports P-256, P-384, P-521, etc. Since Nervos' OmniLock supports custom cryptographic primitives, these can also be covered.

Here are some of the clients that WebAuthn supports:

• Apple KeyChain:

• Security Enclave: Apple's devices use the Secure Enclave to handle key cryptographic operations, including private key storage and signing.

• iOS and macOS: Apple's systems can use the Keychain API for authentication and signing operations, and can also perform user authentication through Face ID or Touch ID.

• Windows Hello:

• TPM (Trusted Platform Module): Windows devices can use TPM for private key generation and signing through Windows Hello.

• Biometric Authentication: Windows Hello supports fingerprint recognition and facial recognition to verify user identity.

• Android Keystore:Android devices can use hardware security modules for key storage and signing, and authenticate through biometric features (such as fingerprint or facial recognition).

• Ubisoft Security Keys:  Security key hardware devices, such as YubiKey, support secure authentication and signing operations via USB or NFC.

CKB Eco Wallet JoyID is an application implemented using WebAuthn technology. Through JoyID, users can authenticate directly through biometrics (such as fingerprint or facial recognition) to achieve seamless and highly secure login and identity management.

.bit in the Nervos ecosystem is also a scenario that uses Apple's WebAuthn implementation to log in and use blockchain.

From the above cases, we can see that CKB's AA solution is naturally supportive of other public chains and Web2 users. For the majority of Web2 users, supporting WebAuthn is crucial, as it gets rid of the burden of private key and mnemonic management, greatly reducing the threshold for use. The earlier the public chain ecosystem works in this direction, the more advantages it will have in the future.

Summary

Ethereum is limited by its historical baggage, and the existing AA solutions are basically only symptomatic and cannot solve the problem from the root; while Nervos fully considered the design of the account system at the beginning of the launch of the mainnet, and provided the OmniLock function, which can support any form of identity authentication.

Nervos' Cell model is essentially a functional expansion of Bitcoin UTXO. Its locking script can support multiple signature verification algorithms. OmniLock supports direct calling of any Cell in the locking script in a way similar to a system contract, providing a Web2-level experience for developers and users;

Currently, there are already products such as CCC, Mobit, and Joyid in the Nervos account abstraction ecosystem, which is basically complete;

BTCFi is essentially to provide a diverse Defi experience for native Bitcoin assets. Whether it can be compatible with mainstream Bitcoin wallets will be an important factor that BTCFi's surrounding facilities need to consider. As an important facility in the BTCFi ecosystem, CKB has adopted an inclusive approach to create the necessary conditions for the mass adoption of BTCFi on both the developer and user sides.