はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、ユーザーのENSドメインに記録されたメタデータを使って、対応するウォレットプロバイダを自動的に判別・接続し、どのウォレットでもDappにログインできる仕組みを提案しているERC2525についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIPについてまとめています。
概要
ERC2525は、Ethereumブロックチェーンへのユニバーサルなログイン方法を改善する仕組みを提案しています。 中心となるアイデアは、ENS（Ethereum Name Service）のメタデータ機能を活用することで、ユーザーがどのウォレットプロバイダを使用しているかを特定し、Dapp側が自動的にその情報を利用してログイン処理を行うというものです。
ここで「ログインしている」とみなすのは、トランザクションやメッセージへの署名が可能なEIP1193準拠のプロバイダを利用できる状態を指します。 この方法は、Alex Van de Sande 氏の提案や Web3Connect から影響を受けています。
将来的には、このアプローチを Ethereum だけでなく、あらゆるブロックチェーンで利用可能に拡張することが目指されています。
動機
Ethereumブロックチェーンとやり取りするためのウォレットソリューションには多様な選択肢があります。 例えば、MetaMask や Gnosis Safe のように、Dapp開発者の手間を省きつつユーザーのブラウザにウォレットを注入するタイプのものがありますが、ユーザー側には拡張機能のインストールなどの手間がかかります。
一方で、Portis や Authereum、Torus、Universal Login のようなソリューションは、暗号資産に不慣れなユーザーでもシームレスに利用できる一方、Dapp開発者にはそれぞれのサービスごとの統合作業が必要となります。 ハードウェアウォレット（Ledger、Trezor、KeepKeyなど）も同様に、統合の手間がかかります。
Dappが複数のウォレットソリューションを統合しようとすると、最終的には「どのウォレットを使うか」の判断をユーザーに委ねる必要があります。 しかし、この選択肢が増えることで、特に初心者ユーザーにとっては複雑化して使いづらくなります。 また、Dappが特定のウォレットだけをサポートするようになると、既存の有名ウォレットだけが優位になり、新しいウォレットの普及が難しくなるため、競争が阻害されてイノベーションが停滞する懸念もあります。
ENSLoginではこの課題を解決するために、ユーザーが所有するENSドメインをログインの入口として利用します。 ENSドメインに紐づけられたメタデータにより、ユーザーが使用しているウォレットプロバイダを特定し、Dapp側がそれに対応した接続を自動で行えるようにします。
この仕組みによって、ユーザーは自分のENSドメインを用いるだけで、どのDappに対しても、どのウォレットを使っていても簡単にログインできるようになります。
仕様
ENSLoginは、ユーザーのENSドメインに記録されたメタデータを用いて、対応するウォレットプロバイダを自動的に判別してDappと接続するための仕組みです。 ログインフローはSDKとして実装され、Dapp開発者はこのSDKを導入するだけで複数ウォレット対応を実現できます。
仕組みの流れ
- ユーザーにENSドメインを入力してもらう。
- ENSドメインから以下を解決する（EIP137に準拠）
- アドレス
- テキストエントリ（EIP634に準拠）
- テキストエントリの内容を解釈し、指定されたファイルをダウンロード。
- ダウンロードしたファイルの内容を評価。
- Web3プロバイダオブジェクトをDappに返す。
- Dappはこのプロバイダを用いて通常のWeb3処理を開始できる（例：
enable()呼び出しによるログイン認証など）。
EIP137については以下の記事を参考にしてください。
この一連の処理はSDKが担い、中央集権／分散型ストレージの両方に対応します。 ただし、ウォレットプロバイダ固有のコードはSDKには含まれず、外部ファイルで提供されます。
詳細
テキストエントリの解決
ENSのテキストエントリ機能（EIP634）を使って、ウォレットプロバイダをインスタンス化するためのコードへのポインタ（URLなど）を取得します。
使用するキーは enslogin（変更の可能性あり）で、該当ドメインに存在しない場合は親ノードの enslogin-default にフォールバックします。
例）username.domain.eth の場合
resolver.at(ens.owner(nodehash("username.domain.eth"))).text(nodehash("username.domain.eth"), 'enslogin')
resolver.at(ens.owner(nodehash("domain.eth"))).text(nodehash("domain.eth"), 'enslogin-default')プロバイダのリンク形式
ウォレットプロバイダのコードは、標準的なスキーム（scheme://path）で指定します。 例）
ipfs://Qm123456.../60/jshttps://server.com/enslogin-module-someprovider/60/js
ここで「60」はSLIP44で定義されたEthereumの番号、「js」はJavaScriptを示します。
プロバイダの初期化
対象ファイルは、以下の形式の関数を提供する必要があります。
global.provider = (config) => Promise<web3provider>戻り値はEIP1193に準拠したプロバイダオブジェクトのPromiseです。 Ethereum以外のブロックチェーンにも将来的に対応予定です。
コンフィグオブジェクト
Dappはプロバイダ初期化時に設定情報を渡せます。
provider: ネットワークやENSコントラクトのアドレスなど_- ウォレットプロバイダ固有のオプション（先頭に
_）
- ウォレットプロバイダ固有のオプション（先頭に
__- SDK用のオプション（先頭に
__）
- SDK用のオプション（先頭に
最小構成例
{
"provider": {
"network": "goerli"
}
}高度な構成例
{
"provider": {
"network": "goerli",
"ens": "0x112234455c3a32fd11230c42e7bccd4a84e02010"
},
"ipfs": {
"host": "ipfs.infura.io",
"port": 5001,
"protocol": "https"
},
"_authereum": {...},
"_portis": {...},
"__callbacks": {
"resolved": (username, addr, descr) => { ... },
"loading": (protocol, path) => { ... },
"loaded": (protocol, path) => { ... }
}
}将来的にはSLIP44によるブロックチェーン識別子をコンフィグに加えることが検討されています。
分散性について
ENSLoginは、Web3Connectのような中央集権的な方式とは異なり、完全に分散型の設計です。 SDKはEthereumおよびストレージプロトコル（https, ipfs等）への解決処理だけを担い、ウォレットの選定や登録に中央の審査が不要です。
これにより、新しいウォレットプロバイダも、自身のコードを対応フォーマットで公開するだけで、すべてのENSLogin対応Dappで即時利用可能になります。 SDKをアップデートすることなく、新しいウォレットが利用できる柔軟な仕組みです。
インセンティブ設計
ENSLoginは、Dapp開発者とウォレットプロバイダの両方の利害を一致させる構造を持っています。
- ウォレットプロバイダ側
- ENSに必要なエントリとコードを公開するだけで、全Dappと互換性が得られるため、導入のハードルが大幅に下がります。
- Dapp開発者側
- SDKを導入するだけで、すべての互換ウォレットと接続できるようになります。
- ユーザー数の拡大が容易になります。
ユーザー側にとっても、対応ウォレットであれば設定不要でそのままログイン可能です。 より詳しく操作したいユーザーはENS上のメタデータを自分で編集することも可能です。
課題と制限
ENSLoginはDappと任意のウォレットとの連携を可能にしますが、「どのウォレットを使って登録を始めるか」という初期選択については、Dapp側で推奨UI（Web3ConnectやBlockNativeのようなコンポーネント）を提供する必要があります。
サポートコミュニティ
以下が、指定された情報を元にしたMarkdown形式の表です。
| Name | Live | Module | Assigns ENS names | Support by default |
|---|---|---|---|---|
| Argent | yes | no | yes | no |
| Authereum | yes | yes | yes | no |
| Fortmatic | yes | no | no | no |
| Gnosis Safe | yes | yes* | no | no |
| Ledger | yes | beta | no | no |
| KeepKey | yes | no | no | no |
| Metamask | yes | yes | no | no |
| Opera | yes | yes* | no | no |
| Portis | yes | yes | no | no |
| SquareLink | yes | no | no | no |
| Shipl | no | no | no | no |
| Torus | yes | yes | no | no |
| Trezor | yes | no | no | no |
| UniLogin | beta | beta | yes | no |
* uses the Metamask module
よくある質問
- 他人が自分のログイン情報で接続することはありますか？
- 秘密鍵はどこに保存されますか？
ENSLoginは、ENSに記録された情報（アドレスと使用しているウォレットプロバイダ）にしかアクセスできません。 秘密鍵の管理はウォレットプロバイダが行っており、ENSLoginの範囲外です。
ウォレットプロバイダによって秘密鍵の保存場所や管理方法は異なります。
- 一部のプロバイダは、秘密鍵をユーザーのローカルディスクに保存します。
- 別のプロバイダは、カストディアル方式（管理者預かり）で安全なリモートサーバー上に秘密鍵を保管します。
- また、ハードウェアウォレットのように、署名処理を専用デバイス上で完結させることで秘密鍵が外部に漏れない設計のものもあります。
このように、ENSLogin自体が秘密鍵にアクセスすることはなく、ログインの安全性は各ウォレットプロバイダの実装とセキュリティに依存しています。
引用
Hadrien Croubois (@amxx), "ERC-2525: ENSLogin [DRAFT]," Ethereum Improvement Proposals, no. 2525, February 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2525.
最後に
今回は「ユーザーのENSドメインに記録されたメタデータを使って、対応するウォレットプロバイダを自動的に判別・接続し、どのウォレットでもDappにログインできる仕組みを提案しているERC2525」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！
