主页EIPs周刊
EIPsEIP-2700
EIP-2700

JavaScript Provider Event Emitter

FinalStandards Track: Interface
创建时间: 2020-06-05
Micah Zoltu (@MicahZoltu), Erik Marks (@rekmarks)
社区讨论原文链接编辑
1 分钟了解
欢迎补充好内容
去提交
相关视频
欢迎补充好内容
去提交
正文

Simple Summary

A standard mechanism for JavaScript Ethereum Providers to notify clients about chain state changes when both are able to interface with each other via a shared JavaScript object.

Abstract

This standard provides the description of an object that is made available to JavaScript applications which they can use to receive notifications from an Ethereum Provider. This standard only describes the notification mechanism, it does not specify the payloads that are valid nor does it specify how the client or the provider will discover or agree on payload content.

How/where this Ethereum Provider object is exposed is left to future standards.

Motivation

When working within a JavaScript runtime (such as NodeJS, Electron, Browser, etc.) it may be possible for the runtime or a runtime plugin to inject objects into the runtime. Someone authoring a runtime or a runtime plugin may choose to expose an Ethereum Provider to any JavaScript apps or scripts running within that runtime in order to provide notifications of blockchain state changes. In order to achieve maximum compatibility between the provider and the client, a standard is necessary for what the shape of that object is.

Specification

RFC-2119

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119.

Interface

interface EthereumProvider { on(eventName: string, listener: (...params: unknown[]) => void): void removeListener(eventName: string, listener: (...params: unknown[]) => void): void }

The specific events that can be listened to and the shape of their listener callback functions is left to be defined in separate standards.

If on is called with an eventName that the provider is familiar with then the provider MUST call the provided listener when the named event occurs. If the same listener is added multiple times to the same event via on, the provider MAY choose to either callback the listener one time or one time per call to on.

If removeListener is called with an eventName and listener that was previously added via on then the provider MUST decrease the number of times it calls the listener per event by one.

Rationale

This EIP is mostly a retrospective EIP meaning it codifies an already existing specification so there isn't a lot of room for improving things such as by using a discriminated union object for listener parameters or having a tighter definition of on. The specific events are intentionally left out of this specification as that set will be an ever-evolving collection and having the first few listed here doesn't add value to this specification (especially if, over time, the first few end up deprecated or unused).

Security Considerations

The relationship between Ethereum Provider and client is a trusted one, where it is assumed that the user implicitly trusts the Ethereum Provider which is how it managed to get injected into the client, or the client expressly pulled in a connection to it.

Copyright and related rights waived via CC0.

扩展阅读
欢迎补充好内容
去提交

不想错过最新的 EIP 动态?

订阅 EIPs Fun 周刊以跟进相关更新,建⽴你与 EIP 之间的连接 ,更好地建设以太坊。

详情
支持以太坊贡献者,推动生态建设
资源
GitHub
支持社区