Add EIP: RPC Provider Discovery & Capacity API #9832

peersky · 2025-05-28T00:28:37Z

This commit introduces a new EIP that outlines a standard mechanism for Ethereum RPC providers to advertise their service endpoints and operational capacity. It includes discovery methods using DNS-based Service Discovery and direct IP address querying, along with a structured Capacity Information API for real-time metrics. The EIP aims to enhance decentralization, improve user choice, and reduce reliance on centralized endpoints.

eth-bot · 2025-05-28T00:29:05Z

File `EIPS/eip-7959.md`

Requires 1 more reviewers from @g11tech, @lightclient, @SamWilsn

…tisement

…y and Service Advertisement This update improves the consistency of formatting, including the removal of unnecessary escape characters and the correction of typographical errors throughout the document. The changes enhance readability and maintain the clarity of the EIP's content.

…isement

EIPS/eip-0000.md

…agreements (SLA) and accountability mechanisms. Update specifications for Capacity Information API to support SLA details, including optional fields for SLA parameters and dispute resolution. Improve clarity and structure throughout the document.

Darkknight-web

👍🏻

g11tech · 2025-06-09T07:54:11Z

@peersky do you think this is more suited as an ERC? imo EL clients don't need to implement this, a middleware on top would be much better and hence from that viewpoint this is something that clients don't need to implement.

So it would be better as an ERC. wdyt?

peersky · 2025-06-10T06:12:47Z

@peersky do you think this is more suited as an ERC? imo EL clients don't need to implement this, a middleware on top would be much better and hence from that viewpoint this is something that clients don't need to implement.

So it would be better as an ERC. wdyt?

I agree that modular middleware does make sense;

I don't think that current ERC classification can fit in to proposed standard (it's not application level):

Application-level standards and conventions, including contract standards such as token standards (EIP-20), name registries (EIP-137), URI schemes (EIP-681), library/package formats (EIP-190), and account abstraction (EIP-4337).

Perhaps keeping EIP but moving in to networking category could make sense?

github-actions · 2025-06-16T15:39:51Z

The commit 3017969 (as a parent of 39ac116) contains errors.
Please inspect the Run Summary for details.

g11tech · 2025-06-23T08:46:20Z

Perhaps keeping EIP but moving in to networking category could make sense?

since this doesn't has to do with client networking, i doubt it belongs to networking category

peersky · 2025-06-24T15:24:34Z

Perhaps keeping EIP but moving in to networking category could make sense?

since this doesn't has to do with client networking, i doubt it belongs to networking category

That's the reason I submit it as Interface. I would not want to create unnecessary implications on clients who are not seeing this interesting though; Perhaps having MAY over MUST is sufficient (they may support it, but not obliged)

g11tech · 2025-06-24T16:34:25Z

Perhaps keeping EIP but moving in to networking category could make sense?

since this doesn't has to do with client networking, i doubt it belongs to networking category

That's the reason I submit it as Interface. I would not want to create unnecessary implications on clients who are not seeing this interesting though; Perhaps having MAY over MUST is sufficient (they may support it, but not obliged)

could you present me some evidence that some client actually wants to implement/support this? a comment here or in the discussions eth magicians link?

peersky · 2025-06-25T13:13:53Z

Perhaps keeping EIP but moving in to networking category could make sense?

since this doesn't has to do with client networking, i doubt it belongs to networking category

That's the reason I submit it as Interface. I would not want to create unnecessary implications on clients who are not seeing this interesting though; Perhaps having MAY over MUST is sufficient (they may support it, but not obliged)

could you present me some evidence that some client actually wants to implement/support this? a comment here or in the discussions eth magicians link?

It's intended to drive spatial decentralisation trough incentivisation;
Without such, it is impossible to propose any resonable market finance model for RPC ad-hoc avaliablility;

Hence, this standard is not intended to drive clients-wants;

It is for showing in conversations with last mile telecom provider carriers, saying "hey, did you know you can earn extra $ with EVM nodes serving?"

