GraphQL interface to Ethereum node data


Good thought. I hadn’t recognised the significance of using ID to other generic graphql tools.

I think your option 2 is better - make IDs opaque to callers, with no guarantees except they’re unique.


I’ve updated the EIP to add a Pending type, and to move account, call and estimateGas to Pending and Block. This also makes it possible now to query transactions in the pending pool, which the schema didn’t previously offer.

Pending has a subset of fields from Block that make sense based on the available data.

I’ve also written a PR updating the geth implementation to reflect these changes.


It is a little strange for query ‘’‘block\miner’’’ to have a ‘’’(block :Long)’’’ augment.

Not sure if people have requirement of query one block for another block’s miner.


Question about output formats. From the current spec

# BigInt is a large integer. Input is accepted as either a JSON number or as a string.
# Strings may be either decimal or 0x-prefixed hexadecimal. Output values are all
# 0x-prefixed hexadecimal.
scalar BigInt
# Long is a 64 bit unsigned integer.
scalar Long

When outputting the json for a transaction some of the fields are Long, such as gasUsed. Should those be outputted as standard json numbers or as hex strings as though it was a BigInt. The lack of formatting instructions leads me to believe the latter.


Any argument that specifies an account has a block number - so you can specify what block you want to fetch that account at.

Good point, we should specify this. The intention is that longs are read and formatted as numbers; GraphQL only specifies a 31 bit integer type, and it’s useful to be able to use a longer (52 bit, safely in Javascript) numeric type.


Also, it may be worth referencing the GraphQL website when saying “implement a graphql endpoint” because there are about 3 ways to do it. GET, POST applicaiton/json, and POST applicaiton/graphql. No need to spell it out in the spec, just reference their page:

1 Like