Implement eth_getTransactionByHash

[lithp]

From #26, eth_getTransactionByHash is not implemented.

[voith]

This is fairly simple to implement using graphql. I have added a test here:

trinity/tests/core/graphql-rpc/test_grqphql.py

Lines 418 to 446 in 6b6d224

	pytest.param(
	build_request("""
	{
	transaction(hash: "0x747acd83b82d5fc65743568331c1f1dc0d540a59576838d7ac9adb893c84cc94") {
	from {
	address
	},
	to {
	address
	},
	value
	}
	}
	"""),
	{
	'errors': None,
	'result': {
	'transaction': {
	'from': {
	'address': '0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b'
	},
	'to': {
	'address': '0x0000000000000000000000000000000000001010'
	},
	'value': '0x1'
	}
	}
	},
	id='eth_getTransactionReceipt'

I haven't exposed all fields, but just writing all the attribute names in the query will fetch the needed attributes.
Maybe this is off topic as this needs to be implemented in JSON-RPC, but I'm just excited to share my progress : )

---

EDIT:
looks like I have more work to do as I need to test this with all possible chains.

[pipermerriam]

Some thoughts...

Initial implementation should be dead simple. If we have the transaction we return it.

The later work is to figure out what we can do when we don't know about the hash yet. If we want to be a full client in 5 minutes we need a solution for getting them on demand. Ideas for how we might do that?

1. Swarm via the BZZETH protocol. They're already doing it for block headers. Why not transactions and receipts too.
2. Expose convenience API via another sub protocol that only trinity speaks (until other clients adopt it).

[lithp]

As a note, Jason and I talked about this and had the idea that GetNodeData might just work, if transactions were stored in the database by hash it's possible that Geth or Parity don't check that they're returning a node before they return it. Don't know about Parity but I just skimmed the Geth code and transactions aren't stored by hash, the entire block body is stored as one chunk, so GetNodeData won't work.

[lithp]

The later work is to figure out what we can do when we don't know about the hash yet.

This RPC is less critical than the RPCs which involved state, I think I remember that syncing the chain + bodies only takes a few hours? But if we want to make the UX even better yeah, I don't see a way beyond what you've described here, somehow asking remote peers for these transactions.

As an ugly kludge, each day we could generate a bunch of shards and upload them to s3 for clients to download-on-demand, then clients would be able to answer getTransactionByHash queries as soon as they've synced the last day's worth of blocks.

[cburgdorf]

This has now landed as part of #1329. It doesn't do any clever beam sync related things to deal with the case were we try to act as a full node when in reality we haven't synced any historical data yet. But I don't think this is what the ticket is about so I'm closing this for now.