Currently, the provider only has important RPC functionality required for MetaMask. It would be great to have the Verifying Provider that is fully RPC compliant

Getting error "missing value for required argument 1" for methods eth_getTransactionCount, eth_getBalance, eth_getCode, eth_call and eth_estimateGas.

The default block parameter is usually skipped (and defaults to 'latest') even though it is not documented as optional.

After the latest hardfork, headerDataFromWeb3Response seems to build a wrong header structure.

All uses of header.hash() get compared wrongly as a result. All other security checks still seem to run fine though.

This is a somewhat high priority to fix given the nature. I have, in the mean time, disabled block hash verification.

(node:64331) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 hardforkChanged listeners added to [Common]. Use emitter.setMaxListeners() to increase limit

EthersJs has a big suite of libraries to interact with Ethereum. If we can extend the VerifiedProvider to implement the AbstractProvider interface provided by the EthersJs then we can use the VerifiedProvider with all the existing EthersJs toolchain.

Currently, the Verifying provider is booted up with just one provider. This provider can be malicious in such a case the current system simply throws an error and fails.

Allow for passing a set of RPC URLs ordered by the most trusted one first. Gracefully try other provider URLs sequentially

Currently, the Verifying Provider accepts the latest Blockhash and Blocknumber as a constructor param. But as the blockchain has new blocks, the provider should be updated to the latest BlockHash and BlockNumber

GitHub Markdown has some limitation and logo is not formated currectly

Add tests for verifying provider. For the initial version, it is sufficient to test the main cases

I am requesting to add support for eth_getLogs and potentially the other log related methods.

At minimum I would like a guide on how this should be implemented as a method in the VerifyingProvider class.

Thanks!

• Currently, the latest hardfork is hardcoded and blocks before that hardfork do not verify.
• It's possible to determine which hardfork is relevant to the block number in question and support old blocks too.