Web2 ユーザーのアイデンティティを Web3 にブリッジするにはどうすればよいでしょうか?

公式アカウントより転載：旧ヤッピー

この記事では、Web2 がどのようにして Web3 エコシステムに移行するのか、そしてその中でアイデンティティがどのように重要な役割を果たすのかという問題を探ります。

Web3 はしばらく存続すると思います。 Web3 とは、ユーザーの選択と所有権を優先し、分散型サービスの構築に使用できる哲学、概念、テクノロジーを意味します。ブロックチェーン (例: Ethereum 、Solana)、トークン、プロトコル (例: IPFS、TheGraph、Lit)、サービス (例: ENS、Filecoin)、dApps、およびユーザーのキーが Web3 を構成します (ここには 1 つも網羅的なリストは記載していません)。

それがどれほど成功するかはわかりませんし、今日は何も起こらないと思います。しかし、うまくいくと思います。ある意味では成功していると思います。

また、Web3 が存在する「唯一の」Web ではないとも思います。少なくとも数年 (数十年) は Web2 と共存することになります。そう思うのは私だけではありません。

その後、おそらく別のパラダイムが現れるでしょう。開発者として、特に他の開発者のために製品を構築する者として、私はこれが何を意味するのかを考えるのに多くの時間を費やしています。自分の考えを文章にして共有するのも楽しいかもしれないと思いました。

この記事は主に次のような方向けです。

• Web3 サービスと通信する Web2 アプリケーションを構築する開発者

• Web2 アプリケーションで使用することを目的とした Web3 サービスを構築する開発者

この投稿では、イーサリアムのドキュメントと概念にリンクします。これは、私がイーサリアムに最も精通しており、イーサリアムが今日最大の開発者プラットフォームであるためです。同様のことが他の多くのチェーンにも当てはまります。

Web3 アーキテクチャを使用した Web2 アプリケーション

Web2 アプリケーションは、Web3 構造を通じてユーザー エクスペリエンスを向上させることができます。

