You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The role of rpc-compat hive tests. How do clients perceive the value of these tests? We maintain them as a separate artefact in the execution-apis repo so that clients can pull them into their unit tests. But nobody does that, probably. They also run on hive, but there are a lot of minor client issues that prevent them from being green. Ideally we'd reach a point where all clients pass all tests.
Spec considerations: we have some stuff in the spec for backwards-compatibility, like v signature value on transactions. It's hard to remove because the RPC client space is so open-ended, so have opted for keeping this around. I know some client-specific fields exist, such as author on blocks for Nethermind. Should these be added to the spec as well?
How to deal with extension proposals: there are a few open issues on the execution-apis repo where people proposed new methods. Sometimes these proposals would require extensive client changes. What's the process for landing an RPC extension?
The text was updated successfully, but these errors were encountered:
Meeting Info
#json-rpc-api
Discord channel before the callAgenda
See https://notes.ethereum.org/@fjl/rpc-standards-2025-01 for context.
v
signature value on transactions. It's hard to remove because the RPC client space is so open-ended, so have opted for keeping this around. I know some client-specific fields exist, such asauthor
on blocks for Nethermind. Should these be added to the spec as well?The text was updated successfully, but these errors were encountered: