1193: single object argument for request method

[rekmarks]

File: https://github.com/rekmarks/EIPs/blob/1193-request-arg/EIPS/eip-1193.md

New signature for the request method:

interface RequestArguments {
  method: string;
  params?: Array<any> | { [key: string]: any };
  [key: string]: any;
}

Provider.request(args: RequestArguments): Promise<unknown>;

Example call:

Provider.request({ method: 'eth_accounts' })
  .then((accounts) => console.log(accounts))
  .catch((error) => console.error(error));

See document for further details.

This is motivated by discussions with @frozeman and others, and enables a future for the Provider interface generally and the request method specifically where any of the following holds:

• Multiple chains are served by a single Provider at once
• Multiple protocols are served by a single Provider at once
• The Provider needs some kind of metadata submitted along with request calls, for reasons we are unable to anticipate today

If we want EIP 1193 to function "in perpetuity", why not make the request method maximally flexible?

[eip-automerger]

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

• EIP 1193 requires approval from one of (@MaiaVictor, @frozeman, @marcgarreau, @ryanio)

[adrianmcli]

Just a question.

[adrianmcli]

This line can also be written like this, right?

params: {
  latest: true
}

[adrianmcli]

This example seems a little more straight-forward to understand when written as an object instead of an array.

[rekmarks]

Hm, I don't know if the params can be given in object form. I imagine it's just following: https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getblockbynumber

[rekmarks]

By the method's interface the params can certainly be given as an object, but whatever the specific RPC method's definition says, goes.

[adrianmcli]

Ah nevermind, I confused myself. However the type annotation (on line 32) here makes it seems like params can either be an array of anything or an object?

params?: Array<any> | { [key: string]: any };

[adrianmcli]

But in the official JSON-RPC, it seems like it is always an array.

[adrianmcli]

This part confuses me because it seems to indicate that the params property can either be an array of stuff or an object. But the JSON-RPC only ever lists them out as arrays.

[ryanio]

@adrianmcli the ethereum json rpc api has traditionally accepted an array for params, however the official json-rpc spec does specify that params can also be passed as a by-name object. The real reason why I recently made it optional was not only this realization but also to support graphql queries in the future so method can == query and params can == variables.

Hope that adds some clarity :)

[rekmarks]

@adrianmcli @ryanio, I'm thinking we should just change params to any and refer to the RPC method's own documentation, adding that for Ethereum JSON RPC (by far of course the most important one right now), always expects an Array. Since we want the spec to be RPC protocol-agnostic, there's no real reason to follow its specification for params.

Any thoughts on that? I might just push a commit so we can get a feel for it.

[MicahZoltu]

Same comments as above about any. Always prefer unknown.

[rekmarks]

My bad for not clarifying: all references to any were changed to unknown in 7753ce8

[MicahZoltu]

I'm not personally a fan of this change as it hurts the ergonomics of using these functions and doesn't actually solve the versioning problem (which I do agree is a problem that should be solved). While options objects give a bit more flexibility in terms of versioning, you still need some larger versioning mechanism in place to make this useful and if you have a versioning system you can just have versioned function signatures.

[MicahZoltu]

That being said, ergonomics are not a blocker for me on 1193, so if that is what everyone else wants I'll capitulate.

[rekmarks]

@MicahZoltu, I also find ergonomics important, although I personally find the difference negligible in this case, especially in light of the gains in extensibility.

On that note, this change is only meant to address extensibility, not versioning. I still firmly support the creation of a Provider versioning EIP, and may put my time where my mouth is, too.

Thanks for the review; I always appreciate your input!

[ryanio]

Looks great, thank you!

[frozeman]

Great to see this moving forward