Posts

It is that time of the year in which I post about my personal interests, or rather wish lists, for Ethereum. I have already tried this topic before and will touch on that below, but before we get into the weeds of technicalities (actually I promised this post will be very short and to the point so there won’t be many) let’s get right to what this post is about: The time Ethereum messages spend on the wire is wasted time. We therefore want to spend the least amount of time broadcasting messages. The time we gain from communicating faster can be used in other ways: ...

The node keeps a list of whitelisted and blacklisted builders, they serve different purposes. Blacklisted builders will have their bids rejected and may not be contacted by direct connections if they are known. Whitelisted builders on the other hand are builders that will receive preferential treatment even in the event of a global circuit breaker triggering. In gloas there are three types of builders, those over P2P that can be largely anonymous, and those being reached by direct connections that can be trusted or not. It is unclear if there will be untrusted direct connection builders on the market, but we should prepare our circuit breaker as if they existed. Untrusted builders can deploy multiple keys, rotate them, try to attack the payload market, etc. Trusted builders can do so as well, but they are well established institutions with market to lose. So in some circuit breaker scenarios, it is actually convenient to fall back to trusted builders rather than falling back to self-building immediately. There are very little scenarios in which falling back to p2p bids is preferable. ...

This note is to clarify the nuances of new types of reorgs that can happen after the Gloas fork. The reason for this note is some confusion that seems to have been caused by the need to creating a new Engine API intrepretation. Honest reorgs pre Fulu Consensus nodes sync beacon blocks in a two step communication process with the execution engine. When they receive the beacon block, it contains the execution payload, the CL passes it to the EL via a call to the notify_newPayload engine API call. After the payload has been validated, the CL informs the EL that this payload is the new head via a call to the notify_ForkchoiceUpdated engine API call. All in all, the beacon block arrives around 2 seconds into the slot, and shortly after the engine has updated the head and users requesting information about the status of the Ethereum network get this information rather quickly. For all users, this process happens almost immediately after the beacon block arrives, no matter if the beacon block is early or late during the slot. ...

Potuz’s node was chugging along pretty happily following the chain. It unfortunately suffered a power loss and was unavailable for 5 days. He was so unlucky that during the 4th day, the chain stopped finalizing. So Potuz’s node has just restarted and finds itself leaking for the last 5 days, and being increasingly penalized since the last day of non-finality. His node starts requesting blocks by range. His last synced block was in slot S, the finalized checkpoint slot was F (4 days after S) and about one day from the current slot C. So Potuz’s node requests all blocks from S until C. Most nodes break this process in two logically (although not necessarily implementation-wise) different processes, the finalized range S -> F and the unfinalized section F -> C. This post will focus on the finalized section. ...

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. ...