Error on finalized flag for /eth/v2/beacon/blocks/{block_id}

[ignaciofd]

Describe the bug

I run several nodes behind a node balancer. I query for the checkpoint and when I receive a new one I query /eth/v1/beacon/headers/{block_id} with the block_id = finalized_root from the checkpoint payload. Then, I query for all the slots between the previous finalized slot and the current finalized slot.

When I queried slot 8118490 (endpoint = /eth/v2/beacon/blocks/8118490) after having seen a new checkpoint (not necessarily from the node that I was quering), I received the payload for the block with the flag finalized: true which is not what I was expecting since the slot has been forked/uncled.

I was expecting either a 404 (block not found) or finalized: false.

Is this an expected behaviour?

Here is the payload that I received for slot 8118490 that shows the finalized flag = true.

Has this worked before in a previous version?

Not sure

🔬 Minimal Reproduction

Below are the prism flags and environment used for all of the nodes behind the node balancer.

[Service]

Environment=USE_PRYSM_MODERN=true
Environment=USE_PRYSM_VERSION=v4.0.8

ExecStart=/data/prysm/prysm.sh beacon-chain \
--slots-per-archive-point 2048 \
--execution-endpoint=http://localhost:8551/ \
--mainnet \
--jwt-secret=/path/to/jwt.hex \
--datadir /path/to/datadir \
--monitoring-host 0.0.0.0 \
--grpc-gateway-host 0.0.0.0 \
--grpc-gateway-corsdomain 127.0.0.1 \
--accept-terms-of-use \
--enable-debug-rpc-endpoints

Error

No response

Platform(s)

Linux (x86)

What version of Prysm are you running? (Which release)

4.0.8

Anything else relevant (validator index / public key)?

No response

[rkapka]

Hi @ignaciofd , I did some digging into our codebase and this behavior is expected if the block is from the last finalized epoch.

Note: beacon blocks from the latest finalized epoch return true, whether or not they are considered canonical in the "head view" of the beacon node.

After the next epoch finalizes, you should get a 404.

[ignaciofd]

Thank you very much for the reply. However, this does not seem to be good behaviour since the finalized field is not telling if a slot is final or not which I assumed was the intention of the field. Now I know that I should not take into account that flag and I need to reconstruct the chain to filter out the forks.

[rkapka]

Hi @ignaciofd , I am currently working on a solution for this because I agree it shouldn't work like this.

[ignaciofd]

Thank you @rkapka !