——Shopifyは、ユーザーのNFTに基づいてショッピング体験をカスタマイズする「トークンゲートコマース」に参入しています。これについては、非常に明確で詳細な記事があります。トークン化されたコマースは素晴らしいアイデアです。あなたが持っているものは、あなたの好きなものについて多くを物語ります。 NFT に基づいてショッピング体験をカスタマイズするのは自然なことです。 (
https://help.shopify.com/en-US/manual/products/digital-service-product/nfts）

— Twitter と Stripe は、暗号通貨での支払いを可能にするために提携しており、コンテンツ作成者が暗号通貨で支払いを簡単に受け取ることができるようになります。 (
https://ストライプ.com/blog/expanding-global-payouts-with-crypto)

- Reddit は、ブロックチェーン上にコミュニティ ポイント システムを構築しています。 (
https://www.reddit.com/community-points/)

これらは消費者向けの大規模なプラットフォームです。彼らは dApps にはなっていませんが、Web 3 に手を出しています。

これは開発者にとって何を意味しますか?

開発者は、Web2 と Web3 の世界を統合する方法を見つける必要があります。これがさまざまな方法で展開されることはすでに確認され始めていますが、開発者ツールやインフラストラクチャを作成している企業は Web3 統合を検討し、実装しています。

• Stripe は Web3 決済インフラストラクチャを構築しています (https:// Stripe.com/use-cases/crypto)

• Auth0 はイーサリアム ログインのサポートを発表しました (https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/)

• Google Cloud は Web3 チームを構築しています

パターン: Web2 開発インフラストラクチャを構築したこれらの大企業は、現在、Web2 アプリ開発者が Web3 の概念 (NFT、暗号通貨、ENS など) dApps と簡単に統合できるようにするコンポーネントを作成しています。

彼らは Web2 と Web3 の世界の間に橋を架けようとしています。彼らのブリッジは、Web2 開発者が Web3 ファブリックと対話できるようにすることを目的としており、これがこの投稿の焦点です。

ブリッジングのもう 1 つの側面は、Web2 データを Web3 開発者が利用できるようにすることです。この記事が開発者の興味を引いたら、それについて別のブログ投稿を書くかもしれません。

Web3 の信頼モデル

Web3 の考え方は分散化です。すべてのユーザーは自分のデータ、$token などを所有します。

Web3 の信頼モデルは非対称暗号化に依存しており、信頼のソースはユーザーの秘密キーです。

委任の使用例はいくつかありますが、通常、ユーザーは信頼できる代表者としてサードパーティを選択せず、委任はユーザーの選択となります。

Web2 と Web3 の間のブリッジが存在するには、ユーザー アドレスの所有権に関する信頼が両方向に流れる必要があります。

アイデンティティは橋の構造です

結局のところ、Web3 のコンテキストでは、ユーザーのアドレスはその「アイデンティティ」です。これは彼らが誰であるかを表しています。したがって、彼らはさまざまな種類の多くのアイデンティティを持っている可能性があり、それぞれが異なるコンテキストで提示する個別の「アイデンティティ」です。

Web2 と Web3 の世界の橋渡しとは、ブリッジの両側で ID を解決し、開発者がその上に簡単に構築できるようにすることを意味します。

もちろん、ブリッジを構築するときに Web 3 の原則を犠牲にしてはなりません。 Web3 ID プロトコル (OIDC など) を調整する必要がある場合があります。
https://openid.net/connect/、OAuth 2: https://oauth.net/2/) と、Web 3 のニーズと概念に適応する標準的な作業方法。

すべては住所から始まります

Web3 アドレスには、関連付けられた秘密キーと公開キーがあります。

アドレスの数は急速に増加しています。

イーサリアムアドレス (https://etherscan.io/chart/address)

しかし、アクティブなアドレスの数はさらにゆっくりと増加しました。

アクティブなイーサリアムアドレス https://etherscan.io/chart/active-address

上のグラフから、イーサリアム アドレスを積極的に使用しているインターネット ユーザーの割合が低いことが推測できます。メタマスクは2カ月前、月間アクティブユーザー数が3000万人だと発表した。しかし、アドレスを所有していないユーザーはどうなるでしょうか?

Web3 が長期にわたって大量のユーザーに採用されるためには、大量のユーザーに採用されるための舗装された道が必要です。誰もが暗号通貨の世界に興味があるわけではありません。ユーザーが使い慣れたパターン (Facebook、Google、Twitter などでログイン) を使い続けて、後でブロックチェーン (およびキー) について知りたいときに初めて気づくことができる方法は、非常に価値があります。

アドレスの数は非常に急速に増加していますが、すべてのインターネット ユーザーのうち比較的少数のグループが、オフラインでキー ペアを作成するか、ハードウェア ウォレットを介して秘密キーを所有しています。それらのほとんどは「保管ウォレット」の形で存在し、鍵はサービス組織によって管理されます。 Binance やCoinbaseなどの集中型取引所が最も一般的な例です。

これは Web3/分散化の観点からは「純粋」ではないかもしれませんが、非常に前向きです。これは Web 3 のアイデアの一部を大衆にもたらします。

開発者の観点から見ると、Web2 と Web3 の世界を橋渡しするということは、ホスティング サービスがブロックチェーン アドレスをユーザー アカウントに関連付け、キーを安全に管理し、ウォレットのやり取りを管理するための制御を (少なくとも他の内部開発チームに) 提供する必要があることを意味します。

magic.link、bitski、venly などのサービスは、Web2 が Web3 の世界に接続できるように支援し、一般的な Web2 ログイン メカニズムのキー ペアを作成し、開発者がこれらの秘密キーを管理するための API と UI を提供します。

ユーザーが秘密キーを制御したら、ここからが楽しい始まりです :)

秘密キーを使用してログインします

比較的単純なシナリオを見て、それが Web2 および Web3 アプリケーションでどのように動作するかを見てみましょう。ユーザー：

• 1つのアプリで認識されました。

• アバターを {input A} に変更して保存します。

• #2で間違いを犯したことに気づきました。

• アバターを {input B} に変更して保存します。

Web3 アプリケーション (dApp) を使用すると、ユーザーは自分のアドレスの 1 つに「接続」できます。この操作は基本的にブラウザにユーザーのブロックチェーン アドレスを提供します。ブロックチェーンやその他の分散型サービス以外に「バックエンド」はありません。通常、Web3 コンポーネント上でユーザーの認証を必要とする操作には、ユーザーの秘密キーからの署名付き情報が必要です。

Web 3 の場合

Web2 プロトコルを使用すると、ユーザーは操作するたびに自分の身元を証明するためのアクションを行う必要がなくなります。通常、ユーザーはログインする必要があるのは 1 回だけであり、クライアント/ブラウザーは資格情報を保存し、後続のリクエストでそれをバックエンドに送信し、バックエンドはそれを使用してユーザーを認証します。

Web 2 の事例

上の図は要点をわかりやすくするために簡略化しすぎています

Web2 のユーザー エクスペリエンスは優れています。 Web2 の世界と Web3 の世界の橋渡しには、Web2 のようなユーザー エクスペリエンスを維持し、ユーザーが秘密キーを制御し、ブロックチェーン (またはその他の Web3 ネイティブ サービス) を呼び出すときにそれぞれの特定のアクションを実行するつもりであることを証明する必要があります。

開発者は、Web2 アプリケーションの一部としてアドレスをユーザー アカウントにどのように関連付けるのでしょうか?

前のセクションで説明したサービスは、すでに秘密キーをユーザー アカウントに関連付けています。しかし、そうでないサービスはどうなるでしょうか?ユーザーが Metamask、Argent、Trezor、またはその他のタイプのウォレットを使用している場合はどうなりますか?

これはイーサリアムログインで解決される問題です（
https://eips.ethereum.org/EIPS/eip-4361)。これにより、ユーザーは、アドレスの所有権を証明する資格情報として秘密キーを使用して、サービスとのセッション (Web2 の意味で) を確立できます。

画像ソース: https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/

これが興味深いと思われる場合は、@signinwitheth と @SpruceID をフォローしてください。

そして、Web2 アプリケーションがユーザーのブロックチェーン アドレスが事実であることを認識すると、可能性の世界が開かれます。

潜在的なユースケース

ユーザーの Web3 ID が判明したら、Web2 開発者は当然、さらに先へ進みたいと思うでしょう。これは次のことを意味します:

• アドレスに関連する公開データ (オンチェーン データなど) を読み書きし、ビジネス ロジックに使用します。これらを「ユーザー認証を必要としない操作」と呼びます。

• 認証が必要なデータの読み取り/書き込み (分散ストレージに保存されたユーザーのプライベート ビデオやオンチェーン トランザクションの実行など)。これらを「ユーザー認証が必要な操作」と呼びます。

どのように機能するかを理解するために、それぞれを詳しく見てみましょう。

ユーザー認証を必要としない操作

これは最も単純なケースです。開発者は、アドレスを必要とし、認証を必要としない API を呼び出すことができます。思い浮かぶ使用例は次のとおりです。

• ENS (https://ens.domains/) または Unstoppable Domains (https://unstoppabledomains.com/) のプロファイル データを読み取り、それを表示します。これは、ユーザーが選択した場合は「グローバル パブリック ユーザー名と設定」になります。ファイル画像」が可能性を広げます。

• トークンのアクセス制御は、ユーザーの POAP を取得し、これらの POAP (https://poap.xyz/) に基づいてリソースへのアクセスを制限することによって実現されます。

• 資産をユーザーのオンチェーンアドレスに転送します。

• 次のステップは、彼らが主流になる場合は、Proof of Humanity のようなサービスを使用して、偽のユーザー アカウントを回避することです。

デジタル検証可能な証明書を使用してこれらの目標の一部を達成する別の方法があり、これらの方法では公開データは必要ないことに注意してください。しかし、それは別の記事でお話します...

ユーザー認証が必要な操作

ああ、話がややこしくなってきました :) 私たちは皆、このような対話には慣れています。

Web2 アプリに Gmail データにアクセスさせたい場合は、Google でログインし、Web2 アプリにアクセスさせたいアカウントのリソースに同意するダイアログが表示されます。

これは Web 3 サービスではどのように動作するのでしょうか? Web2 アプリケーションが 2 つの異なる Web3 サービスに存在するデータを読み取りたい場合。

• すべて同時に「ログイン」する必要がありますか?

• それとも、両方にアプリのアクセス許可を与えることに同意するだけですか?

• それぞれの場合のユーザー エクスペリエンスはどのようなものですか?

Web2 アプリケーションのコンテキストでは、認証サーバー (前の例では Google) によって発行されたトークンを使用して、Gmail の API にアクセスします (Gmail は「リソース サーバー」です)。 Web 2 アプリケーションは、ユーザーに代わって API を複数回呼び出すときにこのトークンを送信します。 Web3 サービスの場合、これはどのように動作するのでしょうか?

• ユーザーは Web3 サービスとのやり取りごとに契約書に署名する必要がありますか?最高のユーザーエクスペリエンスではありません...

• アプリケーションに権限を委任する必要がありますか?どのように任せるのか？

• Web3 サービスは、これらの認証状況にどのように適合する必要があるのでしょうか?

Spruce の開発者は、この課題を解決する方法をすでに検討し始めています。それは前向きな一歩だと思います。ユースケースと現実世界のシナリオを理解し、これらのケースをすべての開発者にとって反復可能なパターン/ガイドラインに一般化する必要があります。

それが今後の課題の大きな部分だと思います。

要約する

私はこの件について積極的に考え、解決しようとしているところなので、これについてどう思うか知りたいです。 Auth0Lab での私のチームの仕事の一環として、私たちは 1 つのアプリケーションのコンテキストだけでなく、すべての開発者にツールを提供するというコンテキストで、Web2 と Web3 の世界の橋渡しをする方法を模索しています。