こんにちは。金融ソリューション事業部の姫野です。
本ブログでは、Magic、thirdweb、Web3Authの3サービスの秘密鍵管理方式に焦点を当て、深く掘り下げていきます。各サービスの主要なアーキテクチャと処理フローを、図解も含めて詳細に理解していきましょう。
1. 前回のおさらい
前回のブログ（web3入門：ウォレットサービスとは？主要3サービスを徹底比較）では、web3ウォレットの基本とそれをユーザーフレンドリーに提供する主要な3つのサービス（Magic、thirdweb、Web3Auth）の概要を比較しました。
| サービス | 認証方法 | セキュリティ | 対応SDK |
|---|---|---|---|
| Magic | 分散型キーマネジメントシステム （DKMS） |
ローカルで秘密鍵の生成、復元が行われる 秘密鍵は分散保管せず、AWSのKMSサービスを利用し、秘密鍵の復号化キー（ユーザーマスターキー）をHSMに保存 |
DedicatedWallet |
| thirdweb | シャミアの秘密分散 （SSS） |
ローカルで秘密鍵の生成、復元が行われる 秘密鍵はシャミアの秘密分散により、複数shareに分けられ分散保管 shareAはユーザーデバイス、shareB,CはAWS HSMに保管 |
Connect |
| Web3Auth | 単要素認証 （MPC） |
ローカルで秘密鍵の生成、復元が行われる 秘密鍵はMPCにより、ネットワーク（5/9）分散保管 |
Plug & Play CoreKit |
| 分散鍵生成としきい値署名スキーム （DKGとTSS） |
完全な秘密鍵は生成されず、署名情報のみがTSSプロセスにより復号される キーはDKGプロセスにより、複数Factorに分けられ分散保管 Factor1はMPCネットワーク、Factor2はユーザーデバイスに保管 |
CoreKit |
次のセクションからは各サービスの主要なアーキテクチャと処理フローを、図解も含めて詳細に解説します。
2.Magicの秘密鍵管理方式
まずは一番シンプルなMagicの秘密鍵管理方式について、みていきましょう。MagicはAmazonのキーマネジメントサービスを利用した非保管型の鍵管理方式を実現しています。
2.1 アーキテクチャ：分散型キーマネジメントシステム（DKMS）
Magicのアーキテクチャは、Amazonのキーマネジメントサービス（AWS KMS）をベースにしたハードウェアセキュリティモジュール（HSM）を使用して、非保管型（ノンカストディアル）の認証システムを構築しています。これにより、ユーザーは自らのデバイス上で秘密鍵を生成し、その秘密鍵はAWS KMSによって保護された環境で安全に保管されます。
補足説明
- KMS（Key Management Service）：AWSのKMSは、鍵の管理と暗号化をクラウドで安全に行うためのサービスです。
- HSM（Hardware Security Module）：HSMは、暗号化キーを生成、管理、保護するためのハードウェアデバイスです。高度なセキュリティが求められる環境で使用されます。
- ノンカストディアル（Non-Custodial）：ユーザーが自分の秘密鍵を管理する仕組みを指します。サービスプロバイダーが秘密鍵にアクセスできないため、セキュリティが向上します。
Magicが採用しているこのDKMSアーキテクチャは、特許を取得しており、中央集権型のサーバーに頼ることなく、分散型のセキュリティを実現しています。
2.1.1 DKMSの機能と利点
- シンプルな非保管型（ノンカストディアル）の認証システム：
完全な秘密鍵はユーザーのデバイス上のみで取り扱われ、外部で扱われることはありません。また、AWS KMSのみを使ったシンプルなアーキテクチャ構造であるため、リスクポイントが少ないです。 - HSMによるマスターキーの厳格な保護：
秘密鍵の暗号化と復号はAWSのKMSが管理するハードウェアセキュリティモジュール（HSM）で行われますが、HSMに秘密鍵自体は保存されず、マスターキーのみが保管されます。マスターキーはユーザーのみがアクセス可能で、非常にセキュアなAmazonセキュリティ技術によって厳重に管理されており、外部からのアクセスは完全に遮断されています。
2.2 処理フロー
Magicの非保管型キーマネジメントシステムの処理フローについて解説します。
2.2.1 秘密鍵生成と保管
以下の図2Aはユーザーがサインアップした際に、秘密鍵を生成し、安全に暗号化して保存するプロセスを詳細に示しています。このフローに沿って詳細を解説します。
（出典：Non-custodial tool for building decentralized computer applications）
各ステップの詳細
- サインアップイベント（Step 202）：
ユーザーがクライアントアプリケーション（Client 110）でサインアップを開始します。 - 新規ユーザー登録（Step 204）：
サーバー（Server 125）は、ユーザーの情報を受け取り、新規ユーザーを登録します。 - 時間制限付きアクセストークンの生成（Step 206）：
サーバーは、サードパーティサービス（3rd Party Service 155）を利用して時間制限付きアクセストークンを生成します。 - アクセストークンの返却（Step 208）：
サーバーは、生成したアクセストークンをクライアントに返却します。 - スコープ付き資格情報の交換（Step 210）：
クライアントは、サーバーにアクセストークンを返送し、スコープ付き資格情報を取得します。 - 秘密鍵の生成（Step 212）：
クライアントは、自身のデバイス上で秘密鍵を生成します。 - HSMでの暗号化（Step 216）：
クライアントは、生成した秘密鍵を専用のHSM（Hardware Security Module）で暗号化します。HSMは、ハードウェアレベルでの高いセキュリティを提供します。 - 暗号化された鍵の返却（Step 218）：
HSMは、暗号化された秘密鍵をクライアントに返却します。 - 暗号化された鍵のアップロード（Step 220）：
クライアントは、暗号化された秘密鍵をサーバーにアップロードします。
このフローにより、ユーザーはSNSにログインするだけで、秘密鍵の生成からHSMへの安全な保管までが自動的に行われ、鍵の管理負担が軽減されます。
2.2.2 トランザクションへの署名
以下の図2Bでは、既にログインしているユーザーがトランザクションを実行する際に、秘密鍵を安全に使用し署名を行うプロセスです。このフローに沿って詳細を解説します。
（出典：Non-custodial tool for building decentralized computer applications）
各ステップの詳細
- アクセストークンの交換（Step 230）：
ログイン済みのユーザーは、クライアントアプリケーション（Client 110）で時間制限付きのアクセストークンを交換します。 - 時間制限付きスコープ資格情報の返却（Step 232）：
サーバー（Server 125）は、サードパーティサービス（3rd Party Service 155）を介して、クライアントに時間制限付きスコープ資格情報を返却します。 - 暗号化された秘密鍵の復号（Step 234）：
クライアントは、取得したスコープ資格情報を使用して、暗号化された秘密鍵をHSM（Hardware Security Module）に送信します。HSMはユーザーマスターキーを使用して、暗号化された秘密鍵を復号化します。 - 復号された秘密鍵の返却（Step 236）：
HSMは、復号された秘密鍵を直接クライアントに返却します。 - トランザクションデータの署名（Step 238）：
クライアントは、復号された秘密鍵を使用してトランザクションデータに署名します。 - 秘密鍵のメモリからの削除（Step 240）：
署名後、クライアントは秘密鍵をメモリから安全に削除します。 - 署名済みトランザクションデータの送信（Step 242）：
クライアントは、署名済みのトランザクションデータをサーバーに送信します。 - ブロックチェーンへのトランザクションの提出（Step 244）：
サーバーは、署名済みのトランザクションデータをブロックチェーン（Blockchain 185）に提出します。 - 提出結果の返却（Step 246）：
ブロックチェーンは、トランザクションの実行結果をサーバーに返却します。 - 結果の返却（Step 248）：
サーバーは、実行結果をクライアントに返却します。
これらのフローを通じて、ユーザーはSNSにログインするだけで、安全かつ効率的にブロックチェーン上のトランザクションに署名することができます。
2.3 セキュリティと暗号化
- セキュアな通信：
Magicでは、サーバーとユーザーブラウザ間で送受信されるすべてのデータはエンドツーエンドでTLS暗号化されており、サーバーと内部アプリケーション間で送信される秘密情報もTLSで保護されています。内部アプリケーションの秘密情報は、Hashicorp Vaultで安全に管理されています。Hashicorp Vaultは、機密情報の保存、アクセス管理、および動的なシークレットの生成を行うためのセキュアなシステムです。 - データの暗号化：
Magicは、業界標準のAES-256暗号化アルゴリズムを使用して、すべてのデータを暗号化しています。これには、データベースに保存される情報、データのスナップショット（ある時点のデータのコピー）、定期的に行われる自動バックアップ、およびデータのレプリカ（他の場所に保存されるコピー）が含まれます。データの暗号化と復号は、データがストレージに書き込まれる際および読み取られる際に自動的に行われます。
3. thirdwebの秘密鍵管理方式
次に、thirdwebの秘密鍵管理方式について、みていきましょう。thirdwebはAWS KMSでの鍵管理に加え、シャミアの秘密分散アルゴリズムを利用した分散保管による鍵管理方式を実現しています。
3.1 アーキテクチャ： シャミアの秘密分散（SSS）
thirdwebのアーキテクチャは、秘密鍵をシャミアの秘密分散（SSS）アルゴリズムを用いて分割・管理するセキュアなアーキテクチャを採用しています。ユーザーのデバイスで生成された秘密鍵は、複数のシャードに分割され、異なる保管方法で安全に管理されます。シャミアの秘密分散では、秘密鍵の完全な形がユーザーのデバイス外で扱われることはありません。
上述のMagicのアーキテクチャでは秘密鍵は分割されずに暗号化されてHSMに保管されていましたが、SSSの仕組みを用いることにより、例え一部のシャードの暗号が解析されたとしても個々のシャードでは完全な鍵としての機能を果たさないため、攻撃者が秘密鍵全体を解明することが非常に難しくなります。
補足説明
- シャミアの秘密分散（SSS: Shamir's Secret Sharing）：
シャミアの秘密分散は、秘密鍵を複数のシャード（断片）に分割し、それぞれを別々に保管することでセキュリティを強化するアルゴリズムです。秘密鍵を再構築するためには、一定数のシャード（しきい値 k）が必要で、これを満たさないと再構築は不可能となります。
秘密鍵は特別な数式（多項式）を使って分割されます。各シャードは、この数式に数値を代入して計算された結果です。k 個のシャードがそろうと、ラグランジュ補間という方法を使って元の数式を再構築します。ラグランジュ補間とは、いくつかの点（結果）がわかっているときに、それらの点を通る曲線（数式）を見つける方法です。この方法を使って、各シャードの情報から多項式を再計算し、その定数項から秘密鍵を復元します。
3.1.1 SSSの機能と利点
- 秘密鍵のシャード化とセキュリティの向上：
ユーザーのデバイスで直接生成される秘密鍵は、シャミアの秘密分散アルゴリズム（SSS）によって3つのシャードに分割されます。これにより、秘密鍵全体が一箇所に存在するリスクを排除し、単一シャードでは機能しないため、改ざんや不正アクセスに対する耐性（耐タンパ性）が向上します。 - 分散保管によるリスクの低減：
シャードはユーザーのデバイスとthirdwebのサーバー間で分散して保管され、AWS KMS（HSM）を活用した追加の暗号化により、シャードのセキュリティがさらに強化されます。これにより、単一点による漏洩リスクが低下し、全体的なシステムの堅牢性が高まります。
3.2 処理フロー
thirdwebのSSSを用いた秘密鍵管理プロセスは以下のステップに沿って進みます。
- ユーザー認証：ユーザーはメール、ソーシャルログイン、またはカスタム認証メソッドを使用して初めてアプリケーションにログインします。
- キーペアの生成：ログイン後、ユーザーのデバイスで公開鍵と秘密鍵のペアが生成されます。このプロセスは完全にクライアントサイドで行われます。
- 秘密鍵のシャード化：生成された秘密鍵はシャミアの秘密分散アルゴリズムを用いて3つのシャードに分けられます。各シャードは個別に機能せず、しきい値以上のシャードがそろって初めて秘密鍵を再構成できます。
- シャードの保管：
- シャードAはユーザーのデバイスに保存されます。ウェブアプリケーションの場合はブラウザに、モバイルアプリの場合はセキュアエンクレーブ（デバイス内の安全で機密データを保護するために使用される領域）に保存されます。
- シャードBはthirdwebによってAWS KMS（HSM）を利用して暗号化され、thirdwebDBに保管されます。マスターキーはthirdweb管理となります。
- シャードCはユーザー認証プロセスを通じてAWS KMS（HSM）を利用して暗号化され、thirdwebサーバーに保管されます。マスターキーはユーザーのみ使用可能です。
このフローにより、ユーザーはSNSにログインするだけで、秘密鍵の生成からシャミアの秘密分散アルゴリズムによる分散保管までが自動的に行われ、鍵の管理負担が軽減されるとともに、セキュリティが強化されます。
3.3 セキュリティと暗号化
- セキュアな通信：
thirdwebのバックエンドとのすべての通信は、TLSにより暗号化され、安全なデータ転送が確保されています。 - データの暗号化：
保存されるデータはAES-256で暗号化され、万が一のデバイス紛失や障害にも備えたバックアップがとられています。
4. Web3Authの秘密鍵管理方式
最後に、Web3Authの秘密鍵管理方式について解説します。Web3AuthはAWS KMSでの鍵管理に加え、複数のアルゴリズムを利用した分散保管による鍵管理方式を実現しています。Web3Authでもシャミアの秘密分散を採用していますが、シャードの保管場所以外はthirdwebと類似するため、本セクションではシャミアの秘密分散の解説は割愛します。
4.1 単要素認証（MPC）
4.1.1 アーキテクチャ
Web3Authの単要素認証（MPC）は、Authネットワークと呼ばれるMPCネットワークをベースにした分散型の参加者群（企業群）が個々に部分鍵を保管し、個々の参加者は秘密鍵の全貌を知ることなく秘密鍵の生成と使用を共同で行います。
補足説明
- マルチパーティ計算（MPC: Multi-Party Computation）：
マルチパーティ計算におけるシャードの分割と再構築はシャミアの秘密分散と同様に多項式とラグランジュ補間がよく用いられます。シャミアの秘密分散と異なる点は、MPCでは複数の参加者が共同で計算を行う点です。
MPCのプロトコルでは、秘密情報を特定の数式を用いて部分鍵に分割し、ネットワークの各参加者に送信します。各参加者は自分の部分鍵を持ち、その部分鍵を元に個々の部分計算を行います。再構築の際には、これらの部分計算結果をローカルで集め、統合することで秘密情報を復元可能です。
4.1.2 機能と利点
複数ノードによる安全な分散管理：
Web3Authの単要素認証（SFA）は、MPC（マルチパーティ計算）技術を活用して、秘密鍵の断片を複数の計算ノード間で分散させます。このアプローチにより、鍵全体が一箇所に集中するリスクを排除し、耐タンパ性（改ざん耐性）を向上させます。5/9のコンセンサスメカニズム：
Authネットワーク内の5/9コンセンサスメカニズムによって、秘密鍵の断片は分散されて保管されます。このメカニズムにより、9つの計算ノードのうち5つが合意に至らないと鍵の断片は再構築できません。コンセンサスメカニズムとは、分散システムにおいて複数のノードが協力して一貫した決定を行うプロセスのことです。これにより、ネットワーク内での合意形成が要求され、攻撃者による不正アクセスや鍵の漏洩のリスクが著しく低下します。また、このシステムは自律的であり、一つの組織や個人が全ての権限を持つ中央集権的な管理ではないため、単一点の障害から保護する効果があります。
4.1.3 処理フロー
単要素認証の処理フローはとてもシンプルです。ソーシャルログインの後、ローカルで生成された秘密鍵はAuthネットワーク内で分散して保管されます。
（出典：Web3Auth Documentation）
また、ソーシャルログインについても解説します。
（出典：Web3Auth Documentation）
ソーシャルログインの詳細：
- ユーザーはWeb3Authのポータルにリダイレクトされます。
- Web3Authのポータルからサービスプロバイダを経由してOAuthやJWTで認証を行います。
- ユーザーのローカル環境とサービスプロバイダ間でセッショントークンのハンドシェイクが行われます。
- サービスプロバイダからユーザーの固有情報（JWT RFCのsubjectフィールドに相当）を取得します。
- 取得した固有情報はハッシュ化され（オプショナル）、秘密鍵の一部としてAuth Network内で保管されます。
これらのフローを通じて、ユーザーはSNSにログインするだけで、秘密鍵の生成とMPCネットワークへの分散保管が自動的に行われます。これにより、秘密鍵が一箇所に集中するリスクを排除し、セキュリティが強化されます。
4.2 分散鍵生成としきい値署名スキーム（DKGとTSS）
Web3Authではこのセクションで説明するアーキテクチャのことを「MPC」と呼んでいます。Web3Authの「単要素認証」も「MCP」もどちらもMPCネットワークを利用しているため、本ブログでは違いを分かりやすく、主要なアーキテクチャベースで説明をするために「分散鍵生成としきい値署名スキーム（DKGとTSS）」として解説します。
4.2.1 アーキテクチャ
DKG（Distributed Key Generation）：
DKGアーキテクチャは、署名に必要な部分鍵を生成するプロセスです。非同期検証可能シークレットシェアリング（AVSS）と呼ばれるアルゴリズムの改良版を用いて、トランザクションの署名に必要な部分鍵（Factor1, Factor2, Factor3...）を非同期に複数生成します。その後、これらのFactorは複数のシェアに分割され、分散保管されます。
TSS（Threshold Signature Scheme）：
TSSアーキテクチャは、部分鍵から署名を生成するプロセスです。各シェアはそれぞれのFactorに基づいて独立して署名を生成します。そして、ユーザーデバイス上でこれらの個々の署名が集約され、トランザクションのための最終的な署名が形成されます。
マルチパーティ計算（MPC: Multi-Party Computation）：
DKGプロセスによって生成されたFactorの1つは、MPCアーキテクチャによってさらに分散保管され、MPCネットワークの各ノードは部分鍵を保管します。署名を生成する際、トランザクション毎に各ノードが部分鍵をもとに個々の計算を行い、各ノードで独立して部分署名を生成します。生成された部分署名は集約され、最終的なトランザクションの署名が形成されます。重要なのは、部分署名が直接集約されて最終署名が生成され、Factor自体を一度再構築することはないという点です。
4.2.2 機能と利点
- 完全な秘密鍵を生成しない：
本アーキテクチャでは完全な秘密鍵はどの時点でも生成されず、Magicやthirdwebのようにローカルで秘密鍵を復号する必要がないため、秘密鍵の漏洩リスクがありません。 - 動的な鍵管理によるセキュリティ強化：
DKGやMPCによって生成されるFactorや部分鍵はトランザクション毎に動的に生成されます。これにより、攻撃者が一度にアクセスできるのは単一のトランザクションデータに限られ、影響を最小限に抑えることができます。また、複数の分散されたシェアから独立して署名が生成されるため、単一のシェアが侵害されても、全体のFactorやトランザクションのセキュリティが維持されます。これにより、攻撃者が全シェアにアクセスせずにトランザクションを偽造することは非常に困難になります。
4.2.3 処理フロー
分散鍵生成（DKG: Distributed Key Generation）プロセス
下図はDKGプロセスの処理フローになります。Factor1の部分は前述したMPCプロセスと類似しており、Factor2,3の部分は前述のSSSプロセスと類似しています。
ユーザー認証：
ユーザーはソーシャルログインによるOAuth認証を行います。これはユーザーデバイス上で行われ、セキュアなログイン情報が生成されます。キーファクターの生成：
ユーザー認証後、ユーザーの固有情報をもとにWeb3AuthのDKGプロセスにより非同期で複数のキーファクター（Factor1, Factor2, Factor3）を生成します。これらのファクターは、後の署名に必要な要素を形成します。ファクターの分散：
このフローにより、ユーザーはSNSにログインするだけで、複数のキーファクターが生成され、分散保管されます。これにより、秘密鍵を完全に生成せずに、各ファクターが安全に管理されます。
しきい値署名スキーム（TSS: Threshold Signature Scheme）プロセス：
続いてトランザクションへ署名するためのしきい値署名スキームのフローです。
- 署名要求：
ユーザーがトランザクションを実行する際、署名要求が発生します。この要求は各シェアに送信され、分散署名プロセスが開始されます。 - 部分署名の生成：
各ノードは自身のFactorや部分鍵を用いてトランザクションの部分署名を生成します。これにより、各ノードで独立して部分署名が作成されます。 - 最終署名の生成：
生成された部分署名は集約され、完全な署名が形成されます。
このフローにより、ユーザーはSNSにログインするだけで、各部分鍵が独立して署名を生成し、最終的な署名が形成されます。これにより、完全な秘密鍵を生成せずにトランザクションの署名が可能となり、セキュリティが強化されます。
5. 結局、どの秘密鍵管理方式がいいの？
Magic、thirdweb、Web3Auth、それぞれ異なる秘密鍵管理方式を採用していますが、それぞれの優位性について考察してみます。
5.1.1 Magicの優位性
Magicは秘密鍵を分散保管していない代わりに、設計がシンプルという利点があります。分散保管するとその分構造は複雑になるため、障害リスクも高まります。堅牢なAWSのKMSが管理するHSMを利用しつつ、ユーザーのみが（ユーザー認証によって）鍵にアクセスできる非中央集権な仕組み（DKMS）を実現しています。また、MagicはこのDKMSの特許を取得しており、構造がオープンになっているため、透明で堅牢なシステムを利用したいユーザーに最適といえます。
5.1.2 thirdwebの優位性
thirdwebはシャミアの秘密分散技術を利用しており、秘密鍵をシャードに分割し、それぞれ異なる場所に保管することでセキュリティを高めています。ユーザー側ではデバイスとOAuth認証の2つのシャード管理が必要になりますが、thirdwebが鍵の1つを管理しているため、ユーザーがどちらか1つを紛失・漏洩した場合でもウォレットを継続利用できます。ユーザーが2つの鍵を、中央集権（thirdweb社）が1つの鍵を管理する構造は、個人での鍵管理に不安のあるユーザーに最適といえます。
5.1.3 web3authの優位性
Web3Authのアプローチは、秘密鍵を生成せず、代わりに分散型の動的な計算（MPC）を利用してトランザクション毎に一時的な署名を生成します。これにより、一度にアクセスできるのは一回のトランザクションデータのみとなり、攻撃者による全アクセスのリスクが大幅に低下します。Web3Authでは鍵は中央集権（Web3Auth社）で管理されず、すべてユーザーが管理するため、完全な非中央集権的であるといえます。個人で完全に鍵管理をしたい、または秘密鍵の生成リスクをなくしたいユーザーに最適といえます。
一方でそれぞれの想定されるリスクや懸念点についても考察してみます。
5.1.4 Magicのリスクや懸念点
Magicのリスクや懸念点として、秘密鍵の保管先がKMSであり、AWSサービスにアーキテクチャが依拠していることが挙げられます。これにより、AWSのサービスが停止した場合に影響を受けるリスクがあります。また、分散保管の仕組みを採用していないため、暗号化した秘密鍵が解読された場合、流出するリスクがあります。
5.1.5 thirdwebのリスクや懸念点
thirdwebのリスクや懸念点として、部分鍵の保管先の一つがKMSであり、Magicと同様にAWSサービスに依拠していることが挙げられます。また、部分鍵の保管先の一つがthirdwebであり、thirdwebのインフラに依拠していることも懸念されます。
5.1.6 Web3Authのリスクや懸念点
Web3Authのリスクや懸念点として、完全に非中央集権的な実装になっているため、ユーザーの鍵紛失リスクを全て個人が負うことになります。これにより、ユーザーが自らの責任で鍵管理を行う必要があり、管理ミスが致命的な結果を招く可能性があります。
本セクションでは各サービスの優位性や懸念点を考察しました。どのサービスも企業の認証システムや暗号復号プロセスに依存しているため、リスクを理解し、対応策を講じることが重要です。ユーザーのニーズやリスク許容度に応じて、最適なサービスを選択しましょう。
6. 最後に
今回は秘密鍵の管理と利用部分に特化した各サービスの優位性を比較しましたが、その他の観点（導入のし易さや企業の信頼性など）も考慮が必要になります。全体的な観点での比較は以前のブログ「web3入門：web3ウォレットサービスとは？主要3サービスを徹底比較」をご参考ください。また、仕組みの違いにより様々なユーザーニーズに対応できる点、どのサービスも優位性がある点は新しい気づきとなりました。
今後の調査と検証計画
Web3AuthのDKGとTSSアーキテクチャの深掘り：
これまでの私の理解では、署名に必要な情報はmessageとprivate_keyの2つでした。messageは任意に変更可能であり、よくTimeStampが利用されるため、一意の署名が生成されます。そして、もう一方の情報である秘密鍵が必要と認識していました。しかし、DKGとTSSアーキテクチャを利用することで、完全な秘密鍵なしで署名が可能であり、具体的なアルゴリズムの理解がまだ不足しているため、今後その点について深掘りできたらブログ化したいと思います。
thirdwebを用いた検証：
本ブログで紹介したthirdwebを用いて、実際に検証を行ったブログ「web3入門：SNSログインでNFTを獲得！thirdwebを用いたweb3サービスを構築してみた」を執筆中です。thirdwebは2024年5月にiPhoneのPassKeyによるログインに対応しており、これによりユーザービリティがさらに向上しています。PassKeyを利用することで、iPhoneの指紋認証（Touch ID）や顔認証（Face ID）によるログインが可能となり、ユーザーはより簡単で安全にweb3に接続できます。thirdwebを用いたシステムを構築する際には、この機能も利用できるため、ぜひ上記ブログを参考にしてみてください。
また、未定ではありますがWeb3Authを用いた検証ブログも執筆したいと思っているので、気になる方は是非チェックしてみてください。
現在、電通総研はweb3領域のグループ横断組織を立ち上げ、web3およびメタバース領域のR&Dを行っております（カテゴリー「3DCG」の記事はこちら）。 もし本領域にご興味のある方や、一緒にチャレンジしていきたい方は、ぜひお気軽にご連絡ください！ 私たちと同じチームで働いてくれる仲間を、是非お待ちしております！ （電通総研の採用ページ）
執筆：@himeno、レビュー：@yamashita.tsuyoshi
（Shodoで執筆されました）
