Ethereum gives a strong guarantee that no honest node will ever reorg a finalized checkpoint. Moreover, if two conflicting checkpoints are finalized, FFG (Ethereum’s finality gadget) implies that at least 1/3 of the total stake is slashable. That is the usual crypto-economic safety statement. This post is about a narrower question: when Ethereum says that a checkpoint is finalized, what state is actually protected by that guarantee? That question already has some subtlety today when the epoch-boundary block is missing. Gloas makes it more delicate, because beacon-block availability and payload availability can now diverge. In particular, EIP-7732 forces us to be precise about what a finalized checkpoint does and does not commit to. ...

At slot 281, Prysm cannot import a Teku built block. The message we get is [2026-03-04 15:28:11.08] DEBUG sync: Could not validate beacon block error=could not get pre state for slot 281: could not process block: could not process execution payload bid: bid consistency validation failed: bid parent block hash mismatch: got d1424c208f74aec1cd64c25f18745bc964b2f4bdbe075fe9c9d3d890d125973d, expected 03611a4c6839eb3dc9ca69c49a26b387e3a3a3a6ce951086620b55d723a5c6aa graffiti=teku-geth-1 GE57c3TK5704 proposerIndex=1826 slot=281 version=7 The bids corresponds to these blocks: In slot 223 we get ...

This is the third post on the series of annotating the Gloas fork. In this post we will go over the forkchoice changes. Some final details are still missing in forkchoice, particularly dealing with PTC dual deadlines and how to handle the data available boolean in the PTC attestations. Since there seem to be a global agreement on these remaining changes, I take the liberty of indicating them here, even though they may not be accurately what will end up in the final spec. These will be clearly marked in this document and they are anyway very minor modifications to the current specification. ...

This is the second post on the series annotating the Gloas fork. In this post we will go over validation of objects over gossip. These paths are typically not executable on the spec and leave more slack for clients to design their validation pipeline. For example, changing the order of validation can lead a client to ignore messages that other client would reject. The structure of this post is different than the beacon chain one. We will break the post in sections for each object. Special care will be taken with respect to DataColumnSidecar because this validation is very likely to change. ...

This is the first installment of an annotated Gloas spec. It’s aimed mostly for an audience of client implementers or spec researchers. Text will be terse and assumes deeper knowledge of the previous forks’ code. In this post we will go over some changes in the file beacon-chain.md. As requested by many in the Prysm team, we will restrict ourselves to describe the why of these changes rather than the how. We will simply omit any section that is self-descriptive. Text follows the order of the beacon-chain.md file, therefore some explanations have to be deferred until the corresponding helper functions and classes are declared. ...

This will be the story of another bug in Ethereum, this time an actual protocol bug and not a client’s one. I’ll interleave it with the history of how I got involved in Ethereum core protocol development as this bug is intimately intertwined with my interests in blockchain. The account of events told here is rather a reflection of how I remember them and not how they actually happened. My memory is not a shade of what it used to be a couple of decades ago. ...

This is a full explainer of the DOS experienced by Prysm nodes at the Capella and Fusaka forks. Checkpoints and Attestations Before going into the bug details, let’s get a refresher on the technical aspects of attestation validation on Ethereum. Ethereum has Epochs, consisting of 32 Slots, where blocks are proposed. When a validator, during its assigned slot attests to a block, it also attests to a target checkpoint. This target checkpoint is explicitly sent in the attestation for bookkeeping and accountability reasons, but can be completely derived from the attestation’s slot and block roots. The associated checkpoint is easier to visualize than to define, so let’s draw some cases first before jumping into formal definitions. ...