[Feature] Configuration flag to allow possible 'null' blocks on a network

Description

Filecoin blockchain has added an EVM runtime on top of its blockchain some months ago. From Filecoin docs web:

"The FVM contains an Ethereum Virtual Machine (EVM) runtime, allowing Ethereum and Solidity developers to run their contracts on the FVM with little to no modifications. This page details what exactly this EVM compatibility means, and any other information that Ethereum developers may need to build applications on the FVM."

Because of the Filecoin's miner election process nature, "null" blocks can happen. When the random miner election process occurs, sometimes no winer is chosen. In that scenario, no tipset (group of blocks) is generated. On the ethereum rpc side, this is reflected with an error message indicating the block is null. Please, refer to Ethereum RPC doc.

We are currently trying to use the ethereum rpc on the Filecoin network to connect a graph node so that subgraphs can be deployed. However, the moment a null block is found, the process gets stuck there. Some possible fixes has been explored, but none of them have been effective. In particular, a proxy has been established between the graph node and the filecoin node to produce fake blocks when a null one is found. This an entire valid block with no txs on it. However, the chain is actually broken, as block hashes are not correctly chained (it is impossible to do it in this proxy). For this reason, we see constantly reverted blocks while new blocks are ingested.

One possible workaround to this could be a new flag for specific chains which can allow to "skip" blocks when they are "null".

Some screenshots from our grafana dashboard

These are some of the logs we see on the node

Jun 29 13:56:14.343 INFO Scanning blocks [2991101, 2991101], range_size: 2000, sgd: 2, subgraph_id: QmebGEv1gdcQfGM5RkiDbx421Kw4JEPTMmUvN8wc6NU3XL, component: BlockStream
Jun 29 13:56:14.343 DEBG Requesting hashes for blocks [2991101, 2991101], sgd: 2, subgraph_id: QmebGEv1gdcQfGM5RkiDbx421Kw4JEPTMmUvN8wc6NU3XL, component: BlockStream
Jun 29 13:56:14.356 DEBG Requesting 0 block(s), sgd: 5, subgraph_id: QmQzU2mwuhMZvSXam1jPcWhBMpnyFBL7NudkmJkyduQ3F5, component: BlockStream
Jun 29 13:56:14.405 INFO Reverting block to get back to main chain, revert_to_ptr: #2991100 (6718cfaf170b5e8e1e67bec45f07d08768f36d2ee420a4e2d7d6acdcf615f8d0), subgraph_ptr: #2991101 (fcf0abfb1c450019f8305472c962a8ed445d4804d727ca5f5e4adfa6c4f52979), sgd: 5, subgraph_id: QmQzU2mwuhMZvSXam1jPcWhBMpnyFBL7NudkmJkyduQ3F5, component: SubgraphInstanceManager
Jun 29 13:56:14.746 DEBG Found 1 relevant block(s), sgd: 2, subgraph_id: QmebGEv1gdcQfGM5RkiDbx421Kw4JEPTMmUvN8wc6NU3XL, component: BlockStream
Jun 29 13:56:14.768 INFO Scanning blocks [2991101, 2991101], range_size: 2000, sgd: 5, subgraph_id: QmQzU2mwuhMZvSXam1jPcWhBMpnyFBL7NudkmJkyduQ3F5, component: BlockStream
Jun 29 13:56:14.770 DEBG Requesting logs for blocks [2991101, 2991101], contract 0x9be9b0cfa89ea800556c6efba67b455d336db1d0, 5 events, sgd: 5, subgraph_id: QmQzU2mwuhMZvSXam1jPcWhBMpnyFBL7NudkmJkyduQ3F5, component: BlockStream
Jun 29 13:56:14.835 INFO Reverting block to get back to main chain, revert_to_ptr: #2991100 (6718cfaf170b5e8e1e67bec45f07d08768f36d2ee420a4e2d7d6acdcf615f8d0), subgraph_ptr: #2991101 (fcf0abfb1c450019f8305472c962a8ed445d4804d727ca5f5e4adfa6c4f52979), sgd: 2, subgraph_id: QmebGEv1gdcQfGM5RkiDbx421Kw4JEPTMmUvN8wc6NU3XL, component: SubgraphInstanceManagerJu

Are you aware of any blockers that must be resolved before implementing this feature? If so, which? Link to any relevant GitHub issues.

No response

Some information to help us out

• Tick this box if you plan on implementing this feature yourself.
• I have searched the issue tracker to make sure this issue is not a duplicate.

ソースファイルやテストは指定されていません。まず、ログに示されている BlockStream の処理と、null blocks に対する Ethereum RPC パスを追跡し、その後、chain-specific configuration が取り込みにどのような影響を与えるかを判断してください。完了は、block-chain consistency を損なうことなく、Filecoin の null blocks によって graph-node のインデックス作成が停止しなくなることで実証されるべきです。