アカウントの抽象化という概念は、イーサリアムコミュニティでAA物語が火を噴いた2022年以来、Web3コミュニティで人気がある。実際には、より高いレベルで標準を確立し、アカウントの機能を強化することを目的とした、アカウントシステムに関する設計哲学です。そして、イーサなどの主流のブロックチェーンでは、アカウントシステムは固定ルールの制限により、柔軟性や汎用性がほとんどありません。
ETHのようなガストークンをあらかじめアカウントに入れておく必要があります。アカウントツールとポータルを使用する必要があります。
以前、イーサリアムコミュニティで大流行したEIP-4337の提案は、上記の問題を解決すると考えられていましたが、その技術モデル、歴史的なお荷物や生態学的な発展、開発者の認識により、EIP-4337のパッチソリューションはパッチのようなものになっています。EVMに新しいオペコードを追加しようとするEIP-3074は、セキュリティリスクと考えられており、古い問題を解決する一方で新しい問題をもたらし、その実現可能性は非常に議論の的となっています。
さまざまな理由から、Etherの創設チームはメインネットワークの立ち上げ当初にアカウントシステムについて熟考せず、EOAアカウントとコントラクトアカウントの分離、ノーガス取引のサポート不足、さまざまな暗号プリミティブのサポート不足など、多くのお荷物を残してしまいました。これらの歴史的なお荷物は、イーサネットのAAロードマップの実装に明らかな障害をもたらしており、イーサネットのAAソリューションは、そのアカウント・システムが後の新しいパブリック・チェーンを凌駕することを可能にするものではなく、両者のギャップを埋めるものに過ぎないとさえ言える。もしパブリックチェーンがアカウント設計を念頭に置いて最初に設計されていたら、イーサが取ったような回り道をする必要はなかったでしょう。
EVMチェーンとは異なり、Nervosはアカウントシステムを念頭に置いて設計されており、調査の結果、NervosのアカウントシステムはAAの基盤と性質により沿っていると考えています。そのUTXOアカウントモデルと、さまざまな検証方法をサポートするOmniLockは、最初から最後までAAの目標に深く沿っており、、歴史的なお荷物なしで、BTC、ETH、さらにはSolanaのような他のパブリックチェーンのアカウントシステムを本質的にサポートしています。
さらに、最近注目されているBTCFiの場合、BTCにネイティブであるように設計されています。BTCFiは、ビットコイン資産ネイティブのためのDefiのようなシナリオを導入しているため、ビットコインホルダーにとって、主流のビットコインウォレットやその他の周辺機器と互換性のあるシームレスな製品体験が必要であり、これはCKBのネイティブAAソリューションによって自然に実現され、BTCFiの大量導入に必要な条件を作り出している。
以下では、設計思想、システムアーキテクチャ、アプリケーション、エコロジーなど、多角的な観点からNervosのアカウント抽象化システムについて説明します。
ビットコインのUTXOとNervosのセルモデル
UTXOモデルに基づいていることは、ほとんどの人が知っています。データの保存構造は「アカウント・バランス」方式ではなく、独自の形式を採用している。具体的には、UTXOは金のように溶かしたり鋳造したりすることができ、取引のたびに古いUTXOは破壊され、新しいUTXOが生まれる。さらに、UTXOのデータは集中管理されたアドレスの下に保存されるのではなく、UTXOを生成したトランザクションの中に散在しており、過去のブロックの記録を読み取ることによってのみ見つけることができる。
推奨図書:「BTCへのアプローチ:BitVMを理解するために必要な背景知識(1)」
ビットコインは、従来のWeb2プラットフォームの「アカウント-メッセージ」システムとは一線を画すストレージパラダイムを生み出し、ステートフルな爆発やデータの非効率な読み書きの問題を解決していると言っても過言ではありません、これにより、状態の爆発、データの非効率的な読み書き、所有権の曖昧さといった問題を解決できる。UTXOモデルでは、異なる人々の資産データの保存場所と所有権が非常に明確で、並列性/並行性に優れ、ストレージリースやその他の機能をサポートすることも容易であるため、従来のアカウントシステムの多くの穴を回避することができる。
Nervosパブリックチェーンのアカウントシステムは、設計の初期段階からビットコインUTXOの利点を完全に吸収しており、そのCellモデルは実際にビットコインUTXOのアップグレード版であり、チューリング完全なプログラマビリティを提供しています。さらに、CKBとその他のアセットはどちらもファーストクラスのアセットであり、EVMパブリックチェーンのようにネイティブアセットとERC-20を区別して扱うことはありません。
CKBのCellは、ビットコインのUTXOとほぼ同じ方法で動作します:それは「ロックスクリプト」と「アンロックスクリプト」によって駆動されます。各UTXO/Cellは、コンビネーションロックのような「ロッキングスクリプト」と、ロッキングスクリプトのロックを解除する対応するキーである「アンロックスクリプト」で生成される。ロック解除スクリプト」は、「ロックスクリプト」のロックを解除する対応キーである。鍵をロックに提出しさえすれば、関連するUTXOは自由に使えるようになる。
しかし、ビットコインのUTXOとは異なり、Cellにはロックスクリプトがあります。strong>Cellはロックスクリプトの上に「TypeScript」フィールドを追加する。ロックスクリプトがCellを書き換える資格があるかどうかを判断する認証子だとすれば、TypeScriptはCellに付属するスマートコントラクトであり、貸し出しプロトコルであるDEXのコードはTypeScriptの中にデプロイすることができる。
開発者がCKBのようなAMM流動性プールを実装したい場合、DEXのコードはTypeScriptの中で展開できます。AMMのリクイディティ・プールを実装したい場合、必要なことは、専用のCellに対してTypeScriptでコントラクト・コードを記述し、このCellのDataフィールドにリクイディティ・プールのステータス情報(プール内の様々な種類の資産の残高など)を格納し、ユーザーがTypeScriptのコードと対話するだけです。
CKBのこの設計は、ビットコインのUTXOモデルを拡張して、よりプログラムしやすいリッチなシナリオを含むものであり、CKB自体がさまざまなプログラミング言語で書かれたプログラムをサポートするRISC-V仮想マシンを使用しているため、ビットコインよりもはるかに強力なさまざまなロジックをサポートすることができます。
CellのロックスクリプトであるLockScriptに関しては、今日の中心的なトピックであるAAに正対しています。なぜならば、AAが提唱する主な特徴の1つは、オンチェーンアカウントが柔軟で多様な認証方法をサポートできるようにすることだからです。UTXOの場合、これは認証装置として機能するLockScriptに取り組むことで達成され、CKBはこの目的のために特に複数の認証方式をサポートするOmniLockスクリプトを導入しました。
OmniLockの設計を見てみましょう。
OmniLockとアカウントの抽象化
CKBのCellは、ビットコインのUTXOとともに、ロックスクリプトによって定義されるアクセス権を持っていることを先に述べました。ロックスクリプトは、誰がCellを書き換えることができるかを決定し、認証の役割を果たします。複数の認証方法をサポートするため、CKBはOmniLockと呼ばれる汎用ロックスクリプトを提供しており、さまざまな署名アルゴリズムや検証メカニズムと互換性があります。
オムニロック(OmniLock)。異なる検証ロジックはモジュール化されているため、異なるパラメータを設定することで、異なる検証アルゴリズムを柔軟に構成することができます。ユーザーは、それぞれBTC、ETH、さらにはWebAuthnなどのアカウント、ウォレット、認証方法を使用して、CKBチェーン上の資産を直接操作することができます。
では、OmniLockは具体的にどのように実装され、使用されるのでしょうか?平たく説明すると、OmniLockはNervosがCKBチェーン上に直接敷設したコードの一部であり、特定のCellに書かれ、EVMパブリックチェーンの「システムコントラクト」のように他のCellで使用することができます。
ロックスクリプトとOmniLockがどのように機能するかを理解するための擬似コードを以下に示します。
CKBのロックスクリプトには、Codeハッシュ、ハッシュタイプ、Argsフィールドがありますが、このセクションとはあまり関係がないので、ここでは説明しません。ここでは、OmniLockで定義された異なる認証アルゴリズムを使用するように柔軟に設定できる、Argsフィールドに焦点を当てます。
Argsフィールドは2つの部分に分けられます。1つは認証専用のauthで、1バイトのフラグ識別子と20バイトの認証データを含む21バイト長である。authの認証データには、あらかじめ定義された公開鍵ハッシュが含まれており、その公開鍵ハッシュに対応する公開鍵の所有者のみが認証され、セル内のデータを書き換えることができます。
Authのフラグは、異なる認証方法を選択するための識別子です。これは暗号署名の検証だけでなく、メッセージ処理などの包括的な処理を含みます。認証方式を表します。Etherに加えて、OmniLockはBitcoin、Dogecoin、Tron、マルチシグネチャ、その他の豊富な形式のメッセージ認証もサポートしています。
argsの別の部分はOmnilock argsと呼ばれ、Omnilockの定義済みの機能モードを選択するボタンのような役割を果たします。とにかく、Omnilockの引数を微調整するだけで、OmniLockの様々な事前定義された機能を使用することができます。
まとめると、CellロッキングスクリプトのAuthとOmnilockのargsフィールドに異なるパラメータを入力することで、異なるパブリックチェーンやプラットフォームの認証方法を選択することができ、CKBに多種多様な認証方法を導入することができます。もちろん、OmniLockであらかじめ定義された認証方式に加えて、開発者は独自の認証方式を定義することもできます。
ナーヴォスのアカウント抽象化のエコロジー:CCC、Mobit、JoyID
上記で、OmniLockがNervosのアカウント抽象化の実装の基礎であること、Mobit、.bit、Omiga、ミドルウェアなどのOmniLockベースのウォレットがあることを学びました。CCC (Common Chains Connector)などのOmniLockベースのウォレットは、安全なプライバシー保護とID管理サービスを提供するDIDプラットフォームであるDid.id、分散型Dobs資産取引プラットフォームであるDobbyに加えて、Nervosの豊富なBTCFiアカウント抽象化エコシステムを構成しています。
AAの優れた機能は、BTCFiエコシステムのアプリにも大きな利便性をもたらし、CKBエコシステム内のプロジェクトがBTCウォレットのやり取りを直接サポートできるようにし、利用の敷居を下げています。以下では、具体的なケースカットを用いてCKBのAAエコシステムを検証してみましょう。
Common Chains Connector (CCC)
まずCCCを例にとると、これはウォレットやdAppsに各種パブリックチェーンの操作性をCKBに提供することに特化したウォレット接続ミドルウェアである。
下の画像はCCCの接続ウィンドウです。ここではMetaMaskを例に、Etherアカウントを持っている場合にCKBチェーン上の対応するアカウントを操作する方法を説明します。
CCCを使ってCKBチェーン上で取引を行う場合、デモはMetaMaskを呼び出します。デモでは、署名のためにMetaMaskウォレットのpersonal_sign メソッドを呼び出します。
メッセージにはCKBトランザクション用の一連の16進コードが含まれていることがわかります。MetaMaskによって署名された後、メッセージはNervos CKBチェーンに提出され、OmniLockのようなメカニズムを通して検証されます。
また、先に述べたように、Nervos自身はCKBの検証をサポートしています。Nervos自体がEtherメッセージフォーマットの検証をサポートしているので、CKBは他のパブリックチェーンエコシステムを下からドッキングすることを考慮したと言えます。
開発者にとっては、Nervosは底辺でOmniLock標準を定義し、CCCを通じてマルチチェーンウォレットの実装詳細を抽象化することで、開発の難易度を大幅に下げています。これにより、開発者は根本的な細部にあまり注意を払うことなく、ビジネスロジックの上位レイヤーに集中しやすくなります。
モビット
モビットはNervosベースのDIDおよび資産管理プラットフォームです。MobitはNervorsエコシステムへのゲートウェイであり、非常に障壁の低いゲートです。Mobitを使えば、ユーザーはほとんど予備知識を必要とせず、他のパブリックチェーン上のアカウントとNervosエコシステムでやりとりするために必要なのは、いくつかの簡単なアクションだけです。
下の画像はモビットの接続ウィンドウです。Mobitは現在、いくつかの主要なパブリックチェーンのアカウントシステムをサポートしており、そのリストは増え続けていることがわかります。
まだメタマスクウォレットを例にしています。接続後のインターフェイスには、ユーザーのEVMとCKBアドレスが表示され、CKBチェーン上のそのアドレスが保持するトークンとDOBs資産が表示されます。
DOBについて少し説明します。生態系に特化したNFTのような資産だが、DOBはNFTとは根本的に異なる。まず、多くのイーサリアムNFTがチェーン上にデータが保存されていないのに対し、DOBはチェーン上にデータが丸ごと保存されており、「フルチェーンNFT」と考えることができます。
さらに、各DOBはチャットボットを設定することができ、チャットボットは対話などを通じて保有者と対話することができます。保有者との対話などのインタラクションシナリオを実行することが可能で、保有者によって育成パスが異なるため、従来のNFTと比較して、各DOBはより大きな個人差を持つことになります。
NervosのエコシステムにおけるDOBの取引プラットフォームであるOmigaについては、ユーザーはMobitのAppsインターフェース上でワンクリックで直接ジャンプすることができます。
Omigaはまた、Nervosの口座抽象化機能を活用しています。アカウント抽象化機能を活用しています。
Mobitのシンプルさと包括的な機能性は、BTCFiの製品の本質を表しています。BTCFiの製品の本質は、ネイティブのビットコイン資産に多様なDefi体験を提供することであり、主流のビットコインウォレットとの互換性は、BTCFi周辺機器にとって重要な検討事項であり、CKBは今、その準備ができています。
WebAuthnの採用
WebAuthnは、W3C(World Wide Web Consortium)とFIDO(Fast IDentifier)によって開発された技術です。WebAuthnは、World Wide Web Consortium (W3C)とFIDO (Fast IDentity Online) Consortium によって開発されたウェブ標準です。ユーザー認証のセキュリティを向上させ、ログオンプロセスを簡素化し、従来のパスワードや秘密鍵への依存を減らすことを目的としています。
iOSやAndroidのような主要なデスクトップやモバイルのオペレーティングシステムには、鍵管理ソフトウェアが組み込まれており、ローカルのセキュリティモジュールやクラウドストレージを使用して鍵を保存し、署名することができます。NervosのOmniLockはカスタム暗号プリミティブをサポートしているため、これらをオーバーライドすることもできます。
以下は、WebAuthn がサポートするクライアントの一部です:
CKBエコ・ウォレット JoyIDは、WebAuthn技術を使って実装されたアプリケーションです。JoyIDを使えば、ユーザーは生体認証(指紋や顔認証など)を使って直接自分を認証することができ、シームレスで安全性の高いログインとID管理が可能になります。
Nervosエコシステムの.bitはまた、次のようなものです。アップルのWebAuthn実装を活用してログインし、ブロックチェーンを使用するシナリオ。
上記の例から、CKBのAAプログラムは、本質的に他のパブリック・チェーンやWeb2ユーザーをサポートしている。大多数のWeb2ユーザーにとって、WebAuthnのサポートは非常に重要です。秘密鍵とヘルパーの管理というお荷物を取り除き、利用の敷居を大幅に下げることができるからです。この方向性を推し進めるパブリックチェーンのエコシステムが早ければ早いほど、この先より有利になるでしょう。
まとめ
イーサリアムはその過去のお荷物によって制約されており、既存のAAソリューションは基本的に症状を治療しますが、問題の根本原因は治療しません。strong>Nervosは、メインネットワークの立ち上げ当初からアカウントシステムの設計を十分に考慮し、どのような認証方式にも対応できるオムニロック機能を提供してきた。
NervosのCellモデルは、基本的にビットコインのUTXO機能を拡張したもので、さまざまな署名検証アルゴリズムをサポートするロックスクリプトを備えています。OmniLockはシステム契約に似ており、ロックスクリプトで直接呼び出される任意のCellをサポートし、開発者とユーザーにWeb2.0プラットフォームを提供します。
CCC、Mobit、Joyid、およびその他の製品は、Nervosのアカウント抽象化エコシステムですでに利用可能であり、基本的に完成しています。
Nervosのアカウント抽象化エコシステムは、Nervosのエコシステムですでに利用可能です。align: left;">BTCFiの本質は、ネイティブビットコインアセットに多様なDefi体験を提供することであり、主流のビットコインウォレットと互換性を持たせることができるかどうかは、BTCFi周辺施設において考慮すべき重要な要素となり、CKBはBTCFiエコシステムの重要な施設として、開発者側とユーザー側の両方において、可能な限りBTCFiの大量導入に必要な条件を整えるために包括的なアプローチを採用しています。大量採用。