feat: fix GetBlock for null rounds by returning nil

[virajbhartiya]

Related Issues

fixes #10909

Proposed Changes

fix GetBlock for non-existent blocks by returning nil

Additional Info

https://github.com/ethereum/go-ethereum
https://docs.infura.io/api/networks/ethereum/json-rpc-methods/eth_getblockbynumber

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title conforms with contribution conventions
• Update CHANGELOG.md or signal that this change does not need it per contribution conventions
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[virajbhartiya]

@aarshkshah1992 Can you please give this a view

[rvagg]

Can you add something in itests for this?

[virajbhartiya]

I have reverted back to the original state, I'll make the changes in getTipsetByBlockNumber. Sorry for the weird commit history

[virajbhartiya]

Null rounds essentially gaps in the blockchain where no blocks are successfully mined for a particular epoch. These occur naturally in the protocol with a designed 0.7% probability due to the network's winner selection mechanism, though they can also happen if all Storage Providers who were selected as potential block miners for that epoch fail to produce or publish blocks. During a null round, while no blockchain data is created, the network's epoch clock continues to advance. This creates a gap in the chain's sequence. When a null round occurs, the next successful block will link back to the last valid tipset before the null round, effectively skipping over the empty epoch. This ensures network progression even when block production temporarily fails. And also null rounds differ from empty tipsets in that they don't exist in the chain state at all.

Null rounds -> when no block gets mined at a given epoch
Empty tipsets -> valid tipsets that contain no messages but have a CID and exist in the chain state

[aarshkshah1992]

@virajbhartiya Great ! One more question -> given an epoch -> how can determine if it's a null round or not in Lotus ?

[virajbhartiya]

That can be done by
Trying to retrieve a tipset for your target epoch, if no tipset exists for that epoch, it's likely a null round and even if you get a tipset back it needs to be verified its height matches the target epoch. If the returned tipset's height doesn't match your target, it's a null round

Since null rounds don't exist in the chain state, we need to look for gaps in the chain. These gaps can be found by failing to find a tipset at that epoch

[virajbhartiya]

To be able to return null values when a block is a null round

- func (a EthModule) EthGetBlockByNumber(ctx context.Context, blkParam string, fullTxInfo bool) (ethtypes.EthBlock, error)
+ func (a EthModule) EthGetBlockByNumber(ctx context.Context, blkParam string, fullTxInfo bool) (*ethtypes.EthBlock, error)

which will result in

- return newEthBlockFromFilecoinTipSet(ctx, ts, fullTxInfo, a.Chain, a.StateAPI)
+ return &block, nil

So the function of the definition of EthGetBlockByNumber will have to be changed everywhere. Is this okay or there's a better way of doing this?

[aarshkshah1992]

@virajbhartiya Yes, we need to change the function signature. Document this in the CHANGELOG when you write the change log for this.

[virajbhartiya]

I have updated EthGetBlockByNumber to return nil for a null round and also written itest for it and updated the ones using the function.

[aarshkshah1992]

@virajbhartiya Reviewed.

[aarshkshah1992]

lgtm

[aarshkshah1992]

@virajbhartiya Last set of comments.

[virajbhartiya]

@aarshkshah1992 I have made the changes suggested in you review and modified the tests.

[aarshkshah1992]

lgtm

[rvagg]

#12641

sorry, reverts aren't fun to have done to you