Use RPC batch requests where possible

[Brechtpd]

From limited testing approximately halves the number of RPC requests that need waiting on. The get_proof requests are very very quick now because can be fully batched. So with a remote node, approximately speeds up input gathering by 50%.

Currently have to import the same reqwest because of some type difficulties, can be removed when we can switch to the same latest reqwest after the proverd PR is merged.

[johntaiko]

@Brechtpd @smtmfft Changed the customize batch history headers API to ether's batch API.

[smtmfft]

Changed the customize batch history headers API to ether's batch API.

Make sure the headers are in same order as before, so that we won't meet that wrong sequence issue again.

[johntaiko]

Changed the customize batch history headers API to ether's batch API.

Make sure the headers are in same order as before, so that we won't meet that wrong sequence issue again.

https://github.com/taikoxyz/taiko-geth/blob/2eac3d10ea69a3946a6d1c3f407834a5a1d0564e/eth/taiko_api_backend.go#L65

Yes, I follow the geth's version. But, we don't care about the order in raiko's usage. We just store them in a HashMap.

[johntaiko]

let block = get_block(&provider, block_number, true).unwrap();
let parent_block = get_block(&provider, block_number - 1, false).unwrap();
...

The rpc in prefilght also could be batched in one request

[Brechtpd]

let block = get_block(&provider, block_number, true).unwrap();
let parent_block = get_block(&provider, block_number - 1, false).unwrap();
...

The rpc in prefilght also could be batched in one request

Yeah you're right, though only 2 RPC to 1 RPC so not sure if it's really worth it.

[Brechtpd]

Some more batching in https://github.com/taikoxyz/raiko/pull/112 so we can really batch request everything, but that still needs a bit of work (not too much though). If no more open issues with this PR I think we can already merge this one.

[smtmfft]

Some more batching in #112 so we can really batch request everything, but that still needs a bit of work (not too much though). If no more open issues with this PR I think we can already merge this one.

I believe it's good enough, and further batch optimization need kind of save & replay which I think is somehow related to parallel execution analysis, as there are some runtime dynamic ones. Maybe not need to be done now.