解读CKB账户抽象生态: BTC Mass Adoption的铺路石

作者：雾月，极客web3

编辑：Faust

自2022年AA叙事在以太坊社区火热以来，账户抽象概念便流行于Web3社区。它实际上是一种关于账户体系的设计理念，旨在更高层次上建立标准，增强账户的功能性。而在以太坊等主流区块链中，由于存在固定规则的限制，账户体系的灵活性和通用性非常差，比如说：

1. 你的账户中要事先有ETH等Gas Token，不然无法发起交易，显然这对新账户非常不友好；
2. 以EVM系为代表的公链仅支持单一的账户体系，其他公链或Web2用户需要使用新的账户工具和入口。

此前在以太坊社区风靡一时的EIP-4337提案被认为可以解决上述问题，但受制于其技术模型、历史包袱与生态发展、***认知等因素，EIP-4337的修补方案更像是在打补丁，而不是从根本上解决问题；尝试为EVM添加新操作码的EIP-3074，则被认为存在安全隐患，在解决旧问题的同时带来了新问题，可行性备受争议。

碍于各种原因，以太坊创始团队在主网启动之初，没有对账户体系进行周全考虑，留下了大量的包袱，如：EOA账户与合约账户分野、不支持无gas交易、不支持多种加密原语等。这些历史包袱对以太坊AA路线图的实施造成了明显阻碍，甚***可以说，以太坊的AA方案并不能让其账户体系超越后来的新公链，而只是在弥补两者间的差距。如果一条公链在***初设计时就充分考虑账户设计，就不用像以太坊一样走弯路了。

与EVM系公链所不同，Nervos在设计之初就深入考虑了账户体系的问题，在进行了调研后，我们认为，Nervos的账户体系更偏向AA的底层和本质，其UTXO账户模型及支持多种验证方式的OmniLock，从始***终都与AA的目标深度契合，且没有历史包袱，天生支持BTC、ETH乃***Solana等其他公链的账户体系。

此外，对于近期火热的BTCFi而言，由于其本身就是为原生比特币资产引入Defi等场景，要让比特币持有者获得无缝的产品体验，有必要兼容主流的比特币钱包等周边设施，而CKB的原生AA方案天然实现了这一点，为BTCFi的大规模采用创造了必要条件。

下面我们将从设计理念、系统架构、应用、生态等多个角度解读Nervos的账户抽象体系。

比特币UTXO与Nervos的Cell模型

大多数人都知道，基于UTXO模型的公链，其数据存储结构并不基于“账户—余额”体系，而采用了一种独特的形式。具体而言，UTXO像黄金一样可以被熔化或铸造，每次交易都会有旧的UTXO销毁，新的UTXO诞生。此外，UTXO数据并不存储在某个集中式地址下，而是分散存储在生成UTXO的那笔交易里，要读取过往区块的记录才能找到。

毫不夸张的说，比特币开创了一种区别于传统Web2平台“账户-信息”体系的存储范式，这可以解决状态爆炸、数据读写效率低下、所有权模糊化的问题。在UTXO模型下，不同人的资产数据存储位置与所有权划分十分清晰，对并行/并发比较友好，也便于支持存储租赁等功能，可以避开传统账户体系的很多坑。

Nervos公链的账户体系在设计之初，便充分吸收了比特币UTXO的优点，其Cell模型实际上是比特币UTXO的升级版，提供了图灵完备的可编程性。此外，无论是CKB还是其他资产都是一等资产，并不像EVM公链一样把原生资产与ERC-20区别对待。

CKB的Cell在运作机理上与比特币UTXO大致相同：都是被“锁定脚本”和“解锁脚本”驱动的，每个UTXO/Cell在产生时，都会有一个“锁定脚本”，就像一道密码锁；而“解锁脚本”是对应的密钥，可以解开“锁定脚本”。只要你能提交“锁”对应的“密钥”，其关联的UTXO就会任你差遣。

但与比特币UTXO不同的是，Cell在锁定脚本之上增设了“TypeScript”字段。如果说LockScript是身份验证器，决定你是否有资格改写这个Cell，那么TypeScript就是附着在Cell中的智能合约，DEX、借贷协议的代码都可以部署在TypeScript内。

如果***要在CKB上实现类似于AMM的流动性池，只需要在一个专用Cell的TypeScript中写好合约代码，然后在这个Cell的Data字段中，存放流动性池的状态信息（比如池子里各类资产余额），之后用户和TypeScript中的代码交互就行了。

CKB的这种设计在比特币UTXO模型之上拓展出了更丰富的场景，可编程性强得多，且由于CKB本身采用RISC-V虚拟机，支持多种编程语言写的程序，能够支持的各种逻辑要远比比特币强大。

