invalid handling of `parentHash` for skipped blocks during block indexing.

[0x3bfc]

Near blocks might produces some empty blocks which are skipped by the indexer. However there is no check whether skipped parent block hashes (the computed parentHash which is the parent of a block previously fetched from the chain) are empty or not.

It requires an extra check in the following line: https://github.com/aurora-is-near/aurora-relayer/blob/f477c1ff728e24c369a42284b9c25eb015e2e910/src/indexer.ts#L101

[0x3bfc]

Comment by @artob

The actual problem is that skip blocks don’t exist, at all, in NEAR: they take up a block number, but they don’t even have a (NEAR) block hash, and you can’t ask for any information about them from the NEAR RPC. So, any operation about them is going to fail. So what is actually needed is to improve our indexer to correctly handle skip blocks, by catching that error (block doesn’t exist, says NEAR RPC) to index the block as an empty block. Thus translating NEAR skip blocks into EVM empty blocks.

[mfornet]

What is the plan ahead for this issue? Are you using the same hash for all this block, or some custom hash per block like sha256(block_height + more_data)?

in any case, I'd also add a new field that contains the Near Definition of parentHash (i.e. without skip-blocks), maybe this can be exposed in a similar method but with different name to avoid apps to be broken because of this.

[0x3bfc]

@mfornet

What is the plan ahead for this issue?

Yep, please check out the #128

Are you using the same hash for all this block, or some custom hash per block like sha256(block_height + more_data)

The block hash is deterministic it relies on the hash of (block height + chainID + Aurora EVM contract ID)

in any case, I'd also add a new field that contains the Near Definition of parentHash (i.e. without skip-blocks), maybe this can be exposed in a similar method but with different name to avoid apps to be broken because of this.

Not sure what do you mean by this new field for parent hash?