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

自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中预先定义的几种鉴权方式外，开发者也可以自行定义身份验证方案。

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创造必要条件。

以上是解读CKB账户抽象生态: BTC Mass Adoption的铺路石的详细内容。更多信息请关注PHP中文网其他相关文章！