***于Cell的锁定脚本LockScript，则与我们今天的核心话题AA正相关。因为AA所主张的一大特性，在于让链上账户支持灵活多样的身份验证方式。对于UTXO而言，要实现这一功能，就要在充当身份验证器的LockScript上下功夫，CKB为此推出了专门支持多种身份验证方案的OmniLock脚本。

下面让我们来了解下OmniLock的具体设计。

OmniLock与账户抽象

在前面我们曾提到，CKB的Cell与比特币UTXO，其使用权限都是由锁定脚本来定义的，LockScript中会确定哪些人可以改写这个Cell，起到身份验证的作用。为了支持多种认证方法，CKB提供了名为OmniLock的通用型锁定脚本，可以兼容多种签名算法和验证机制。

OmniLock将不同的验证逻辑进行了模块化处理，只要设置不同的参数，就可以灵活配置不同的验证算法。用户可以分别使用BTC、ETH甚***WebAuthn等账户、钱包/鉴权方式，直接操纵CKB链上的资产。

那么OmniLock具体是怎么实现和使用的？其实要通俗的解释，OmniLock是Nervos官方直接在CKB链上布置好的一段代码，这段代码写在了某个特定的Cell上，可以被其他Cell使用，就好像EVM公链中的“系统合约”一样。如果某个Cell要使用OmniLock，可以在自己的锁定脚本中声明引用OmniLock。

下面我们可以通过一段伪代码理解锁定脚本和OmniLock的工作原理。

CKB的锁定脚本包含Code hash、hash type和Args三个字段，由于Code hash和hash type与本节内容关联性不大，这里不作解释。下面我们着重介绍Args字段，通过对Args进行灵活配置，就可以使用OmniLock中定义好的不同验证算法。

Args字段对应的内容可以分为两部分，一部分是auth，专门用于身份验证，其长度为21字节，包含1字节的flag标识符，以及20字节的鉴权数据。auth的鉴权数据中包含一段预设好的公钥哈希，只有公钥哈希对应的公钥主人才能通过身份验证，有资格改写Cell中的数据。

Auth中的flag则是一个标识符，用于选择不同的鉴权方式，此处说的鉴权方式不仅指密码学验签，还包括信息处理等综合流程：如flag为0x01时，代表以太坊外部消息的鉴权方式。除了以太坊，OmniLock还支持Bitcoin、Dogecoin、Tron、多签等丰富的消息验证形式。

Args中的另一部分叫Omnilock args，它就像一个按钮，可以在OmniLock预设好的功能模式中进行选择，如用管理员模式（如USDT的管理员冻结功能）、用于小额支付的anyone-can-pay模式（小额捐赠使用）、时间锁模式等。Anyway，只要对Omnilock args进行调整，就可以使用OmniLock中预先写好的不同功能。

综上，我们可以在Cell锁定脚本的Auth和Omnilock args字段输入不同的参数，来选择不同公链或平台的身份验证方法，为CKB引入多种多样的身份验证方式。当然，除了OmniLock中预先定义的几种鉴权方式外，***也可以自行定义身份验证方案。

(WEEX交易所官网：www.weex.com)

Nervos账户抽象生态：CCC、Mobit和JoyID

上面我们已经知道，OmniLock是Nervos实现账户抽象的基础，而基于OmniLock的钱包如Mobit、.bit、Omiga和中间件CCC（Common Chains Connector）等则构成了Nervos丰富的BTCFi账户抽象生态，此外还包括提供安全隐私保护和身份管理服务的DID平台Did.id，以及去中心化Dobs资产交易平台Dobby等。

AA的良好特性给BTCFi生态应用也带来了极大的便捷性，使得CKB生态内的项目可以直接支持BTC钱包交互，降低了使用门槛。在下文中，让我们以具体的案例切入，来考察CKB的AA生态。

Common Chains Connector（CCC）

首先我们以CCC为例，这是一个钱包连接中间件，专门为钱包和dApp提供各种公链对CKB的可操作性。

下图是CCC的连接窗口。这里我们以MetaMask为例，如果你拥有一个以太坊账户，如何操作CKB链上的对应账户。

当使用CCC进行CKB链上交易时, 该demo会调起MetaMask钱包的personal_sign 方法来进行签名，这种方法用于签名一段不直接上链的文字消息。

我们可以看出该信息包含的内容是CKB transaction的一系列十六进制码。通过MetaMask签名后的消息，将被提交***Nervos CKB链上，并通过OmniLock等机制进行验证。

而前面我们曾提，Nervos本身就支持验证以太坊的消息格式，可以说CKB从底层就考虑好了对接其他公链生态。对用户而言，你可以通过既有的、熟悉的入口和工具进入CKB生态；

