[ERC1102] Ethereumアカウントを安全にサイトに接続する仕組みを理解しよう！

はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

今回は、ユーザーの許可があるまでEthereumアカウントをWebサイトに開示しないことで、プライバシーと安全性を高める新しい接続ルールの仕組みを提案しているERC1102についてまとめていきます！

以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。

EIP-1102: Opt-in account exposureEthereum Improvement Proposals

他にも様々なEIPについてまとめています。

Notion | Where teams and agents work togetherMade in Notion, the connected workspace where AI agents and teams organize docs, projects and knowledge together.Notion

概要

ERC1102は、dApp（分散型アプリケーション）とEthereumに対応したDOM環境（例えば、ブラウザの拡張機能）との間で、安全に情報をやり取りするための通信プロトコルを定義するものです。従来のEthereum対応ブラウザでは、ページの読み込み時に自動的にユーザーのEthereumアカウントがJavaScript環境に注入される仕組みが使われていましたが、この新しいプロトコルでは、ユーザーが明示的に同意するまでアカウント情報を開示しないように設計されています。

この仕組みにより、ユーザーのプライバシーとセキュリティが向上し、悪意のあるWebサイトによって勝手に取引が実行されたり、個人情報が収集されるリスクを軽減できます。

動機

これまでのEthereum対応ブラウザや拡張機能は、ユーザーの許可を得る前からEthereumアカウントをWebページに自動的に提供する設計になっていました。そのため、WebサイトのJavaScriptがユーザーの知らないうちにアカウントのアドレスを取得したり、不正なトランザクションを発行するなどのセキュリティ上のリスクが存在していました。

このようなリスクに対応するために、ERC1102では「ユーザーが明確にアクセスを許可した後にのみ、アカウント情報を提供する」という形にプロトコルを変更します。これにより、ユーザー自身がいつ・どのdAppに対してアカウント情報を開示するかを完全に制御できるようになります。

ERC1102は、dAppとブラウザの連携方法に新しい標準的な枠組みを与えることで、より安全で信頼性の高いWeb3体験の提供を目指しています。

仕様

この仕様は、Ethereum対応ブラウザ（MetaMaskなど）とdApp（分散型アプリケーション）がどのようにアカウント情報をやり取りするかを定めた通信プロトコルを示しています。従来の自動アカウント注入方式を見直し、ユーザーの明示的な許可があって初めてアカウント情報を開示する方式に移行するためのルールが定義されています。

`eth_requestAccounts` メソッド

Ethereum対応ブラウザが提供する eth_requestAccounts は、新しいアカウントアクセスのリクエスト手法です。 dAppがこのメソッドを呼び出すと、ユーザーにアカウントアクセスを許可するかどうかを尋ねる画面が表示されます。ユーザーが許可すれば、Promiseがアカウント配列とともに解決されます。拒否された場合はエラーとしてrejectされます。

javascript

const accounts = await ethereum.send('eth_requestAccounts');

このメソッドは、ユーザーの意思によって明示的にアカウント情報を提供する仕組みを可能にし、プライバシーとセキュリティを向上させます。

`provider.enable()` の廃止

以前は ethereum.enable() メソッドが使われていましたが、現在は非推奨となり、eth_requestAccounts の使用が推奨されています。両者とも似た動作をしますが、新しい eth_requestAccounts の方が明確な標準として定義されています。

初期化プロトコルの変更

従来のdAppは、web3 がブラウザに存在しているかどうかで動作を決定していました。しかし、これはセキュリティ上の問題を含んでいました。 ERC1102で提案されている新しい初期化方法では、dAppは window.ethereum にアクセスし、明示的にアカウントアクセスを要求します。ユーザーが許可した場合のみ、アカウント情報がdAppに渡されます。

新しい初期化フローは次のようになります。

javascript

try {
  const accounts = await ethereum.send('eth_requestAccounts');
  // accounts[0]を使ってトランザクションなどを実行
  ethereum.send('eth_sendTransaction', { from: accounts[0], ... });
} catch (error) {
  // アクセス拒否された場合の処理
}

要件と制約

この仕様を実装するEthereum対応ブラウザには、以下のような要件があります。

ブラウザは window.ethereum に provider を公開しなければなりません。
eth_requestAccounts メソッドを実装しなければなりません。
Promiseの解決・拒否はユーザーの操作を待ってから行っても構いません。
アカウントが1つも提供できない場合、Promiseは理由を明記したエラーで拒否されなければなりません。
Promiseが成功した場合には、少なくとも1つ以上のアカウントを含める必要があります。

補足

背景と目的

従来のEthereum対応ブラウザ（DOM環境）では、Webページを開いた時点で自動的にユーザーのアカウント情報を提供する設計が一般的でした。この設計は利便性を重視したものでしたが、ユーザーのプライバシーやセキュリティの観点からは大きな問題がありました。

例えば、信頼できないWebサイトが勝手にユーザーのEthereumアドレスを取得したり、あたかもユーザー自身が発行したかのようにトランザクションを開始できてしまう可能性があります。多くのユーザーはそうした不正なトランザクションを拒否するとはいえ、「ユーザーが拒否すればいい」という設計は本質的な防御にはなりません。

ERC1102では、アカウント情報の取得を明示的なユーザーの同意に基づいて行うことを必須とすることで、こうした問題を根本的に解消しようとしています。

即時的な利点

この新しいプロトコルの導入により、ユーザーは信頼できないWebサイトに対して以下のことができるようになります。

アカウント情報の非公開を選択できる。
アカウントを非公開にすることで、不正なトランザクションの発行を未然に防げる。

これにより、dAppが自動的に情報へアクセスするリスクが排除され、Web3におけるユーザー体験がより安全なものになります。

将来的な展開

このプロトコルは、単に「アカウント情報を隠す」ことだけにとどまりません。将来的には、ユーザーの同意に基づいて、特定の情報やネットワークへのアクセスを選択的に許可する設計にも拡張可能です。

例えば以下のような利用が想定されます。

特定のアカウント情報（uPortやDIDなど）を明示的に許可。
特定のネットワーク（例：L2）への接続要求にユーザーが応答。
ユーザーが選択した条件ごとに情報の共有範囲を細かく制御。

このように、ユーザーの同意に基づく柔軟な情報管理が可能になり、Web3のユーザー体験はより高度で安心なものに進化していくことが期待されています。

互換性と移行の影響

このプロトコルの導入は、dApp開発者とEthereum対応ブラウザ（拡張機能など）の開発者双方に影響を及ぼします。

dApp側では、従来のように自動的にアカウント情報へアクセスすることはできなくなり、代わりに eth_requestAccounts を通じたアカウントアクセスの明示的リクエストが必要になります。ブラウザ側では、アカウント情報の提供をユーザーの同意によって制御する実装が求められます。

つまり、この提案はdAppとブラウザの両方に対して新たな標準への対応を促すものであり、今後のEthereumエコシステム全体にわたるセキュリティ向上のための基盤となります。

引用

Paul Bouchon mail@bitpshr.net, Erik Marks (@rekmarks), "EIP-1102: Opt-in account exposure [DRAFT]," Ethereum Improvement Proposals, no. 1102, May 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1102.