Im not affiliated with any client development teams, but I do have contracts in telecom industry and I am looking ways to create incentives for Ethereum not to be a joke running at one single AWS availability zone with fully centralized, eclipse attack prone, list of 3 bootstrapped nodes hardcoded in client distributions;

SamWilsn · 2025-07-08T16:43:13Z

I agree with @g11tech that this doesn't belong in Networking. Interface is for language / contract level standards and ABIs, so I think this probably belongs in the ERC space. Conceptually it sits roughly around the same level as URI standards. Please re-open this on the ERCs repository (though you can keep the same number).

SamWilsn · 2025-07-08T16:39:21Z

EIPS/eip-7959.md

+created: 2025-05-28
+---
+
+## **Abstract**


Don't bold the headers.

SamWilsn · 2025-07-08T16:40:13Z

EIPS/eip-7959.md

+
+## **Abstract**
+
+This EIP proposes a standard mechanism for Ethereum RPC (Remote Procedure Call) providers, including Internet Service Providers (ISPs) or individual network hops, to advertise their RPC service endpoints, current operational capacity, and optionally, their support for advanced service level agreement (SLA) frameworks. It defines discovery methods using DNS-based Service Discovery (DNS-SD) for domain-based lookups, and direct IP address querying for IP-specific lookups. It also specifies a schema for a machine-readable Capacity Information API endpoint that provides details about available RPC services, their capabilities, real-time capacity metrics, and information pertinent to engaging with them under such formal SLA frameworks.


None of this seems specific to Ethereum.

SamWilsn · 2025-07-08T16:41:05Z

EIPS/eip-7959.md

+* **Service Name:** Providers MUST advertise their service using the following DNS SRV service label:
+    * `_ethrpc-info._tcp`
+* **DNS Query:** Clients SHOULD construct a DNS query for SRV records. For example, if a client's local DNS search path or ISP domain is `example.com`, the query would be for `_ethrpc-info._tcp.example.com`. Clients MAY also allow users to configure specific discovery domains.
+* **SRV Record:** The SRV record (RFC 2782) MUST point to the hostname and port where the provider's Capacity Information API is hosted. Standard SRV priority and weight mechanisms apply.


EIP-1 has instructions for linking to RFCs.

SamWilsn · 2025-07-08T16:44:35Z

EIPS/eip-7959.md

+
+**Field Explanations:**
+
+* specVersion: The version of this EIP's API specification that the response conforms to.