而对于***，Nervos在底层定义好了OmniLock标准，并通过CCC抽象了多链钱包的实现细节，极大降低了开发难度，让上层应用***可以更好地专注于上层业务逻辑的开发而不必过度关注于底层细节。

Mobit

Mobit是基于Nervos的DID和资产管理平台，如果用一个比喻，Mobit就像是外界进入Nervors生态的一道大门，而这道大门的门槛很低。借助Mobit，用户几乎不需要任何前置知识，只需要一些简单操作，就可以用其他公链的账户在Nervos生态中完成交互。

下图是Mobit的连接窗口。可以看到目前Mobit已经支持多个主流公链的账户体系，且这个列表还在继续扩张。

仍以Metamask钱包为例。连接后的界面同样可以看到用户的EVM和CKB地址，并展示该地址在CKB链上持有的Token和DOBs资产。

这里说下DOBs，它是Nervos生态中特有的，类似于NFT的资产，但DOB与NFT有本质不同。首先，DOBs的数据完整保存在链上，可以看成是“全链NFT”，而很多以太坊NFT的数据并未完整存储在链上；

另外，每个DOBs都可以设置Chatbot，可以与持有者进行对话等交互场景，随着不同持有者各异的养成路径，相比于传统的NFT，每个DOBs将具有更显著的个体差异。

***于Omiga是Nervos生态中DOBs的交易平台，用户可以直接在Mobit的Apps界面一键跳转进入。

Omiga同样利用了Nervos的账户抽象功能。

Mobit的操作简单、功能全面，将有助于BTCFi的交互。BTCFi产品本质是为原生的比特币资产提供多样性的Defi体验，能否兼容主流比特币钱包将会是BTCFi周边设施需要考虑的重要因素，而CKB目前已经做好了准备。

对WebAuthn的采用

WebAuthn是一种由万维网联盟（W3C）和FIDO（Fast IDentity Online）联盟共同开发的网络标准，目标是提高用户身份验证的安全性、简化登录过程，减少对传统密码或私钥的依赖。

一些主流的桌面或移动操作系统如iOS和Android中内置的密钥管理软件，可以使用本地的安全模块或云存储来存储密钥并进行签名。目前WebAuthn主流实践中一般会支持P-256，P-384，P-521等，由于Nervos的OmniLock支持自定义的密码学原语，所以也可以覆盖这些。

以下是一些WebAuthn支持的客户端：

• Apple KeyChain:

• Security Enclave: 苹果的设备使用Secure Enclave来处理关键的加密操作，包括私钥存储和签名。
• iOS 和 macOS: 苹果的系统可以使用钥匙串API进行身份验证和签名操作，也可以通过Face ID或Touch ID进行用户认证。

• Windows Hello:

• TPM（Trusted Platform Module）: Windows设备可以通过Windows Hello利用TPM进行私钥生成和签名。
• 生物认证: Windows Hello支持指纹识别和面部识别来验证用户身份。

• Android Keystore:Android设备可以利用硬件安全模块进行密钥存储和签名，通过生物特征（如指纹或面部识别）进行认证。
• Ubisoft Security Keys:  安全密钥硬件设备，如YubiKey，支持通过USB或NFC进行安全认证和签名操作。

CKB生态钱包JoyID就是利用WebAuthn技术所实现的应用。通过 JoyID，用户可以直接通过生物识别（如指纹或面部识别）方式进行身份验证，实现无缝且高安全性的登录和身份管理。

Nervos生态中的.bit也是利用Apple的WebAuthn实现来登录并使用区块链的一个场景。

从上面的案例我们可以看出，CKB的AA方案天生就支持其他公链和Web2用户。对于广大Web2用户而言，支持WebAuthn是***关重要的，它摆脱了私钥和助记词管理的包袱，极大降低了使用门槛。越早在这个方向上发力的公链生态，在日后就越有优势。

总结

以太坊受限于其历史包袱问题，现有的AA解决方案基本治标不治本，无法从根源上解决问题；而Nervos在启动主网之初就充分顾及了账户体系的设计，提供了OmniLock功能，可以支持任意形式的身份验证方式。

Nervos的Cell模型实质上是对比特币UTXO的功能拓展，其锁定脚本可以支持多种验签算法，OmniLock则以类似于系统合约的方式，支持任意Cell在锁定脚本中直接调用，为广大***和用户提供了Web2级别的体验；

目前Nervos账户抽象生态内已经有CCC、Mobit、Joyid等产品，基本比较完备；

BTCFi本质是为原生的比特币资产提供多样性的Defi体验，能否兼容主流比特币钱包将会是BTCFi周边设施需要考虑的重要因素，而CKB作为BTCFi生态中的重要设施，采取了包容并蓄的做法，尽可能在***侧和用户侧都为BTCFi的mass adoption创造必要条件。