
CKBのアカウント抽象化エコシステムを解読:BTC大衆化への土台
TechFlow厳選深潮セレクト

CKBのアカウント抽象化エコシステムを解読:BTC大衆化への土台
Nervos(CKB)のネイティブAA方式の実装方法と関連エコシステム構築について、一文で理解する。
執筆:霧月、極客 web3
編集:Faust
2022年以降、イーサリアムコミュニティでAA(アカウント抽象)のナラティブが注目を集めるようになって以来、この概念はWeb3コミュニティ全体に広く浸透しました。AAとは本質的にアカウント体系に関する設計思想であり、より高いレベルで標準を確立し、アカウントの機能性を強化することを目指しています。しかしイーサリアムなどの主要なブロックチェーンでは、固定されたルールの制約により、アカウント体系の柔軟性と汎用性が非常に低くなっています。たとえば:
-
取引を発行するには、あらかじめETHなどのGasトークンをアカウントに保有しておく必要があるため、新規ユーザーにとって非常に使いづらい;
-
EVM系のパブリックチェーンは単一のアカウント体系しかサポートしておらず、他のチェーンやWeb2ユーザーは新たなアカウントツールと入口を必要とする。
以前、イーサリアムコミュニティで話題となったEIP-4337提案はこうした問題を解決できると考えられていましたが、その技術モデルや歴史的負債、エコシステムの発展、開発者の認知度といった要因から、EIP-4337の修正案は根本的な解決ではなく、むしろ「パッチ」を当てているに過ぎないと言える。一方、新しいオペコードをEVMに追加しようとするEIP-3074はセキュリティ上のリスクがあるとされ、既存の問題を解決しつつ新たな問題を生み出すことになり、実現可能性については大きな議論があります。
さまざまな理由により、イーサリアム創設チームはメインネット立ち上げ当初、アカウント体系について十分な検討を行わず、多くの技術的負債を残しました。たとえばEOAアカウントとコントラクトアカウントの分離、ガスレス取引の非対応、複数の暗号プリミティブの非サポートなどです。これらの負債は、イーサリアムにおける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/Cellを自由に操作できます。

ただし、ビットコインのUTXOと異なるのは、Cellのロックスクリプトに「TypeScript」フィールドが追加されている点です。LockScriptが身元検証子であり、誰がCellを改変できるかを決定するのに対し、TypeScriptはCellに付随するスマートコントラクトであり、DEXやレンディングプロトコルのコードをここにデプロイできます。

開発者がCKB上でAMM型の流動性プールを実装したい場合、専用CellのTypeScriptにコントラクトコードを書き込み、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の3つのフィールドから構成されています。Code hashとhash typeは本節の内容と関係が薄いため省略します。以下では特にArgsフィールドに注目します。Argsを柔軟に設定することで、OmniLockにあらかじめ定義された異なる検証アルゴリズムを利用できます。

Argsフィールドの内容は2つの部分に分けられます。1つはauthで、身元検証専用の領域で、長さは21バイト。1バイトのflag識別子と20バイトの認証データから構成されます。authの認証データには事前に設定された公開鍵ハッシュが含まれており、対応する秘密鍵を持つ者だけが検証を通過し、Cellのデータを改変できます。
authのflagは識別子であり、異なる認証方式を選択するために使われます。ここで言う認証方式は、暗号署名だけでなく、情報処理を含む包括的なプロセスを指します。例えば、flagが0x01の場合、イーサリアムの外部メッセージ認証方式を意味します。イーサリアム以外にも、OmniLockはBitcoin、Dogecoin、Tron、マルチシグなど多彩なメッセージ検証形式をサポートしています。
Argsのもう一つの部分はOmnilock argsと呼ばれ、OmniLockに予め用意された機能モードを選択するスイッチのようなものです。管理者モード(USDTの凍結機能など)、小額支払い用のanyone-can-payモード(寄付など)、タイムロックモードなどが該当します。つまり、Omnilock argsを調整することで、OmniLockにあらかじめ用意されたさまざまな機能を利用できます。
以上のように、CellのロックスクリプトのauthフィールドとOmnilock argsフィールドに異なるパラメータを設定することで、異なるチェーンやプラットフォームの認証方式を選択でき、CKBに多様な身元検証方式を導入できます。もちろん、OmniLockで事前定義された方式以外にも、開発者は独自の認証スキームを定義することも可能です。

Nervosアカウント抽象エコシステム:CCC、Mobit、JoyID
これまで見てきたように、OmniLockはNervosにおけるアカウント抽象の基盤であり、Mobit、.bit、Omiga、中間ミドルウェアCCC(Common Chains Connector)などのOmniLock対応ウォレットが、Nervosの豊かなBTCFiアカウント抽象エコシステムを形成しています。その他にも、セキュリティ・プライバシー保護とID管理を提供するDIDプラットフォームDid.id、分散型DOBs資産取引所Dobbyなども存在します。
AAの優れた特性は、BTCFiエコシステムアプリケーションにも大きな利便性をもたらしており、CKBエコシステム内のプロジェクトが直接BTCウォレットとの相互作用をサポートできるようになり、利用のハードルが下がっています。以下では、具体的な事例を通じてCKBのAAエコシステムを考察します。

