eth_getLogs RPC is unreliable in light mode

[jimpo]

I'm running:

• Which Parity version?: 2.0.0
• Which operating system?: Linux
• How installed?: from source
• Are you fully synchronized?: yes
• Which network are you connected to?: ethereum
• Did you try to restart the node?: yes

The eth_getLogs RPC only works for recent blocks in light mode. Specifically, it only works if logs are created on blocks where the headers are stored. If the headers are pruned, the client does not fetch them from the network on-demand to scan for logs.

I noticed this when using Augur and opened an issue there. This gist provides a test case.

While it could be too expensive to support eth_getLogs on a large range of headers, I think it makes sense for the light client to fetch small ranges of headers on demand from the network and scan them for matching logs.

Furthermore, the log entries responses are incomplete since BlockReceipts responds with a Receipt instead of a RichReceipt. RichReceipt includes the transaction hash, index, cumulative gas, etc., which are expected in the RPC response. Fixing this would require a modification to the PIP protocol, I assume.

[xenoexclusive]

Am I incorrect in believing EIP234 would relate to this in any way?

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-234.md

[jimpo]

@xenoexclusive It is related but doesn't solve the issue. Firstly, it's just an additional option, though it would likely be easier to handle the blockHash case than fromBlock + toBlock.