Written by: Wu Yue, Geek web3
Editor: Faust
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:
You must have ETH or other Gas Tokens in your account in advance, otherwise you cannot initiate transactions. Obviously, this is very unfriendly to new accounts.
Public chains represented by the EVM system only support a single account system. Other public chains or Web2 users need to use new account tools and entrances.
The EIP-4337 proposal, which was once 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, developer cognition and other factors, the EIP-4337 patch is more like a patch rather than a fundamental solution to the problem. EIP-3074, which attempts to add new opcodes to EVM, is considered to have security risks. It brings new problems while solving old problems, and its feasibility is controversial.
Due to various reasons, the founding team of Ethereum 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, no support for multiple encryption primitives, etc. 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 chains that came later, but only make up for the gap between the two. If a public chain fully considers account design when it is initially designed, it will not have to take a detour like Ethereum.
Unlike EVM-based public chains, Nervos has given in-depth consideration to the account system at the beginning of its design. After research, we believe that Nervos' account system is more inclined to the underlying layer and essence of AA. Its UTXO account model and OmniLock, which supports multiple verification methods, are deeply aligned with AA's goals from beginning to end, and have no historical baggage. They naturally support the account systems of other public chains such as BTC, ETH, and even Solana.
In addition, for the recently popular BTCFi, since it introduces 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. 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 including 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, and each transaction will destroy the old UTXO and create a new UTXO. In addition, UTXO data is not stored under a centralized address, but is decentralized in the transaction that generates the UTXO, and 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 traditional Web2 platform "account-information" system, 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 different people's asset data are very clear, which is more friendly to parallelism/concurrency, and is also convenient for supporting functions such as storage leasing, which can avoid many pitfalls of the traditional account system.
The account system of the Nervos public chain was designed to fully absorb the advantages of Bitcoin UTXO. 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, unlike the EVM public chain, which treats native assets differently from ERC-20.
The operating mechanism of CKB's Cell is similar to Bitcoin's UTXO: both are driven by "locking scripts" and "unlocking scripts". When each UTXO/Cell is generated, there will be a "locking script", just like a combination 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.
But 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 the Cell, then TypeScript is the smart contract attached to the Cell. The code of DEX and lending protocols can be deployed in TypeScript.
If developers want to implement an AMM-like liquidity pool 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 balances of various assets in the pool) in the Data field of this Cell. After that, users can interact with the code in TypeScript.
The design of CKB expands richer scenarios based on the Bitcoin UTXO model and is much more programmable. In addition, 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 main 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. For this purpose, 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 LockScript, which determines who can rewrite the Cell and 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. By setting different parameters, 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 simple terms, OmniLock is a piece of code that Nervos has directly deployed 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 how the locking script and OmniLock work through a piece of pseudo code.
The lock script of CKB 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. Next, we will 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 be eligible to rewrite the data in the Cell.
The flag in Auth is an identifier used to select different authentication methods. The authentication method here refers not only to cryptographic signature verification, but also to 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 Bitcoin, Dogecoin, Tron, multi-signature and other rich message verification forms.
Another part of Args is called Omnilock args, which is like a button that allows you to choose from the pre-set functional modes in OmniLock, such as administrator mode (such as the administrator freeze function of USDT), anyone-can-pay mode for small payments (for small donations), time lock mode, etc. Anyway, as long as you adjust Omnilock args, you can use different pre-written functions 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 methods 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 Ecosystem: 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 ecosystem. In addition, it also includes the DID platform Did.id that provides security, privacy protection and identity management services, as well as the decentralized Dobs asset trading platform Dobby.
The good features of AA also bring great convenience to the BTCFi ecosystem application, allowing projects within the CKB ecosystem to directly support BTC wallet interaction, lowering the threshold for use. In the following, let us take a specific case to examine the CKB 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 operability of various public chains on CKB.
The following figure is the connection window of CCC. Here we take MetaMask as an example to show you how to operate the corresponding account on the CKB chain if you have an Ethereum account.
When using CCC to conduct CKB on-chain transactions, the demo will call the personal_sign method of the MetaMask wallet for signing. This method is used to sign a text message that is not directly on-chain.
We can see that the information contains a series of hexadecimal codes of CKB transactions. 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 layer and abstracted the implementation details of multi-chain wallets through CCC, which greatly reduces the difficulty of development and allows upper-level application developers to better focus on the development of upper-level business logic without having to pay too much attention to the underlying details.
Mobit
Mobit is a DID and asset management platform based on Nervos. To use a metaphor, Mobit is like a door for the outside world to enter the Nervos ecosystem, and the threshold of this door is very low. With Mobit, users do not need any prior knowledge, just some simple operations, and they can use accounts on other public chains to interact in the Nervos ecosystem.
The picture below 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 taking the Metamask wallet as an example, the interface after connection can also see the user's EVM and CKB address, and display the tokens and DOBs assets held by the address on the CKB chain.
Let’s talk about DOBs here. They are unique to the Nervos ecosystem and are similar to NFT assets, but DOBs are fundamentally different from NFTs. First, the data of DOBs is completely stored on the chain, which can be regarded as a “full-chain NFT”, while the data of many Ethereum NFTs is not completely stored on the chain;
In addition, each DOBs can be set up with a Chatbot, which can carry out interactive scenarios such as dialogue with the holder. With different development paths of different holders, each DOBs will have more significant benefits compared to traditional NFTs. Individual Differences.
As for Omiga, it is the trading platform for DOBs in the Nervos ecosystem. Users can directly jump into it with one click on the Mobit Apps interface.
Omiga also leverages Nervos’ account abstraction capabilities.
Mobit is easy to operate and has comprehensive functions, which will help the interaction with 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 web standard jointly developed by the World Wide Web Consortium (W3C) and the FIDO (Fast IDentity Online) Alliance. Its goal is to improve the security of user authentication, simplify the login process, and reduce reliance on traditional passwords or private keys.
Some mainstream desktop or mobile operating systems such as iOS and Android have built-in key management software that can use local security modules or cloud storage to store keys and sign. Currently, mainstream WebAuthn practices generally support P-256, P-384, P-521, etc. Since Nervos' OmniLock supports custom cryptographic primitives, it can also cover these.
Here are some of the WebAuthn supported clients:
Apple KeyChain:
Security Enclave: Apple devices use the Secure Enclave to handle critical 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 and facial recognition to verify user identity.
Android Keystore: Android devices can use hardware security modules for key storage and signing, and authentication through biometric features such as fingerprint or facial recognition.
Ubisoft Security Keys: Security key hardware devices, such as YubiKey, that support secure authentication and signing operations via USB or NFC.
The CKB ecosystem wallet JoyID is an application that uses WebAuthn technology. Through JoyID, users can directly authenticate 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 the 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 managing private keys and mnemonics, 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.
Summarize
Ethereum is limited by its historical baggage, and the existing AA solution is basically a temporary solution and cannot solve the problem from the root; Nervos fully considered the design of the account system at the beginning of the launch of the main network, and provided the OmniLock function that can support any form of identity authentication method.
Nervos' Cell model is essentially a functional extension of Bitcoin UTXO. Its locking script can support multiple signature verification algorithms. OmniLock supports any Cell to be directly called in the locking script in a way similar to a system contract, providing a Web2-level experience for developers and users.
Currently, the Nervos account abstraction ecosystem already has products such as CCC, Mobit, and Joyid, which are basically complete;
The essence of BTCFi 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. As an important facility in the BTCFi ecosystem, CKB has adopted an inclusive approach to create the necessary conditions for BTCFi's mass adoption on both the developer and user sides.