Common Chains Connector(CCC)
まずCCCを取り上げます。これはウォレット接続ミドルウェアであり、ウォレットとdAppに対して、さまざまなパブリックチェーンからCKBへの操作性を提供します。
下図はCCCの接続画面です。ここではMetaMaskを例に、イーサリアムアカウントを持っているユーザーが、どうやってCKBチェーン上の対応アカウントを操作するかを示しています。

CCCを使ってCKBチェーン上で取引を行う際、このデモはMetaMaskウォレットのpersonal_signメソッドを呼び出して署名を行います。これは直接チェーンに載らないテキストメッセージに署名する方法です。
このメッセージにはCKB transactionの一連の16進数コードが含まれています。MetaMaskで署名されたメッセージはNervos CKBチェーンに送信され、OmniLockなどの仕組みで検証されます。

前述した通り、Nervos自体がイーサリアムのメッセージフォーマット検証をサポートしており、CKBは初めから他チェーンエコシステムとの接続を考慮しています。ユーザーにとっては、慣れ親しんだ既存の入り口とツールでCKBエコシステムに入れるのです。
一方、開発者にとっても、Nervosは底層でOmniLock標準を定義し、CCCを通じてマルチチェーンウォレットの実装詳細を抽象化することで、開発難易度を大幅に下げており、上層のアプリ開発者がビジネスロジックに集中できる環境を提供しています。
Mobit
MobitはNervos基盤のDIDおよび資産管理プラットフォームであり、比喩すればNervosエコシステムに入るための玄関口のような存在です。その敷居は非常に低い。Mobitを使えば、ユーザーは特別な前提知識がほとんど不要で、簡単な操作だけで他のパブリックチェーンのアカウントを使ってNervosエコシステムと相互作用できます。
下図はMobitの接続画面です。現在Mobitは多数の主要パブリックチェーンのアカウント体系をサポートしており、このリストは拡大を続けています。

引き続きMetaMaskウォレットを例にします。接続後の画面では、ユーザーのEVMアドレスとCKBアドレスが表示され、CKBチェーン上での保有トークンやDOBs資産も確認できます。

ここでDOBsについて説明します。DOBsはNervosエコシステム特有の、NFTに類似した資産ですが、本質的に異なります。まず、DOBsのデータは完全にオンチェーンに保存されており、「フルチェーンNFT」とも言えます。一方、多くのイーサリアムNFTはデータが完全にオンチェーンに保存されていません。
また、各DOBsはChatbotを設定でき、保有者との会話などのインタラクションが可能で、異なる保有者による育成経路により、従来のNFTよりも個体差が顕著になります。
OmigaはNervosエコシステムにおけるDOBsの取引プラットフォームであり、MobitのApps画面からワンクリックでアクセスできます。

Omigaもまた、Nervosのアカウント抽象機能を活用しています。

Mobitは操作がシンプルで機能も充実しており、BTCFiのユーザビリティ向上に貢献します。BTCFi製品の本質は、ネイティブなビットコイン資産に多様なDeFi体験を提供することであり、主流のビットコインウォレットとの互換性はBTCFi周辺インフラにとって重要な要素です。CKBはすでにこの点で準備を整えています。
WebAuthnの採用
WebAuthnはWorld Wide Web Consortium(W3C)とFIDO(Fast IDentity Online)Allianceが共同開発したウェブ標準であり、ユーザー認証の安全性を高め、ログインプロセスを簡素化し、従来のパスワードや秘密鍵への依存を減らすことを目的としています。
iOSやAndroidなどの主要なデスクトップ・モバイルOSに内蔵された鍵管理ソフトウェアは、ローカルのセキュリティモジュールやクラウドストレージを利用して鍵を保存・署名を行います。現在のWebAuthnの実装では一般的にP-256、P-384、P-521などをサポートしており、NervosのOmniLockはカスタム暗号プリミティブをサポートするため、これらもカバー可能です。
以下はWebAuthn対応のクライアント例です:
-
Apple KeyChain:
-
Security Enclave:Apple端末はSecure Enclaveを利用して重要な暗号処理(秘密鍵の保存・署名など)を行います。
-
iOSおよびmacOS:AppleのシステムはKeychain 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を使うことで、ユーザーは生体認証(指紋・顔認証)だけでシームレスかつ高セキュリティなログインとID管理が可能です。

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の大規模採用に必要な条件を整えています。
TechFlow公式コミュニティへようこそ
Telegram購読グループ:https://t.me/TechFlowDaily
Twitter公式アカウント:https://x.com/TechFlowPost
Twitter英語アカウント:https://x.com/BlockFlow_News














