eth_getLogs incomplete proof

[Termina1]

Support for eth_getLogs proof was added in #108, however it only proves inclusion of logs, that were returned from untrusted RPC. However, untrusted RPC can simply omit logs. In real world omitting a log can be omitting ERC20 transfer event, for example.

I don't think that it is a good idea to support partial proofs like that, because currently I don't think it is safe to use eth_getLogs via helios in untrusted environment.

[ncitron]

This is a good point but I still think it is worthwhile to have this method. We should probably add a mention of this somewhere in the readme. Might also be worthwhile to have a --strict flag that disables the logs methods for particularly risk-averse users.

I also wonder if there is a way to fetch logs in such a way that helios can guarantee a complete list?

[ryanschneider]

Naive thought: this would only work on reasonable block ranges, but if helios has the block headers for the complete range in question, then you could do at least confirm that the computed bloomfilter of all the returned logs doesn't match any additional blocks.

Basically, use the same code that geth uses to decide which blocks to examine when serving a eth_getLogs: https://github.com/ethereum/go-ethereum/blob/5a02b2d6d0a8d5c8ebf170505c681f7b19df7ed9/core/bloombits/matcher.go#L147

Once you have that list, compare with the blocks that the RPC provider returned logs for. If any additional blocks are found, for each additional block then you could download w/ proofs all the receipts for those blocks and confirm no expected logs were missing. This would of course be super slow so for large block ranges w/ lots of false positive hits on the bloom filter (which would probably happen quite often for popular queries like looking up token transfers on common ERC20 tokens).

[ncitron]

Yeah this would work, although for all the reasons you mention, I think it's probably not a good way forward.

[Termina1]

I think this API just have to be changed to be locally verifiable, however due to the fact that it operates on ranges, I don't think there is a way to make it efficient, unless you use ZK or something like that. May be if you could prove the total number of logs specific query should return, you could then prove everything the same way you do in helios now.