Logs subscription errors out when "FromBlock" is present

[simsonraj]

Description

Expected:
WS logs subscription should accept the same params as HTTP that works
Current:
Errors out with
"error": {
"code": -32602,
"name": "Invalid parameter",
"message": "Invalid parameter 'fromBlock' for EthSubscribeLogsParamsObject: Unknown parameter"
},

Steps to reproduce

WSS request:
{ "jsonrpc": "2.0", "id": 1, "method": "eth_subscribe", "params": [ "logs", { "address": "0x0ed544cdac078ba3bc354b2458c04e358e758c9a", "fromBlock": "0x1E" } ] }

HTTP request:
{ "jsonrpc":"2.0", "method":"eth_getLogs", "params":[{ "address":"0x0ed544cdaC078ba3bC354b2458C04E358E758C9a", "fromBlock":"0x1E" }], "id":12 }

Additional context

No response

Hedera network

testnet

Version

0.47.0-rc3

Operating system

None

[quiet-node]

Hello @simsonraj thanks for opening the ticket!
I did some research and it looks like standard log subscriptions only have params={address, topics} (like our current setup) but not the whole kit like in eth_getLogs.

Below is the logs subscriptions params by some well-known services:

• Alchamy logs sub params
• Infura logs sub params
• Chainnode logs sub params
• Metamask logs sub params

Essentially, eth_subscribe is designed for real-time monitoring of new logs as they are added to the network, while eth_getLogs is used to retrieve historical logs from a specified block range. address and topics filters are sufficient for real-time monitoring for typically retrieving logs from specific contracts and topics. Other filters like fromBlock, toBlock, blockHash would only make sense for retrieving historical logs, i.e. logs that already occurred and added to the network in the past. So to sum up, the difference in filter params between logs subscription and eth_getLogs are intentional and based on their different use cases.

While this is indeed a good feature request, but sort of goes against the grain of how other services follow the industry standard patern for logs subscription params. Feel free to give me more context and explain why you think this is necessary. We will review your suggestion and see how it might fit into our future roadmap.

[AlfredoG87]

@quiet-node @simsonraj

in any case, I believe we should close this ticket, and in case that we wish to consider the feature request, another ticket should be created with the appropriate template and labels, as a feature enhancement.

[simsonraj]

Hey @quiet-node , thanks for the response. you probably are right. The reason why I missed that is because I don't think the other endpoints throw an error, I believe they simply ignore the param, is that doable?

[quiet-node]

Ah I see you're right looks like other services ignore the invalid params. Yes it's doable, and I will create a new ticket to address that and replace this ticket with that. Thanks for pointing it out!

[quiet-node]

Replaced by #2520