CCIP-read results potential for invalidation because fast block sync time on devnets (Goerli)

[FawadHa1der]

I wanted to start a discussion first before moving onto creating an issue. Input from the ethers team would be very appreciated.

Background:
We are working to enable CCIP-Read for Starknet. On goerli starknet state updates on L1 very fast, currently < 1 min between updates. With CCIPRead there are 2 calls made to a CCIP-enabled contract on L1 from ethers/client.

1. First gets the url for the gateway. the url will also contain the starknet block number that has been committed to on L1. This starknet block number and the stateroot changes very fast < 1 min as mentioned above. The gateway return proof against this starknet block number
2. and the second eth_call verifies the proof returned from the gateway.

Both are view only eth_calls. But in order for the proof validation to work both of these requests have to be for the same ethereum block number (hence the same starknet committed block number) on L1 because the gateway might return results for a block which is no longer current by the time a second eth_call is made to verify the proof. Current implementation seems to use 'Latest' blockTag and that could lead to invalidation of proof returned. We have experienced this with our internal tool(though yet to be confirmed with ether.js)

Question and/or proposed solution:
is there a way to persist the block number between these 2 requests so that we can consistently get the same information?