I’ve been through the respective differences between the EthQL and this standard a few times and it looks like a lot of work has been done to align them. On the EthQL side, there are some things that can be done to align some of the more minor differences. There are also some comments I wanted to rehash from previous conversations.
There were a few comments made in previous conversations that seemed like the biggest differences that I wanted to align on.
Big integers should probably have their own scalar type, not just String
Likewise, hex-encoded byte strings other than addresses and hashes should have their own types.
Agreed. The additional specificity is needed for standards.
There are a number of “conveniences” that EthQL layers on top of the raw output to give to dApp developers. Among them, you mentioned additional transaction filters, expressing values in selectable base units, and decoding things like Solidity storage layout. For something baked into a node, the additional complexity / overhead for that is not needed and as we work with EthQL it does feel like there is a Standard API and an Extended API that provides the type of application side processing one would do.
For arguments that reference a block, the EIP limits to blockNumbers. What about adding back the string based references of “latest”, “earliest”, and “pending”?
Also, are there small conveniences we could bake into the standard? For transaction status, the
null values feels like an enum. EthQL has them defined as
There are some methods that went unimplemented in this EIP
eth_newFilter and the like. Are you thinking that Subscriptions would be included in a future EIP?