Log block timestamp

What is the problem

Within a log result in the JSONRPC spec it does not expose the block timestamp, which means it requires another block lookup per each log to get the block timestamp. This is not efficient and can cause a big bottleneck in indexing, slowing indexing down by 10-50x in some cases.

You can see the proposal to add block timestamps to logs here. Alongside reth has already supported this feature for a while now. That said most nodes at the moment are not reth meaning this bottleneck is still a problem.

How do we want to handle it

At the moment rindexer does not expose block timestamps with the logs when indexing. We want to add this feature but we are not willing to slow down the indexer by 10-50x to get this indexing in the traditional way. We are working on an approach which will allow block timestamps to be exposed in the logs without slowing down the indexer.

No block timestamp pain points

Time is an important factor to have but only really on viewing the data. If you just want to order the data or aggregate the data you just need to know which log came first which is already possible with the block number alongside the tx index and log index which is already exposed in the logs. Most programmatic use cases do not need the block timestamp.

That said we understand that some use cases do need the block timestamp, for example, if you are doing a time series analysis on the data you will need the block timestamp. We believe we can solve this problem in a much more efficient way than the traditional way.

Note this is still possible to fetch in rindexer rust projects by fetching the block within your custom handler itself. All network providers can be used within the custom handler to fetch any extra data you need. This means it will only slow down that specific event and not the whole indexer.