# [EIP2700] JavaScriptJavaScriptクライアントへEthereumの状態変化を通知する標準の提案を理解しよう！ > JavaScriptで作成されたアプリケーションがEthereumのプロバイダー（Ethereumと通信を行うためのサービスやソフトウェア）からチェーンの状態変化についての通知を受け取るための仕組みの標準化について説明しています。 - URL: https://cardene.dev/articles/bff71aec3f8c45c10a85 - 公開日: 2024-02-29 - 更新日: 2024-02-29 - トピック: Blockchain - タグ: ethereum, solidity, smartcontract, ブロックチェーン ## はじめに 初めまして。 **CryptoGames**というブロックチェーンゲーム企業でエンジニアをしている **cardene（かるでね）** です！ スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。 https://cryptogames.co.jp/ 代表的なゲームは**クリプトスペルズ**というブロックチェーンゲームです。 https://cryptospells.jp/ 今回は、JavaScriptアプリケーションが、Ethereumプロバイダーからブロックチェーンの状態変化に関する通知を受け取るための共通のオブジェクトについて提案している**EIP2700**についてまとめていきます！ :::message 以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。 ::: https://eips.ethereum.org/EIPS/eip-2700 他にも様々なEIPについてまとめています。 https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4 ## 概要 JavaScriptで作成されたアプリケーションがEthereumのプロバイダー（Ethereumと通信を行うためのサービスやソフトウェア）からチェーンの状態変化についての通知を受け取るための仕組みの標準化について説明しています。 #### 全体像 EthereumのプロバイダーとJavaScriptアプリケーションは共有されたJavaScriptオブジェクトを介して互いに通信できます。 この標準は、JavaScriptアプリケーションが利用できるオブジェクトを提供し、そのオブジェクトを通じてEthereumプロバイダーからの通知を受け取る方法を定義しています。 #### 通知メカニズムの説明 この標準は、通知を受け取るためのメカニズムに焦点を当てており、具体的な通知の内容（ペイロード）や、クライアントとプロバイダーがどのようにしてその内容について合意するかについては定めていません。 つまり、何が通知されるか（例えば、トランザクションの成功やブロックの追加など）はこの標準の範囲外です。 #### 実装と発見の未定義 このオブジェクトがどのようにしてJavaScriptアプリケーションに公開されるか、またクライアントやプロバイダーがどのようにしてこのオブジェクトを見つけ出し利用するかについては、この標準では定められておらず、将来の標準で扱われることになります。 :::message この標準は「**Ethereumの状態が変わったときに、JavaScriptアプリケーションがその変更を検知できるようにするための共通の方法を提案している**」ということになります。 しかし、その方法がどのように実装されるか、どのような情報が交換されるかについては、この標準では触れられていません。 ## 動機 JavaScript実行環境（NodeJS、Electron、ブラウザなど）内でEthereumのプロバイダーをJavaScriptアプリケーションやスクリプトに公開する方法について説明しています。 #### 実行環境のカスタマイズ JavaScript実行環境、またはそのプラグインは、特定のオブジェクトを実行環境に注入することができます。 これにより、実行環境を作成する人やプラグインを開発する人は、実行環境内で実行されているJavaScriptアプリケーションやスクリプトに対し、特定の機能やデータを提供することが可能になります。 #### Ethereumプロバイダーの公開 実行環境の作成者やプラグインの開発者は、Ethereumのブロックチェーンの状態変化に関する通知を提供する目的で、Ethereumプロバイダーを公開することを選択するかもしれません。 これは、アプリケーションがEthereumブロックチェーンと対話するためのインターフェイスを提供することを意味します。 #### 標準の必要性 プロバイダーとクライアント間で最大限の互換性を確保するためには、公開されるオブジェクトの形状（つまり、その構造や提供するメソッドなど）に関する標準が必要です。 これにより、異なる実行環境やプラグイン間でも、Ethereumプロバイダーを利用する際の一貫性が保たれ、開発者がより簡単にEthereumとの連携機能を実装できるようになります。 :::message JavaScriptの実行環境内でEthereumブロックチェーンの情報にアクセスし、状態の変化を検知するための標準化された方法を提供することの重要性について述べています。 これにより、開発者はさまざまな実行環境においても、ブロックチェーンのデータに一貫してアクセスできるようになります。 ::: ## 仕様 EthereumプロバイダーのJavaScriptインターフェイスを定義している部分であり、主にイベントリスナーの追加や削除に関するメソッドを指定しています。 #### インターフェイスの定義 `EthereumProvider`インターフェイスには、`on`と`removeListener`の2つのメソッドがあります。 `on`メソッドは、特定のイベント名(`eventName`)と、そのイベントが発生した時に呼び出されるリスナー関数(`listener`)を引数にとります。 `removeListener`メソッドは、`on`で追加されたリスナーを削除するために使用されます。 #### 振る舞いの要件 `on`メソッドによって、プロバイダーが認識しているイベント名が指定された場合、そのイベントが発生すると指定されたリスナーが呼び出される必要があります。 同じリスナーが`on`を通じて同じイベントに複数回追加された場合、プロバイダーはリスナーを一回だけ呼び出すか、`on`が呼び出された回数ごとに一回ずつ呼び出すかを選択できます。 `removeListener`が`on`を通じて追加されたイベント名とリスナーで呼び出された場合、プロバイダーはそのイベントに対するリスナーの呼び出し回数を一回減らす必要があります。 #### イベントとリスナーの具体的な定義 リスナーを通じて聞くことができる特定のイベントやリスナーのコールバック関数の形は、この部分では定義されておらず、別の標準で定められることになります。 EthereumプロバイダーがJavaScriptアプリケーションとどのようにインタラクションするか、特にイベントの監視とリスナーの管理に関して、基本的なルールや振る舞いの枠組みを設定しています。 ## 補足 Ethereum Improvement Proposal (EIP) について述べており、既存の仕様を公式化するものであることを指摘しています。 これは、基本的には後から振り返り、すでに使われている仕様を正式な形で文書化することを意味しています。 #### 後方振り返りのEIP このEIPは、既に存在する仕様をコード化するもので、そのため新たな改善を加える余地はあまりありません。 つまり、このEIPは、現状を正式に文書化することに重点を置いています。 #### 改善の限界 たとえば、リスナーパラメーターに差別化されたユニオンオブジェクトを使用したり、`on`メソッドの定義をより厳密にするといった改善は、このEIPではあまり取り入れられていません。 これは、すでに使われている仕様を基にしているため、大幅な変更を加える余地が少ないからです。 #### イベントの意図的な省略 このEIPでは、リスナーが監視できる特定のイベントについては意図的に記載されていません。 その理由は、イベントのセットが常に進化していくものであり、最初にここでいくつかを挙げたとしても、時間が経つにつれてそれらが廃止されたり、使用されなくなる可能性があるためです。 このアプローチにより、EIPは時間の経過と共にその価値を失うことなく、柔軟性を保つことができます。 :::message このEIPは主に形式的な文書化に関わっており、Ethereumのインタフェースの既存の実装を標準として定めています。 それは、将来的に発展する可能性のある部分（特定のイベントなど）については開かれた状態にしておくことで、柔軟性と適応性を保持しています。 ::: ## セキュリティ Ethereumプロバイダーとクライアント間の関係性について説明しています。 ここでのポイントは、この関係が信頼に基づいているということです。 #### 信頼関係 クライアント（Ethereumとのやり取りを行うためのアプリケーションやスクリプトなど）とEthereumプロバイダー（Ethereumネットワークへの接続を提供するサービス）の間には、信頼関係が存在します。 これは、ユーザーがプロバイダーを信頼していることを前提としています。 #### プロバイダーの導入 この信頼関係は、プロバイダーがクライアントにinjectされた方法、またはクライアントが明示的にプロバイダーに接続を求めた方法によっても示されています。つまり、プロバイダーがクライアント内に存在するのは、ユーザーがそれを許可した、または望んだ結果であると考えられます。 #### 暗黙の信頼 ユーザーは、Ethereumプロバイダーが自分のクライアント内で動作することを暗黙のうちに信頼しています。 これは、ユーザーがプロバイダーを選択し、その使用を許可しているためです。 :::message このテキストはEthereumプロバイダーとクライアントの関係がユーザーの信頼に基づいて成立していることを指摘しています。 ユーザーはプロバイダーを信用しており、その結果としてプロバイダーはクライアントに組み込まれたり、クライアントからアクセスされたりしています。 ::: ## 引用 Micah Zoltu (@MicahZoltu), Erik Marks (@rekmarks), "EIP-2700: JavaScript Provider Event Emitter," Ethereum Improvement Proposals, no. 2700, June 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2700. ## 最後に 今回は「JavaScriptアプリケーションが、Ethereumプロバイダーからブロックチェーンの状態変化に関する通知を受け取るための共通のオブジェクトについて提案している**EIP2700**」についてまとめてきました！ いかがだったでしょうか？ 質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！ [Twitter @cardene777](https://twitter.com/cardene777) 他の媒体でも情報発信しているのでぜひ他も見ていってください！ https://chaldene.net/ https://zenn.dev/heku https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58 https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4