Please put code snippets, like identifiers, in backticks (`).

SamWilsn · 2025-07-08T16:45:46Z

EIPS/eip-7959.md

+
+* **DNS-SD:** Leverages a well-established, standardized, and decentralized service discovery protocol for domain-based discovery. It is widely supported and understood.
+* **Direct IP Address Query:** Provides a straightforward method for clients to query known IP addresses, such as specific network hops or local nodes, without requiring DNS. This is useful for direct probing or in environments where DNS-SD is not available or applicable for the target.
+* **SRV Records:** Standard for specifying the location (host/port) of services in DNS-SD.


These bullet points aren't really, uh, explaining anything. For example, this line is just defining what an SRV record is. Instead, you should use this section to explain why you made a choice, say why you chose to build on top of DNS-SD.

peersky · 2025-07-08T18:14:22Z

I agree with @g11tech that this doesn't belong in Networking.

@SamWilsn I could not disagree more, there is nothing more fundamental in p2p than discovery of peer nodes;

But this is your sandbox, enjoy it.

peersky requested a review from eth-bot as a code owner May 28, 2025 00:28

eth-bot added e-consensus Waiting on editor consensus e-review Waiting on editor to review labels May 28, 2025

peersky added 6 commits May 28, 2025 08:35

Add front matter to EIP-????: RPC Provider Capacity and Service Adver…

490583d

…tisement

Add description to EIP-????: RPC Provider Capacity and Service Advert…

469731d

…isement

rename eip

bf58690

rm wrong file

86553af

Update front matter in EIP-0000 to use standardized field names

dbeab8c

github-actions bot added the w-ci Waiting on CI to pass label May 28, 2025

peersky added 2 commits May 28, 2025 09:10

lint errors

591889d

validation fixes

41ecaca

github-actions bot added w-ci Waiting on CI to pass and removed w-ci Waiting on CI to pass labels May 28, 2025

Update EIP-0000: Correct author casing and refine copyright reference

19003a1

bomanaps reviewed May 29, 2025

View reviewed changes

EIPS/eip-0000.md Outdated Show resolved Hide resolved

EIPS/eip-0000.md Outdated Show resolved Hide resolved

Update eip-0000.md

e4224cc

github-actions bot added c-new Creates a brand new proposal s-draft This EIP is a Draft t-interface labels May 31, 2025

eth-bot changed the title ~~Add EIP for RPC Provider Capacity and Service Advertisement~~ Add EIP: RPC Provider Discovery & Capacity API May 31, 2025

github-actions bot removed the w-ci Waiting on CI to pass label May 31, 2025

peersky added 2 commits June 1, 2025 09:22

happy linter - happy life

ef18d2c

Darkknight-web approved these changes Jun 1, 2025

View reviewed changes

Update and rename eip-0000.md to eip-7959.md

3017969

github-actions bot added the w-ci Waiting on CI to pass label Jun 16, 2025

poojaranjan mentioned this pull request Jul 8, 2025

EIP Editing Office Hour Meeting 64 (EIP + ERC ) | July 08, 2025 ethereum/pm#1596

Closed

37 tasks

SamWilsn closed this Jul 8, 2025

SamWilsn reviewed Jul 8, 2025

View reviewed changes

peersky mentioned this pull request Sep 17, 2025

Add ERC: RPC Provider Discovery & Capacity API ethereum/ERCs#1215

Open


		## Abstract

		This EIP proposes a standard mechanism for Ethereum RPC (Remote Procedure Call) providers, including Internet Service Providers (ISPs) or individual network hops, to advertise their RPC service endpoints, current operational capacity, and optionally, their support for advanced service level agreement (SLA) frameworks. It defines discovery methods using DNS-based Service Discovery (DNS-SD) for domain-based lookups, and direct IP address querying for IP-specific lookups. It also specifies a schema for a machine-readable Capacity Information API endpoint that provides details about available RPC services, their capabilities, real-time capacity metrics, and information pertinent to engaging with them under such formal SLA frameworks.


		Field Explanations:

		* specVersion: The version of this EIP's API specification that the response conforms to.

Add EIP: RPC Provider Discovery & Capacity API #9832

Add EIP: RPC Provider Discovery & Capacity API #9832

Conversation

peersky commented May 28, 2025

Uh oh!

eth-bot commented May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

File EIPS/eip-7959.md

Uh oh!

Uh oh!

Uh oh!

Darkknight-web left a comment

Choose a reason for hiding this comment

Uh oh!

g11tech commented Jun 9, 2025

Uh oh!

peersky commented Jun 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jun 16, 2025

Uh oh!

g11tech commented Jun 23, 2025

Uh oh!

peersky commented Jun 24, 2025

Uh oh!

g11tech commented Jun 24, 2025

Uh oh!

peersky commented Jun 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SamWilsn commented Jul 8, 2025

Uh oh!

SamWilsn Jul 8, 2025

Choose a reason for hiding this comment

Uh oh!

SamWilsn Jul 8, 2025

Choose a reason for hiding this comment

Uh oh!

SamWilsn Jul 8, 2025

Choose a reason for hiding this comment

Uh oh!

SamWilsn Jul 8, 2025

Choose a reason for hiding this comment

Uh oh!

SamWilsn Jul 8, 2025

Choose a reason for hiding this comment

Uh oh!

peersky commented Jul 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

eth-bot commented May 28, 2025 •

edited

Loading

File `EIPS/eip-7959.md`

peersky commented Jun 10, 2025 •

edited

Loading

peersky commented Jun 25, 2025 •

edited

Loading

peersky commented Jul 8, 2025 •

edited

Loading