Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify subscription API #496

Open
s1na opened this issue Nov 23, 2023 · 1 comment
Open

Specify subscription API #496

s1na opened this issue Nov 23, 2023 · 1 comment

Comments

@s1na
Copy link
Contributor

s1na commented Nov 23, 2023

Most EL clients implement the subscription API documented here: https://geth.ethereum.org/docs/interacting-with-geth/rpc/pubsub. These are widely adopted but not yet included in the specs. It's easy to specify eth_subscribe and eth_unsubscribe. I'm unsure how to specify the concrete methods (newHeads, newPendingTransactions, etc.) as they are passed as parameters to eth_subscribe. Plus when we push data, we're effectively sending an eth_subscription request from server to the client, and the data for that request depends on the concrete method.

After the current state is done I'd like to propose the following modifications:

  • Adding an optional parameter to newPendingTransactions named fullTx. It defaults to false. If true the server returns the full tx object instead of the hash. This is already merged in geth.
  • Adding an optional parameter to newHeads named verbosity. Default value of 0 returns only the hash. If value is 1, we return the complete head object. If value is 2, we return the complete block object. If value is 3 we return the block object + receipts.
  • Add optional parameter to newPendingTransactions named filter. The server uses the filter to narrow down the list of txes to return.
@s1na
Copy link
Contributor Author

s1na commented Nov 29, 2023

Open-RPC cannot express the semantics of the eth_subscribe. It is one method that can have a different set of params based on the event type. E.g.:

  • If type is logs next param can be a filter { address: .., topics: ..}
  • The other types don't have at the moment further parameters.

The same thing happens in the notification requests, i.e. eth_subscription. Each event returns a different object. Because the parameters of this request are addressed by key, we could define a schema with keys for all possible event types. But that's less than ideal.

There exists an issue open-rpc/spec#381 which if fixed would unblock this item.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant