原題：「A&T View: ネットワーク全体における DID トラックの最も詳細なレビュー + DID の魂に関する 3 つの質問」
著者: Lin Chuan、A&T Capital シニア アナリスト
まとめ
まとめ
DID は現在一般的に「Decentralized Identity」（分散型アイデンティティ）の略称であり、中央集権的な組織による最終保証のないデジタルアイデンティティであり、Web2 における「ユーザーポートレート」の概念を Web3 において拡張・拡張したものです。
DID 関連のトラックは主に、アプリケーション シナリオ、ID、資格情報の 3 つの層に分かれています。資格情報層は DID のコンポーネントであり、アイデンティティ層は DID の特定の形式であり、アプリケーション シナリオ層は DID の価値を具体化したものです。
DID 開発の最終形態は、各ユーザーがネットワーク全体にわたる一意の ID と、複数の細分化されたシナリオで部分的な ID を持つことになる場合があります。ユーザーはドメイン名を通じて DID を記憶および識別し、DID を管理し、ウォレットを通じてアプリケーション プロジェクトと対話し、ウォレット統合のさまざまなプロトコルを通じて複数のチェーン上の異なる認証情報と部分 ID を統合します。
DID は現在、ユーザーの直接の要求ではなく、アプリケーション シナリオ プロジェクトの関係者からの要求がより多くなっています。
DID の開発はまだ初期段階にあり、その反復は比較的遅いです。これまでのところ、特定のネットワーク効果を蓄積した DID システムはありません。これは主に、現在の Web3 非金融アプリケーション プロジェクトの開発が困難であるためです。
DID の第 1 レベルの投資の全体的なロジック: ユーザーから始まり、アプリケーションが契約の前にあります。
序文: DID、広く使用され、悪用される概念
DID は、Web3 分野で人気のある概念です。 Twitter には、ほぼ毎週 DID について議論する Twitter スペースがあります。さまざまなオフライン Web3 共有セッションでも、DID は常にホットなトピックの 1 つです。プロジェクトの資金調達デッキでは、ソーシャル、GameFi、DeFi、NFT のいずれであっても、他のアプリケーション プロジェクトや、ウォレット、ドメイン名、さらにはパブリック チェーンなどのインフラ/ミドルウェア プロジェクトは、そのストーリーに DID を追加する可能性があります。
ただし、これほど高い人気があるため、必然的に DID という用語が広く使用され、さらには乱用されることになります。
当初、DID の正式名称は「Decentralized Identifiers」で、直訳すると「分散型識別子」となります。これは、Web2 集中 ID システムに対する懸念から、最も影響力のある国際インターネット技術標準化団体である World Wide Web Consortium (W3C) が主導した一連の標準です。 DID の概念は当初ブロックチェーン/Web3 に直接関連していませんでしたが、「DID」を直接検索すると、多くの記事で説明されている DID がこの特定の標準であることがわかります。
現在の Web3 コミュニケーションでは、DID は「分散型 (デジタル) アイデンティティ」を指す「Decentralized Identity」の略語としてみなされることが多くなっています。しかし、分散アイデンティティ自体も明確な定義が欠けている語彙でもあり、一見すると誰でも大まかな意味は理解できるものの、場面によっては別のものを指すこともあり、Web3の世界では何でも関係ありそうな感じがします。それに。これが、DID に関する現在の議論に概念的な混乱が非常に多い理由です。
この記事で次に説明する DID は、後者の「分散型デジタル ID」の概念を採用し、混乱を避けるために W3C の分散型識別子標準を参照するために DID を使用します。
この記事は前編と後編に分かれています。最初の部分では、著者はアプリケーション シナリオ層、アイデンティティ層、およびデータ層に分け、読者がさまざまな概念間の違いと関連性を理解できるように DID トラックを体系的にレビューします。後半では、著者は次のことを行います。読者が考え、コミュニケーションできるように、DID トラックの将来の開発と初期投資に関する主観的な見解を説明します。
前: 分散型アイデンティティ (DID) トラックのパノラマ解釈
Web2 では、デジタル アイデンティティはプラットフォームを中心としており、同じグループ内のさまざまな製品がアカウント システムを通じて接続されています。たとえば、Tencent のメールボックス、ゲーム、金融などはすべて同じアカウントを使用でき、Google、Facebook、その他の大手インターネット企業も独自のアカウント システムを持っています。この ID システムは構築には便利ですが、その欠点はよく知られています。プラットフォーム間のアカウントは相互運用できず、ユーザーは自分の ID データを制御する方法がありません。
現在の Web3 では、ユーザーのインタラクションは主にウォレット アドレスに基づいているため、アドレスを中心とした一連のアクティビティが Web3 の最も独創的なデジタル アイデンティティを構成します。しかし、新しいアドレスを作成するコストはほとんど無視できるものであり、アドレスに縛られる人はほとんどいません。これにより、ユーザーはいつでもアドレスによって表される「アイデンティティ」を放棄でき、コストゼロで多数のアドレス「アイデンティティ」を作成することもできるため、このデジタルアイデンティティの適用シナリオが制限されるという事実が生じました。 。
DID が解決したいと考えている問題は、分散型デジタル世界で個人のアイデンティティの描写を構築することです。
1. DID の適用シナリオ: すでに完成した DID セットがある場合...
DID は抽象的な概念です。それをより直感的に理解するために、アプリケーション シナリオから始めて、DID の実装方法の詳細を保護しましょう: Web3 の世界にすでに成熟した DID セットがある場合、何ができるのかそうですか？
著者はアプリケーションシナリオ層におけるDIDのナラティブをReputation（評判）とRelationship（関係性）の2つに大別します。
それらを区別する主な方法は、既存の「デジタル アイデンティティ」を放棄する場合、比較的短期間で自分を表現できる新しいアイデンティティを再構築できるかどうかを想定することです。
前者の場合は Reputation クラス、後者の場合は Relationship クラスです。
1.1 評判: 評判/履歴書/社会的存在
このタイプのアプリケーション シナリオは、迅速なスクリーニング効果を達成するために、デジタル ID をいくつかの明示的で信頼できるラベルに単純化することによってユーザーを評価および分類することに重点を置いています。具体的な例を 3 つ挙げます。信用貸し、就職活動、見知らぬ人との交流です。
Web3 クレジット ローンは、ユーザーのアカウント アドレスに「クレジット スコア」を付与して、クレジット ローンの減額または免除できる金額を計算することを目的としています。この種の信用スコアは、オフチェーンの ID/資産証明を通じて達成することも、ユーザーのオンチェーン アドレスの過去の操作記録の分析と組み合わせることもできます。
Web3 の就職活動や人材採用において、ユーザーの履歴書をチェーン上で生成できるようにすることで、ユーザーが Web3 プロジェクト パーティ/DAO/コミュニティなどに対して自分の能力を迅速に証明できるようになり、Web3 ジョブにおける情報の摩擦を軽減できることが期待されます。狩猟と採用のプロセス。履歴書における職歴と Web3 能力の証明は、オンチェーン アドレス分析、元所有者のマルチシグネチャ ウォレット アドレスの署名、および Web2 企業電子メール認証を通じて行うことができます。
Web3 Stranger Social (異性愛ソーシャル、関心ソーシャルなどを含む)。ユーザー向けのタグ説明を迅速に構築したいと考えています。この種のラベルの説明は、NFT の保有に依存する場合があり、たとえば、BAYC の保有者には「富裕層」というラベルを付けることができ、さまざまな関心やコミュニティ NFT の保有者にもそれに応じてラベルを付けることができます。ユーザーはこれらのタグを統合し、ソーシャル ホームページに配置して表示することができます。ユーザーは、これらのタグに基づいて交流したいオブジェクトをすばやくフィルタリングし、自分の興味や好みを事前に理解することもできます。
1.2 関係: DID のリレーショナル アプリケーション シナリオの説明
このタイプのアプリケーション シナリオは、デジタル ID を Web3 のユーザー データの蓄積として扱うことにより、より複雑で包括的なアプリケーション分析を行うことに重点を置いています。関連する具体的な例を 4 つ挙げます。
Web3レコメンドシステムは、Web3関連のユーザーデータを蓄積することでユーザー像を形成し、ターゲットを絞ったパーソナライズされたレコメンドや広告表示を行うことを目指している。この一連のユーザー ポートレートの物語は、実際にはモバイル インターネット時代のプラットフォーム メーカーの中核ロジックから継承されており、実現可能であることが証明されています。また、Web3 では、アイデンティティ データがプラットフォーム間で相互運用できるだけでなく、ユーザーは自分のアイデンティティ データの所有権とオープンな共有権限も持つことができ、このように構築されたユーザー ポートレート システムは、Web2 よりも使いやすいものになる可能性があります。
Web3 知人ソーシャル インタラクション。Web3 でのユーザーのソーシャル インタラクションの蓄積を通じてユーザーの一連のソーシャル グラフを形成し、さまざまな新しいアプリで使用できることを目指しています。このようにして、ユーザーは新しいアプリケーションを使用したり、新しいゲームに参加したりするときに、Web2 のように再度追加することなく、知人や友人をすぐに見つけることができます。
Web3 ゲームでは、Web3 ゲームにおけるユーザーのデータの蓄積を通じて、ゲームに対するユーザーの興味や能力を記述するゲーム アカウント システム (GameID) を構築することが期待されています。たとえば、ユーザー A が特定の Web3 カード ゲームに非常に早期に参加した記録を持っている可能性があり、これらを GameID に記録できるため、新しいカード ゲームが早期のユーザーを見つけたい場合に、A を優先することができます。
DAOの投票ガバナンスでは、「1人1票」の公正な投票を行うことを望む場合がある。しかし、投票をスワイプするために複数のアカウントを登録する (シビル攻撃) のではなく、人が 1 回だけ投票することをどのように証明するかは、難しい問題です。この問題は、ユーザーのアドレス履歴の解析や本人認証によって解決できます。
1.3 2 種類のアプリケーション シナリオ間の接続: 点から面、そして面から点へ
実際、Reputation アプリケーションと Relationship アプリケーションの関係はそれほど明確ではなく、ネットワークのような関係です。
より正確に言うと、さまざまな明示的で信頼性の高いタグは「ポイント」のようなものです。時間が経つにつれて、これらのポイントは同じアイデンティティの周りに蓄積され、最終的にはユーザーまたはプロジェクト関係者が本当に望むときに、ユーザーのポートレートに関する完全な「顔」を生成します。この「面」を使用するには、それを説明して理解しやすいいくつかの「点」に単純化するためのさらなる処理が必要です。
例えば、NFTの保有数に関しては、初期の頃はBAYC保有者やあずき保有者などのタグ付け（ポイント）のみでしたが、時間が経つにつれ、人気の高いNFTが登場するたびにタグ付け（ポイント）されるようになります。 、このユーザーは取引に参加します（面）、帰納的分析を実行して、彼を「人気のNFTトレーダー」（ポイント）としてラベル付けできます。
上記は基本的に、アプリケーション シナリオ レベルでのすべての DID ナラティブの要約です。基本的に Web3 アプリケーション層のほぼすべての説明をカバーしていることがわかります。これが、DID が Web3 アプリケーションの「アイデンティティ インフラストラクチャ」とも呼ばれる理由です。
2. 元のデータ形式と認証情報: DID を構成する属性はどこから来たのか?
読者は、さまざまなアプリケーション シナリオに関する上記の説明で、各デジタル アイデンティティが実際には異なるものを参照していると感じたかもしれませんが、それらはすべて「DID」と呼ぶことができます。ここには、実際には 2 つの重要な問題があります。
この「分散型アイデンティティ」は、具体的にどのようなラベル/属性/資格情報で構成されていますか?たとえば、接続したいのは、ユーザーのNFT保有物、オンチェーンのインタラクション記録、またはユーザーの社会的関係、またはオフチェーンのユーザーのアイデンティティ情報ですか?
この「分散型アイデンティティ」は、どの識別子 (識別子、ID) に基づいて集約されているのか、あるいは外部との対話のための主要なインターフェイスは何ですか?たとえば、ID を表すために NFT、アドレス、またはドメイン名を使用しますか? ID を使用してアプリケーション側と対話するにはどうすればよいでしょうか?
これら 2 つの問題を明確にすると、DID の ID 層でのさまざまで複雑なプロジェクトが明確にわかります。
最初の質問、DID を構成する属性が正確にどこから来たのかを考えてみましょう。
2.1 資格情報: 分散型 ID にとって資格情報が重要なのはなぜですか?
まず次の例を見てみましょう。あなたは新しい人に会い、その人はこう言いました。「私は張三です。1990 年生まれで、北京大学を学士号を取得して卒業しました。あなたのお父さんのことをよく知っています。」彼はあなたに何かを求めていますが、何らかの理由で、あなたは彼の自己紹介に大きな不信感を抱いています。それでは、彼は自分の言ったことの真実性をどうやってあなたに証明すべきでしょうか？
彼が自分の名前と年齢を証明したい場合は、身分証明書を提示できますし、身分証明書が自分のものであることを証明するためにあなたと一緒に警察署に行くこともできますし、学歴を証明したい場合は、身分証明書を提示することもできます。 ID カード 卒業証明書、または Xuexin.com から送信された証明書。彼があなたの父親をよく知っていることを証明したい場合は、父親に連絡して説明してもらうことができます。逆に、彼があなたに尋ね、自分の身元を証明したいと思っているのに、あなたが要求したときに上記の具体的な証拠を提供しなかった場合、あなたには彼の発言の信頼性を疑う十分な理由があります。
したがって、アイデンティティは、名前、生年、教育、社会的サークル、および先ほどの張三の独り言に関係するその他の属性など、多くの属性で構成されていることがわかります。ただし、対応する特定の資格情報がなければ、これらの属性には信頼性がなく、ほとんどのアプリケーション シナリオでは、信頼性がなければデジタル ID は採用されません。 Web3 では、アイデンティティの属性のソースがより多様になり、潜在的なユーザーがより広範囲になるため、集中的な一般保証人を見つけることが困難になり、各属性の資格情報の検証がより重要になります。
2.2 バウチャーのオリジナルデータソースの分類
したがって、DID の特定の構成を調査するときは、実際には特定の資格情報に焦点を当てます。
ユーザーのオンチェーン データは、基盤となるブロックチェーンの改ざん不可能な性質により、認証情報データの最も自然で直観的なソースとなります。この種の信頼でも、特定の証明書発行者を必要とせず、基礎となるパブリック チェーンのみに基づくことができます。たとえば、ウォレット アドレス A が実際にウォレット アドレス B に送金したことを証明するには、チェーン上の対応する情報を確認するだけで済みます。証明書発行者を伴わないこの種の信頼は、他の証明書データ ソースでは利用できません。また、これはブロックチェーンの中核的な魅力の 1 つでもあります。チェーン上のデータを統合分析する Web3 ツール製品は数多くあります。
ただし、現在のWeb3の世界では、オンチェーンデータは主に転送、DeFiインタラクション、NFTトランザクション/保有で構成されており、それがもたらすことができるID情報は限られています。ただし、現実の世界では、多くの場合、証明書を信頼するための前提条件は証明書の発行者を信頼することですが、この信頼関係の確立は Web2 または現実の世界で行われます。多くの場合、運転免許証など、検証プロセス全体をチェーン上に置くことは困難です。デジタル化されていても、テスト自体は依然として現実の世界で行われます。
現在、Web2 および現実世界のデータと信頼関係を信頼できる認証情報にするための主な形式は、SBT、VC、PoP の 3 つです。
2.2.1 ソウルバウンドトークン (SBT)
SBT (Soul Bound Token)、または Soul Bound Token は、2022 年 5 月に Vitalik らが発表した記事「分散型社会」で詳述された新しい概念です。
現在、SBTには共通の明確な規格が存在しないため、実際には現在のSBTは単にNon-Transferrable Token、つまり「譲渡不可能なトークン」として理解することができます。実際、このようなトークンの形式の資格情報は、POAP や Project Galaxy によって発行されたものなど、すでに存在しています。
SBT の実装は最も単純であり、当然ながら非常に優れた相互運用性とオープン性を備えています。また、SBT はチェーン上でネイティブであるため、オンチェーン信用スコアリングなどのオンチェーン データ分析手法の「結果証明書」としても使用できます。
SBT の主な問題は、そのオープン性によって引き起こされるユーザーのプライバシー関連の問題です。ミナミマグロの公共性により、誰でも簡単に個人を連想したり推論したりすることができ、プライバシーが不可能になり、ある種の差別が助長される可能性があります。たとえば、人種差別主義者の雇用主は、求職者の財布を覗くとBlack Lives Matterのイベントが明らかになったために、潜在的な従業員を差別する可能性があります。
理論的には、ZK テクノロジーと SBT を組み合わせることで、ユーザーのプライバシー保護を実現できます。しかし、これは特定の技術的実装にいくつかの困難を伴うだけでなく、SBT のオープン性と相互運用性に影響を与える可能性があります。
2.2.2 検証可能な証明書 (VC)
Verifiable Credentials、直訳すると「検証可能な証明書」。
この記事の冒頭で述べたように、ブロックチェーンがなかった頃、デジタル世界での分散型アイデンティティについて考える人が現れましたが、VC も W3C が提案する概念および標準体系の一部です。
次の国際運転免許証認証の例を通して、VC を直感的に理解してみましょう。
ドイツ人のハンスが運転免許証を取得すると、分散型識別子 (DID) を使用した VC の発行と署名をドイツ政府に申請できます。この VC は、ハンスが運転免許証を取得するための証明書であるデジタル文書の形式で存在し、ハンス自身が保管しています。
ハンスがオーストラリアに行って自動運転ツアーを開始する場合、運転免許証を提示する必要がある場合、ドイツ政府職員から取得したVCをオーストラリア政府に提示できます。オーストラリア政府職員は、ドイツの公的身分証明書が署名したこのデジタル文書を見ました。以上の情報から、ハンスには運転能力があると考えられます。
ただし、厳密に言えば、VC の特定の記述には W3C によって定義された一連の標準があり、その中の分散識別子も W3C システムの DID です。しかし、Web3 の観点から見ると、この分散型識別子を広義のウォレット アドレスに置き換えることは論理的に可能であり、次の図はユーザー、VC 発行者、VC 検証者の間の関係を示しています。
SBTと比較すると、VCの主な利点はユーザーのプライバシーの保護にあり、ユーザーは自然に自分の情報を選択的に開示できることがわかります。さらに、その実装はブロックチェーン技術とは無関係であり、Web2 との互換性も優れています。
VC の主な問題は、VC には比較的認知された一連の標準があるにもかかわらず、この一連の標準には DID (詳細は以下を参照) のサポートが必要であり、DID の進歩が比較的遅いことです。プロジェクト当事者や Web3 コミュニティが一連の VC 運用プロセス標準を設定したい場合、この標準をどのように推進するかも難しい点になります。
2.2.3 人格証明 (PoP)
本人証明。主に行うべきことは、実際の人物の情報をチェーンの下にバインドすることによって、デジタル ID の一意性を証明することです。その代表的なプロジェクトが Proof of Humanity、BrightID、IDENA です。
具体的な実現は主にKYCとビデオ顔認識の2つの技術によって行われます。 KYC は取引所で一般的な古典的な認証方法です。KYC を通じて、デジタル ID はチェーンの下で法人情報 (名前、国籍など) に関連付けられます。BrightID などの顔認識は主に顔情報を使用します。データベースを使用して、ユーザーがプロジェクト ID システムに 1 つの ID のみを登録できるようにします。
PoP 認証の最も直接的な適用シナリオは、反 Sybil 攻撃であることがわかります。また、各国が仮想通貨の規制を検討していることを背景に、「法的身分」の確立にKYCが必須条件となる可能性もある。
2.3 バウチャーの関連アイテム
分散型デジタル ID の具体的な構成は非常に複雑ですが、最終的には主にチェーン上のオリジナルデータ、SBT、VC、PoP の 4 種類の認証情報で構成されていることがわかります。
厳密に言えば、SBT もチェーン上の元のデータの一部ですが、SBT は何らかの方法で再処理する必要があり、その信頼は発行者に依存する可能性がありますが、チェーン上の元のデータの信頼は基礎となるデータにのみ基づく必要があります。パブリックチェーンの信頼。
資格情報に関連する Web3 プロジェクトの具体的な種類は何ですか?
ほとんどの場合、多くの証明書の認証ルールは高い相互運用性を備えています。たとえば、ユーザーがチェーン上のトランザクションを完了したかどうかの検証、ユーザーがプロジェクト関係者の Twitter の転送に協力したかどうかの検証、またはユーザーの背後にいる本人が本物であるかどうかの検証などです。最初に資格情報の取得を試みます。この文脈では、証明書の発行者自体が証明書を発行するためのツールのセットを作成する必要はありません。
したがって、このセグメントの多くのプロジェクト タイプは、実際には証明書発行のためのツール/プラットフォームです。 Project Galaxy を例に挙げると、プロジェクト当事者は Project Galaxy 上でタスクを公開でき、ユーザーはプラットフォーム上でタスクを完了して認証を行った後、プロジェクト当事者によって発行された資格情報を取得できます。
ただし、一部の複雑な状況では、特に評価が一定の程度に左右される複雑なシナリオでは、証明書の発行者がユーザーを認証するための独自のルールを設計したいと考えています。前述の個人証明証明書も証明書発行プロジェクトに分類できます。
他の例は次のとおりです。
Rabbithole は「学習認証」プロジェクトの代表的なもので、ユーザーがより複雑なタスクを完了する必要があるさまざまな Web3 タイトル (NFT Creator、Explorer など) の認証を提供します (ある程度、ロジックとオンライン ネットワーク)。コース修了の割合も非常に似ており、Rabbithole は「Web3 オンライン教育」のプロトタイプとも言えます。
ARCxは、各DeFiパスポート所有者の信用スコアに基づいて、オンチェーンアドレスの信用度を定量化したいと考えています。クレジット スコアは、所有者のイーサリアム アドレスの履歴アクティビティを分析することによって決定され、その範囲は 0 から 999 ポイントに設定され、プロトコルによってユーザーに提供される住宅ローン金利が決まります。信用スコアの高い住所の場合、DeFi Passport は競争力のあるローン担保を提供できます。
FirstBatch は、AI を使用して Web2 ソーシャル メディア上のユーザー認証データを読み取ってチェーン上にユーザー興味タグを生成し、プライバシー保護に ZK テクノロジーを使用したいと考えています。
3. ID レイヤー: アプリケーション シナリオと資格情報の接続、特定の DID フォーム
DID の特定のアプリケーション シナリオについて説明し、DID ID 資格情報の具体的な構成についても説明しました。ユースケースと認証情報を結び付けるのは、アイデンティティ層プロジェクトの役割です。たとえば、ドメイン名、ウォレット、ソーシャル グラフ、アドレス関連付け分析などです。
プロジェクトが ID 集約を行っているかどうかを区別するにはどうすればよいですか?ここで著者は判断方法を提案しています。プロジェクト (またはプロジェクト モジュール) が、特定のユーザー指向のシナリオで DID を使用せず、ユーザーの新しい認証情報も生成しないことを行う場合、主に行うべきことはさまざまな「バインディング」です。 「fixed」と「connected」の場合、ID アグリゲーション レイヤーのアイテムである可能性が高くなります。
ただし、Web3 ID 集約をどのように行うか、プロジェクトの種類が異なれば、道筋や考え方も異なります。これらは大きく 2 つのカテゴリに分類できます。1 つはチェーン上の生データとさまざまな認証情報の処理と集約、もう 1 つはユーザー指向でユーザーによるデータ主権の実現を支援する ID 管理ツールです。
3.1 情報集約プロトコル
チェーン上のユーザーのデータは、多くの場合、複数のパブリック チェーンや複数のプロジェクトのスマート コントラクトに分散しているため、ID を形成するには処理および集約する必要があります。多くのプロジェクトがこのような情報集約プロトコルを実行しています。
これらの契約には直接ユーザー向けの製品は含まれていないことが多く、主にプロジェクト関係者やその他の契約向けであり、情報集約において相互に協力することができます。例は次のとおりです。
サイバーコネクトは、ユーザーの社会的関係データを集約して、オンチェーンのソーシャル グラフを構築したいと考えています。
KNN3 ネットワークは、フットプリント関連分析、サイバーコネクト、その他のソーシャル グラフの統合を通じて、複数のチェーン上にユーザーの社会関係グラフを構築したいと考えています。
RSS3 はチェーン上のコンテンツとソーシャル情報の集合体となることを期待しており、Web3 の情報配信および推奨システムの方向に発展する可能性があります。
以下のタイプの ID 管理ツール プロジェクトはすべて、ユーザーがデータ主権を実現するための直接ツールである、アクティブな ID 管理機能をユーザーに提供することを目的としています。
3.2 ID管理ツール - ウォレット
ウォレットはユーザーに直接向けられており、現在では「Web3の入り口」として認識されています。これ自体は DID アプリケーション シナリオであるとは言えませんが、アプリケーション シナリオとユーザー資格情報を接続する自然なチャネルです。
理想的な「DID ウォレット」は次のようになります: まず、すべての主流パブリック チェーンのアドレスを集約し、基本的な署名、転送、その他のトランザクションを持ちながら、異なるチェーン上のユーザーの断片化されたデータを統合できます。次に、さまざまなトランザクションを表示できます。ユーザーが所有する SBT/VC/PoP 資格情報: アプリケーション プロジェクトと対話するときに、ユーザーはプロジェクトにどのデータを開示するかを独立して承認できるため、ユーザーはデータ主権を実現できます。 Unipass、ABT Wallet、Selfkey など、多くのウォレットで DID の物語が言及されています。
しかし、Metamaskなど現在主流のウォレットにはこれらの機能はありません。重要な理由は、これらのウォレットは基本的に EOA ウォレットであり、基本的にチェーン上のアドレスの最もネイティブな操作 (クエリと転送) のみをサポートしていることです。スマートコントラクトウォレットは、ウォレット機能のさらなる拡張が期待されています。実際、DIDウォレット関連テクノロジーの実装には多くの課題がありますが、非常に期待する価値もあります。
3.3 ID管理ツール - ドメイン名
私たちはそれぞれ固有の ID 番号を持っていますが、日常生活では、個人のアイデンティティを識別するものとして (重複する名前があるかもしれませんが)、日常のコミュニケーションに便利な「名前」を使用することが一般的です。
Web3 の世界にもこの問題があります。現在の人々のやりとりは主にウォレット アドレスに基づいていますが、誰もその長い文字列を覚えようとはしません。 Web3 のデジタル アイデンティティに「名前」が必要な場合、ドメイン名プロジェクトが行うことは、この「名前」になることです。
ENS は、このドメイン名で最もよく知られたプロジェクトであり、イーサリアム財団の公式サポートを受けて、.eth 接尾辞が付いたドメイン名の登録サービスを提供しており、現在、約 180 万件の登録があります。 SpruceID が ENS と協力して EIP-4361: Sign In With Ethereum を推進していることは注目に値します。この提案がうまく実装されれば、Connect Wallet が置き換えられ、ドメイン名がウォレット アドレスの上にある Web3 の入り口になることが可能になります。さらに、ENS は、ドメイン名に一連の ID を統合することで、「Web3 名」のビジョンを完成させたいと考えています。
注目に値するもう 1 つのドメイン名プロジェクトは Space ID です。これは Binance によって公式にサポートされており、接尾辞 .bnb を持つドメイン名の登録サービスを提供します。 Space ID はまた、.bnb ドメイン名とさまざまなチェーン上のユーザーの複数のアドレス、さらにユーザーの Twitter やその他の Web2 アカウントを識別して、Web3 分野のユニバーサル名になることを望んでいます。 ENS と比較して、Space ID の製品の反復速度と着陸速度は速くなります。
ENSとSpace IDに加えて、.bitとUnstoppable Domainも最近比較的多額の資金調達を完了した。彼らが DID について語る物語は基本的に同じです。
ドメイン名とウォレットはどちらもアイデンティティ管理ツールとして使用できますが、その役割は大きく異なることに注意してください。これらは理論的には矛盾しませんが、密接に連携できます。ウォレットはドメイン名をウォレットのアカウント名の代わりに使用し、アプリケーションと対話するときにそれを「名前」として使用できます。ドメイン名は複数のドメイン名を統合することもできます。チェーン上のアドレス、または複数のウォレットアカウントでも可能です。
3.4 その他のアイデンティティ管理ツール - Next.ID を例に挙げます
アイデンティティ管理製品もいくつかあります。アイデンティティ管理実装の具体的な理解はこれまでのプロジェクトとは異なりますが、作業の中心は主にさまざまな接続と集約であり、特定の分野に限定されないネットワークを構築したいと考えています-幅広いアイデンティティを統合します。 Mask Network が作成した新しい ID 管理製品である Next.ID を例に挙げてみましょう。
ユーザー指向ではない ID 集約プロトコル プロジェクトとは異なり、Next.ID はユーザー指向の製品です。 V1 バージョンでは、ユーザーはマスク ネットワークを使用して Web2 プラットフォーム アカウントと Web3 パブリック チェーン ウォレット アドレスの接続と集約を実現し、アクティブな ID 管理を実行できます。ドメイン名や DID と比較して、Next.ID も集約されています。統一されたデジタル ID では、明示的な識別子は強調されていませんが、ID が集約された後、アプリ呼び出しのインフラストラクチャにされることが期待されています。 Next.ID が独自のドメイン名を宣伝したり、マスク アカウントのユーザー名などの識別子を宣伝し始めた場合、その内容は、Space ID や ENS などのドメイン名プロジェクトとある程度重複することになります。
ただし、ユーザー側での集約に加えて、開発者は Next.ID のアバター システムを使用して、次の図に示すように、製品内のユーザー アカウントの特定の操作と Next.ID の間の相互運用性を実現できます。これにより、多くのことが可能になります。ある程度、アイデンティティ集約プロトコルが実行したいことを、これらのプロトコルと連携して再度集約することも選択できます。
出典: Next.ID 公式ドキュメント
3.5 ローカルシーンのアイデンティティ管理ツール
3.5.1 GameID
ネットワーク全体でユーザー データを集約することを目的としたいくつかの ID 管理ツール プロジェクトに加えて、ローカル シナリオに基づいて ID 管理ツールを作成するプロジェクトもいくつかあります。
わかりやすい例としては、昨年流行した Loots など、チェーン上のさまざまなゲームに関するユーザー情報を集約する GameID があります。
GameID の ID は、Web2 の Shanda アカウントや QQ アカウントに似た、エコシステム内で通信するアカウント システムを指します。彼らは、エコシステム内のユーザーの特性を記述するだけであり、ユーザーを代表するものではありません。大規模な集合体です。ネットワーク全体にわたるデジタル ID の管理。
したがって、これは DID であると言うよりも、ユーザーの DID の部分的な断片、パズルのピースであると言った方が適切です。
たとえば、Zhang San はドメイン名 zhangsan.eth を登録し、彼の "Shanda" ID は 123456 で、これにはさまざまな "Shanda シリーズ" ゲーム プロジェクトからの 5 つの証明書が含まれ、彼の "Tencent" ID は 567890 で、これには Tencent からの 9 つの証明書が含まれます。シリーズ」ゲームプロジェクト認定証。したがって、「Shanda」と「Tencent」は、ユーザーが対応するプラットフォーム アカウントを管理できるようにするための専用の ID 管理ツールを備えている可能性がありますが、それらはすべて zhangsan.eth の「Web3 名」によって集約され、zhangsan.eth の ID の一部になる可能性があります。 . ラベル。
3.5.2 DIDs
長年の研究と議論を経て、W3C はついに 2022 年 7 月に分散型識別子 (DID、分散型識別子) の正式な標準 v1.0 を発表しました。 「DID」の最初の定義として、W3C の DID と現在の Web3 DID システムとの関係を明確にする必要もあります。
W3C 標準の分散型識別子アーキテクチャでは、ユーザーは識別子と対応するドキュメントを直接制御します。 APP は、ビジネスを実現するためにユーザーの許可を得て、署名や暗号化されたデータなどのデジタル ID 関連情報を含む DID にリンクされたドキュメントを読み取ることができます。ユーザーは暗号署名を通じて DID の所有権を証明します。ユーザー データは信頼できるデータベース (ブロックチェーンなど) に保存され、ID データは APP に依存しません。
次の図に示すように、DID には 3 つのコンポーネントがあります: DID スキーム (http、ipfs、およびその他のメソッド宣言に似ています)、DID メソッド (特定のメソッドの識別子)、DID アイデンティティ システムを構築したい各プロジェクトは 1 つを申請できます。たとえば、Tencent は QQ の tencentqq 識別子を申請できます。DID メソッド固有の識別子は特定の ID であり、その使用は特定のプロジェクト パーティの定義によって異なります。たとえば、Tencent は、did:tencentqq:123456789 を使用して、 QQ番号123456789。
DID の詳しい操作手順や技術的な内容は比較的複雑なので、ここでは詳しく紹介しません。
DID は Web3 ドメイン名とある程度競合します。DID とドメイン名の主な違いを以下に比較します。
可読性の点では、DID はドメイン名と比較してユーザーレベルの可読性に欠けていますが、DID メソッドの存在により、セマンティクスの層が追加され、柔軟性が向上します。
情報集約の可能性という点では、DID は VC などの検証手法と組み合わせることで、理論的にはより多くのオフチェーン情報、特に権威ある組織が提供するデジタル証明書を集約できます。現在、ドメイン名プロジェクトのデータ集約は依然として次の情報に基づいています。 -chain 情報ベース。より適切なオフチェーン情報の集約が必要な場合は、一致する VC 標準が必要になる場合があります。
データ ストレージに関しては、DID のデータ ストレージは指定されておらず、パブリック チェーンまたは一部の分散データ ネットワーク (セラミック ネットワークなど) に直接保存でき、さらにはユーザー自身のために直接保存することもできます。のドメイン名プロジェクトのストレージはすべてオンチェーンです
全体として、DID システムはトップダウン設計であり、より包括的で互換性の高い標準です。オントロジーなど、デジタル アイデンティティを実現するために DID ルートを採用するプロジェクトも数多くあります。
しかし、DID はユーザーの可読性が低いため、長期的にはユーザーが日常生活で覚えている「Web3 名」になることは困難です。また、ユーザーはさまざまな DID メソッドで異なる DID を持つことができ、DID が異なる場合があります。これはドメイン名によって集約されたオブジェクトである可能性があるため、「セグメント化されたシナリオ/ローカル ID 管理用の識別子」と呼ぶことができます。また、理論的には DID はオフチェーン情報との互換性が高いものの、利益を考慮して現在の Web2 企業が DID に基づいて適切な推奨を行うことはほとんどなく、DID をどのように推進するかも問題となっています。
3.6 ID 管理ツール: ネットワーク全体の ID と部分的な ID
GameID と DID のローカル ID 集約の特徴は、ID 管理の全体的およびローカルな考え方にもつながります。
ID 管理製品がユーザーのネットワーク全体のデジタル ID 製品を集約できない場合、つまりユーザーの「Web3 名」にならない場合、チェーン上のデータの相互運用性により、ID がそれらの一部になる可能性があります。より大規模な ID 管理サービスの一部です。たとえば、小さい GameID は大きい GameID によって集約され、GameID は .eth ドメインによって集約され、さらに .eth ドメインさえも .bnb ドメインによって集約できます。上記の DID は、将来的にはこの種の「部分的なアイデンティティ」になる可能性があります。単一のウォレットアドレスも、ある程度は「部分的なアイデンティティ」であると言えます。
ただし、ローカル ID 管理ツールにも価値があります。特定のアプリケーション シナリオに合わせてより多くの機能を作成できるためです。これは、ネットワーク全体の ID 管理ツールでは必ずしも実行できるわけではありません。そうしないと、肥大化してしまいます。たとえば、GameID 管理プラットフォームでは、他の GameID で表示される情報に基づいて、同じ MMORPG 内の同じ魔法職業のプレイヤーと友達になることができますが、ウォレット/ドメイン名プロジェクトに複数の細分化された機能が必要な場合、製品の複雑さが増し、製品設計の多くの課題に直面することになります。
4. DIDの今後の発展の究極の姿について考える
まず第一に、将来的には誰もが日常生活に深く結びついたデジタル アイデンティティを持つことになります。
各人が持つことができる DID は (PoP 経由で) 1 つだけです。DID は Web3 ネットワーク全体で使用され、オフチェーンの世界とより適切にやり取りできるように、KYC やその他の方法を通じてユーザーの実際の身元に結び付けられることもあります。
Web3 ドメイン名は、この DID の一意の識別子であり、Web3 のユーザーの名前です。
ユーザーは、現在のウォレットよりもはるかに強力な機能を備えたウォレットを通じてこの DID を管理します。ウォレット内では、複数の ID 集約プロトコルを統合して、ユーザーのマルチアドレスとマルチコントラクトのデータ集約を実現し、ユーザーの情報を包括的に表示できます。ユーザー全体のポートレートとして、各チェーンのステータス、各アドレスの認証情報、部分的な ID、関係グラフなど。
ユーザーは、ウォレットを通じてソーシャル ネットワーキング、採用、DAO ガバナンスなどのアプリケーション シナリオと対話します。暗号化技術により、ユーザーはプロジェクト当事者のデータ取得権限を独自に制御することができ、データ主権がユーザーにあることを認識します。
第二に、各人は、いくつかのローカル シナリオ (ゲーム プラットフォームなど)、または PoP を必要としないいくつかのシナリオで複数の異なるデジタル アイデンティティを持っているため、さまざまなシナリオで異なる自分を見せることができます。ユーザーは、これらの ID 間の相互接続を自由に制御し、特定のシナリオで対応する ID を使用できます。
V. 前回の記事のまとめ
上記を精査することで、将来、読者が DID 関連の物語について語るプロジェクトを見たときに、この「DID」がどのような「分散型アイデンティティ」を指しているのかを明確に理解できることを願っています。特定の資格情報のリリースは依然として、さまざまな資格情報を ID に集約するプロセスについて話しているのでしょうか、それともユーザーによる ID の管理について話しているのでしょうか、それともこの ID システムの特定のアプリケーション シナリオについて話しているのでしょうか?
DID 関連のプロジェクトには複数の層があることがよくあります。たとえば、前に分析した Next.ID は、ドメイン名などのユーザー側の ID 対話を実行するだけでなく、多くの ID プロトコルと同様に ID 集約も実行します。 ARCx は、信用スコア証明書の発行だけでなく、関連する申請の作成も準備しています。
下の写真は前回の記事の最後にある、DID関連の楽曲を整理したものです。
次へ: DID 魂の 3 つの質問
次の記事では、著者が 3 つの質問を通して DID 分野についての考え方と理解を説明します。
今まさに DID を必要としているのは誰でしょうか?
なぜ DID はまだ初期段階にあり、発展が遅いのでしょうか?
追跡しましたが、どのように投票すればよいですか?
1. DID、今は誰の需要ですか?
1.1 DID、それは今ユーザーの要求ではない
これまでの考察を通じて、多くの読者は、多くの場合、DID 自体がユーザーの直接の要求ではないことを発見したかもしれません。プロダクト マネージャーの観点から見ると、DID がユーザー向けである場合、多くの場合、特定のアプリケーション シナリオを通過する必要があります。
想像してみてください。現時点で特定のアプリケーション要件がない場合、さまざまな認証情報を積極的に取得すること (ビデオ顔認証のために BrightID にアクセスするなど)、またはいくつかの ID 集約/管理ツール (Next.id など) にアクセスすることに興味があるとします。メールアドレス、Twitterアドレス、ウォレットアドレスはすべてつながっていますか？ほとんどのユーザーはそうしないと思います。
プロジェクト主体が一定のインセンティブを提供すれば、確かに一定のユーザーを獲得することは可能ですが、DID製品の特性上、他のインセンティブのみではユーザーの継続的な維持を図るのは困難であり、他のインセンティブとは異なります。 NFT や GameFi などのプロジェクト。
長期的には、DID 開発の段階的な改善に伴い、ユーザーは個人 ID データの管理と利用についてますます意識するようになるため、特定のアプリケーション シナリオよりも先に ID 管理の必要性が生じる状況が発生する可能性があります。しかし、DIDトラックはまだ初期段階にあるため、それが起こる可能性は低いです。
1.2 DID はアプリケーション シナリオ プロジェクト パーティの要件です
実際、DID からより多くの恩恵を受けるのは、特定のアプリケーション シナリオのプロジェクト関係者です。資格情報に基づく迅速なスクリーニングや、Web3 でのユーザー ポートレートの迅速な取得など、コールド スタート フェーズでプロジェクト側に直接的なメリットをもたらします。
しかし、実際にアプリケーションシナリオで DID を使用し、DID を構築する場合、ユーザーに対して DID の概念を強調する必要はなく、製品のロジックの中で抽象化されます。したがって、DID の概念が特定のアプリケーション シナリオよりもプロジェクトの説明やディスカッションに頻繁に登場するのは驚くべきことではありません。
2. DID トラックがまだ初期段階にあり、発展が遅いのはなぜですか?
DID の概念は Web2 時代にまで遡ることができ、昨年 11 月に ENS が発行されて以来人気が高まっていることは周知の事実ですが、現在、DID トラックはまだ初期段階にあります。 DID に関連するプロジェクトは数多くありますが、DID の形式はまだ決定されておらず、どの DID システムのデータ蓄積にもネットワーク効果の兆候はありません。
DID の開発には特定のアプリケーション シナリオが必要であることを明らかにした後、この問題を理解するのは難しくありません。これは、現在の Web3 開発の「超金融化」と非金融 Web3 プロジェクトの開発の遅さに関係しています。 DID ナラティブに関連するアプリケーション シナリオを見ると、ほぼすべての非金融 Web3 プロジェクトで DID ナラティブを導入できることがわかります。
したがって、この質問に答えるには、基本的に、DID 関連の Web3 アプリケーション シナリオのそれぞれに関連するトラックの開発が遅い理由に答える必要があります。
2.1 Web3 非金融アプリケーション シナリオの開発が遅れている 3 つの理由
著者は、次の 3 つのロジックが、ソーシャル ネットワーキング、ゲーム、採用などを含むすべての Web3 非金融アプリケーション シナリオ プロジェクトの分析に適用できると考えています。 (ウォレットなどツールのプロパティが部分的なものは対象外です)
Web3 アプリケーションのユーザー エクスペリエンスは、対応する Web2 アプリケーションのユーザー エクスペリエンスとは大きく異なります。製品使用量のしきい値、ネットワークの遅延、運用コストなど、すべてが Web2 よりも高くなります。
Web3 アプリケーションのユーザー ベースは Web2 のユーザー ベースよりもはるかに小さく、世界中に分散しています。これは、現実世界とオンチェーン世界の間の接続を妨げるだけでなく、ネットワーク効果の蓄積にさらなる困難をもたらします。
現在は弱気相場のサイクルにあり、多くのユーザーが資産を失い、チェーンでの活動頻度が減少し、2018年のように業界全体に疑問を抱き、直接「サークルから引退」するユーザーも出てきている。 Web3 アプリケーション プロジェクトを開始するのがより困難になる
上記の各項目は、Web3 アプリケーション シナリオ プロジェクトの開発が困難である重要な理由である可能性があります。ということは、Web3 アプリケーション プロジェクトには開発の機会がないということでしょうか?あまり。 Web3 がネイティブで Web2 がネイティブではない一部のシナリオでは、上記の問題が存在する場合でも、関連製品にその価値が反映される可能性があります。
2.2 C社への信用融資は短期から中期的には誤った提案である
(To B のクレジット ローンは CeFi のロジックにより深く関わっているため、ここでは主に To C のクレジット ローンについて説明します)
信用貸付は、DID の最も金融化されたアプリケーション シナリオです。これは、既存のほとんどすべての DeFi が過剰担保で資本活用効率が低いため、これも頻繁に発生するトピックですが、理論的には、信用ローンはユーザーの資本活用効率を向上させることができ、Web3 ユーザーもこれに対する強い要求を持っています。
ただし、To C 信用融資は短中期（3 年以内など）には誤った提案、あるいは極めてニッチな分野であると筆者は考えている。
その主な理由は、Web3 の世界には Web2 のような返済不能ローンに対する求償メカニズムがないことです。したがって、ローンを返済できなかった場合の最終的なコストは、一連のオンチェーン ID が利用できなくなることです。
デジタル ID 自体にも価値があり、上記のさまざまな認証情報や関係データの蓄積を含め、長年使用してきたアドレス、ドメイン名、その他の ID を手放したくないという人もいるかもしれません。しかし問題は、ほとんどの Web3 ユーザーの現在のオンチェーン ID にどれだけの価値があるのか、自問してみてください。 100U を「クレジット ローン」できるとしたら、お金を返済せずにアイデンティティを再構築したいと考えるユーザーがどれくらいいるでしょうか?信用審査の敷居がよほど高くない限り、非常にニッチな商品にもなります。
KYCと顔認証をすればこの問題は回避できるのではないかという人もいるかもしれない。しかし、実際には、さまざまな後進国の農村地域には、価値のない個人の実情報データが溢れています。 「取引所のKYCアカウントはバッチで販売されている」など、毎日目にする情報について考えてみましょう。「クレジットライン」がIDの構築コストよりも高い限り、専門的な「アカウントメンテナンス」が行われます。 「ユーザー、およびバッチ構築が要件を満たしている。身元を確認し、ローンの返済を拒否し、プロジェクト側のウールを奪います。」
To C 信用貸付の成熟は、DID システム全体の成熟を待つ必要があるかもしれません。一方で、さまざまな高額な証明書やさまざまなデータ関係の蓄積により、デジタル ID の構築コストと提供のしきい値が高くなるため、一方で、さまざまな国での監督の浸透に伴い、Web3 ローンには法的救済メカニズムが確立される可能性もあり、これによりユーザーがローンを返済しない場合のコストが増加することになります。
3. DID トラックレベル投資のロジックは何ですか?
ここで、著者は DID トラック レベルへの全体的な投資に関する個人的な考えをいくつか共有します。
全体的なロジック: ユーザーから始まり、アプリケーションが契約に先行します。
特定の優先順位: ID 管理 > アプリケーション シナリオ > 資格情報の発行 > (ユーザー指向ではない) ID 集約プロトコル
3.1 全体的なロジック: ユーザーから始まり、アプリケーションが契約に先行します。
ここでの「アプリケーション」とは、特定のシナリオ、ID 管理、資格情報を発行するための「プロトコル」を含む、「ユーザー指向」の広範な概念です。一般に、ユーザーを直接指向していないさまざまなプロトコル製品を指します。 API 呼び出しの形式、アプリケーション プロジェクトの関係者またはその他の契約。
「協定として、私はより多くのアプリケーション プロジェクト当事者に協定に参加するよう説得し続けます。これらのアプリケーションのほとんどは短期間しか存続しない可能性があり、いくつかは順調に開発されるかもしれませんが、いずれにせよ、私のデータは蓄積され、データの壁やネットワーク効果もあります。このようにして、私の価値はますます高くなり、ますます多くのアプリケーション層のプロジェクトが私に協力してくれるようになり、最終的には API に課金できるようになります、または関連する付加価値サービスを提供します。確かに上記の論理は合理的であり、可能です。
ただし、著者は主に次の理由から、アプリケーションを最初に使用することを好みます。
まず、データ フローの方向において、アプリケーションはプロトコルよりも先を行く必要があるため、アプリケーションの主導権が大きくなります。プロトコル対アプリケーションの議論は、一見すると「鶏が先か、卵が先か」のように見えるかもしれませんが、そうではありません。上で説明したように、DID データの蓄積は、特定のアプリケーション シナリオにおけるユーザーの対話に依存します。
第二に、プロトコルプロジェクト側のやっていることは成熟しておらずコンセプト/テスト段階にある可能性があり、たとえ成熟していてもアプリケーションプロジェクト側のニーズを十分に満たすことができない可能性があります。プロトコル側にフィードバックを与えてその反復を期待するのではなく、アプリケーション側が独自にフィードバックを作成する必要があります。
より現実的な観点から見ると、データ バリアとネットワーク効果は、Web2 によって検証された非常に優れた物語です。このトラックの開発の初期段階では、優れた野心的なアプリケーション プロジェクト チームがこの物語を自発的に放棄することはありません。この値は他のプロジェクト当事者の合意に完全に委ねられます。
結局のところ、現在の Web3 アプリケーション プロジェクトの資金調達は非常に困難です。アプリケーション プロジェクト関係者も、評価のサポートとしてプロトコルに関連する DID の物語について話してみませんか?たとえば、まずアプリケーション自体を通じてユーザーを参加させてデータを蓄積し、次にアプリケーション内のユーザーのデータをプロトコル化し、関連するパートナーやエコシステムで使用できるようにすることで、さらにデータを蓄積し、最終的には DID システムに発展させます。この物語は何度も完全に理にかなっています。
さらに、ほとんどの DID プロトコルには実際には技術的な障壁がなく、その障壁はある程度のエンジニアリングの複雑さによってより反映されます。優秀なチームにとって、最初からプロトコルを自己開発することはそれほど難しいことではありません。たとえアプリケーション プロジェクトであったとしても、最初は、製品を迅速に反復するために、他のプロトコルが使用されますが、アプリケーションが一定の成功を収めることができれば、プロジェクト当事者は、プロジェクトの開発上限を増やすために自社開発のプロトコルを検討することもあります。
3.2 注目に値する特定の細分化されたトラック
優先順位: ID 管理 > アプリケーション シナリオ ≈ 資格情報の解放 > (ユーザー指向ではない) ID 集約プロトコル
アイデンティティ管理ツールのプロジェクト: ウォレットとドメイン名プロジェクトが推奨されます。結局のところ、DID の究極の形についての著者の将来の構想において、両者は非常に中心的な位置を占めています。
アプリケーション シナリオのプロジェクト: 前述したように、Web2 製品の再現ではなく、Web3 の元のアプリケーション要件に多くの機会が現れます。資格ベースの Web3 採用、NFT ベースの関心ソーシャル/異性愛ソーシャルなどはすべて、このかけがえのない Web3 シナリオに属します。
元のリンク
