RPC Standards 2 - March 17, 2025

[jflo]

RPC Standards 2, March 17, 2025

Date & Time: March 17th, 2025, 15:00 UTC

• Duration in minutes : 60
• Recurring meeting : true (true will trigger reccuring meeting with youtube streams on Ethereum protocol youtube channel)
• Occurrence rate : bi-weekly
• Other optional resources

Agenda

• Example of asserting on raw error messages that are client specific
• standardize the API to prefer decimal integers over hex for all numbers. Hex should be reserved for raw data fields. Large integers will likely need to be quoted strings.
• removing "aged out" fields or versioning api calls?
• Review https://github.com/ethereum/execution-apis/pull/600/files and figure out next steps.

Other comments and resources

The zoom link will be sent to the facilitator (please fill in the email and telegram)
Facilitator email: justin@florentine.us
Facilitator telegram: @RoboCopsGoneMad

[jflo]

would love to standardize the API to prefer decimal integers over hex for all numbers. Hex should be reserved for raw data fields. Large integers will likely need to be quoted strings.

How would we go about specifying this, changing it, and how should clients roll it out?

[jflo]

Review https://github.com/ethereum/execution-apis/pull/600/files and figure out next steps.

[jflo]

Have we collected where we are asserting on error messages? For example we found this one in hive at debug_getRawTransaction/get-invalid-hash

"invalid argument 0: json: cannot unmarshal hex string without 0x prefix into Go value of type common.Hash"

[jflo]

methods like eth_getBlock return legacy fields like totalTerminalDifficulty. does dropping them warrant an uprev of the rpc call, or could the field be ommitted?

[poojaranjan]

Recording: https://www.youtube.com/watch?v=WcFNYCEDHqs

[bomanaps]

RPC Standards-2 summary

Action Items:

Error Handling:

• Filter out or ignore client-specific error messages in RPC compatibility tests.
• Standardize error messaging across clients, using the Engine API as a reference.

Process for Spec Updates:

• Identify and revive relevant EIPs/ERCs to serve as a foundation for RPC standardization.
• Use GitHub pull requests and Discord (RPC channel) for asynchronous collaboration.

Data Representation:

• Standardize the representation of integers as decimal values (wrapped in strings) and reserve hex for raw binary data.
• Follow up on any existing PRs or issues related to this proposal.

Aged-Out Fields:

• Add guidelines to the RPC spec for handling optional fields, particularly those that are no longer relevant post-Merge.

PR #600:

• Encourage broader participation and feedback on the PR from the working group.
• Use the PR as a model for standardizing error handling across the RPC spec, assuming it is approved and merged.

Key Discussion Points:

Error Handling and Assertions on Raw Error Messages:

• The team discussed an issue where RPC compatibility tests failed due to assertions on Go-specific (Geth) error messages. This was observed in tests running against Besu.
• The error messages are likely present because Geth is used as the test filler, which is the reference implementation.
• Action Item: Consider filtering out or ignoring these specific error messages in the tests to avoid compatibility issues.

Standardization of Error Messaging:

• Discrepancies in error messages between different clients were identified as a common issue.
• The team agreed on the need to standardize error messaging across clients to ensure consistency.
• Action Item: Explore ways to standardize error handling and reporting, potentially using the Engine API as a model.

Process for Updating the RPC Spec:

• The team discussed the lack of a clear process for updating the RPC specification when issues are identified.
• Suggestions included creating a centralized document or using GitHub pull requests to manage updates.
• Action Item: Identify and revive any existing EIPs or ERCs related to RPC standards, and use them as a foundation for future updates.

Engagement with RPC Providers:

• The team emphasized the importance of involving RPC providers (e.g., Alchemy, Infura) in the standardization process.
• These providers often run multiple clients and could benefit from more standardized RPC behavior, reducing the need for custom load balancing and normalization.

Representation of Data (Hex vs. Decimal):

• The team noted that some APIs represent integer values as hex, which can be inconvenient for developers who prefer decimal notation.
• A proposal was discussed to standardize the representation of integers as decimal values (wrapped in strings for large numbers) and reserve hex for raw binary data.
• Action Item: Follow up on a potential PR or issue related to this proposal and consider incorporating it into the RPC spec.

Handling Aged-Out Fields (e.g., Total Difficulty):

• The team discussed how to handle fields that are no longer relevant post-Merge (e.g., total difficulty).
• Options included making such fields optional or removing them entirely, with a preference for avoiding API versioning.
• Action Item: Add a section to the RPC spec document outlining guidelines for optional fields and how clients should handle them.

Execution APIs Pull Request #600:

• The team reviewed PR 600, which focuses on improving error handling for call methods.
• The PR was seen as a potential model for broader error handling improvements across the RPC spec.

Next Steps:

• Carrie will post relevant EIPs/ERCs in the RPC channel on Discord for further discussion.
• Team members will review and provide feedback on PR 600.
• All participants are encouraged to join future calls and contribute to the ongoing standardization efforts.