This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_1767 [2020/11/13 02:16] nick ↷ Links adapted because of a move operation |
dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_1767 [2021/08/18 10:53] (current) murphy |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ==== EIP 1767: GraphQL interface to Ethereum node data (DRAFT) ==== | ==== EIP 1767: GraphQL interface to Ethereum node data (DRAFT) ==== | ||
| - | [[dido:public:ra:xapend:xapend.stds:defact:ethereum:eip| Return to Ethereum ERCs ]] | + | [[dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip| Return to Ethereum ERCs ]] |
| : **Note**: The following is an excerpt from the official Ethereum site. It is provided here as a convenience and is not authoritative. Refer to the original document as the authoritative reference. | : **Note**: The following is an excerpt from the official Ethereum site. It is provided here as a convenience and is not authoritative. Refer to the original document as the authoritative reference. | ||
| Line 16: | Line 16: | ||
| === Abstract === | === Abstract === | ||
| - | : //This EIP specifies a GraphQL schema for accessing data stored on an Ethereum node. It aims to provide a complete replacement to the read-only information exposed via the present JSON-RPC interface, while improving on usability, consistency, efficiency, and future-proofing.// | + | : //This EIP specifies a GraphQL schema for accessing data stored on an [[dido:public:ra:xapend:xapend.a_glossary:e:ethereum_node|Ethereum node]]. It aims to provide a complete replacement to the read-only information exposed via the present JSON-RPC [[dido:public:ra:xapend:xapend.a_glossary:i:interface|interface]], while improving on [[dido:public:ra:xapend:xapend.a_glossary:u:usability|usability]], consistency, efficiency, and future-proofing.// |
| === Motivation === | === Motivation === | ||
| Line 23: | Line 23: | ||
| : //For example, the ''totalDifficulty'' field is stored separately from the block header in common Ethereum node implementations, and many callers do not require this field. However, every call to ''eth_getBlock'' still retrieves this field, requiring a separate disk read, because the RPC server has no way of knowing if the user requires this field or not.// | : //For example, the ''totalDifficulty'' field is stored separately from the block header in common Ethereum node implementations, and many callers do not require this field. However, every call to ''eth_getBlock'' still retrieves this field, requiring a separate disk read, because the RPC server has no way of knowing if the user requires this field or not.// | ||
| - | : //Similarly, transaction receipts in go-ethereum are stored on disk as a single binary blob for each block. Fetching a receipt for a single transaction requires fetching and deserializing this blob, then finding the relevant entry and returning it; this is accomplished by the ''eth_getTransactionReceipt'' API call. A common task for API consumers is to fetch all the receipts in a block; as a result, node implementations end up fetching and deserializing the same data repeatedly, leading to ''O(n^2)'' effort to fetch all transaction receipts from a block instead of ''O(n)''.// | + | : //Similarly, transaction receipts in go-ethereum are stored on disk as a single binary blob for each block. Fetching a receipt for a single transaction requires fetching and deserializing this blob, then finding the relevant entry and returning it; this is accomplished by the ''eth_getTransactionReceipt'' [[dido:public:ra:xapend:xapend.a_glossary:a:api|API]] call. A common task for API consumers is to fetch all the receipts in a block; as a result, node implementations end up fetching and deserializing the same data repeatedly, leading to ''O(n^2)'' effort to fetch all transaction receipts from a block instead of ''O(n)''.// |
| : //Some of these issues could be fixed with changes to the existing JSON-RPC interface, at the cost of complicating the interface somewhat. Instead, we propose adopting a standard query language,// | : //Some of these issues could be fixed with changes to the existing JSON-RPC interface, at the cost of complicating the interface somewhat. Instead, we propose adopting a standard query language,// | ||