Missing RPC methods

[ncitron]

Missing RPC methods that might be useful to have.

Feel free to reach out here or on the telegram if you want to discuss how to go about implementing any of these.

• [x] eth_sync
• [x] eth_coinbase
• [ ] eth_feeHistory
• [x] eth_newFilter
• [x] eth_newBlockFilter
• [x] eth_newPendingTransactionFilter
• [x] eth_uninstallFilter
• [x] eth_getFilterChanges
• [ ] eth_getFilterLogs
• [x] eth_getTransactionByBlockHashAndIndex
• [ ] debug_getRawHeader
• [ ] debug_getRawBlock
• [ ] debug_getRawTransaction
• [ ] debug_getRawReceipts
• [ ] debug_getBadBlocks

[sk1122]

I am trying to add eth_newFilter, but facing a issue

• If we have enable eth_newFilter, we need to be able to verify the filter id that we receive, to verify that filter id, we will need to integrate eth_getFilterChanges as that will tell us if a filter is valid or not, so should i implement fully that first or just add functions in http_rpc.rs and subsequent files and not expose it for use?
• also what if the rpc says that filter is not valid, but actually the filter is valid, meaning that rpc is a bad actor, how can we mitigate that?

[sk1122]

@ncitron what do you think?

[ncitron]

That's a good point @sk1122. Is it possible to check filter validity ourselves?

I don't think it's a huge deal anyway though, as for the log methods we sort of assume that it is possible for the rpc to withhold logs from us.

[sk1122]

That's a good point @sk1122. Is it possible to check filter validity ourselves?

No, as they are generated randomly, there is no way to verify them based on filter data

I don't think it's a huge deal anyway though, as for the log methods we sort of assume that it is possible for the rpc to withhold logs from us.

Understood, I think we should check it once before handing filter id over to user, what do you think?

Also in future, we can implement DA proofs and Fraud proofs to better secure us against these type of errors?

[ncitron]

Understood, I think we should check it once before handing filter id over to user, what do you think?

How would we check it before handing the id to the user?

[sk1122]

we can check if eth_getFilterChanges returns an error, if it returns an error meaning that id wasn't registered on nodes (execution node can withheld that data though), else means that id has been successfully registered and now can be used for tracking changes

[sk1122]

but for this, we will need to implement eth_getFilterChanges, which returns list of logs if Id is valid, we can just use eth_getLogs verification code for verifying this logs

[sk1122]

so, should I first open a PR for eth_getFilterChanges?

[ncitron]

@sk1122 that would be great!

[muang0]

@ncitron I'm interested in contributing one of these methods, any preference which one I should do? Or is there another issue you think would be better suited for a 2nd contrib?

[ncitron]

Hey @muang0! A lot of the important ones here have been completed, but if you want to chat about some other contributions we can discuss on Telegram. I'm @ ncitron there.