Quick blocks without quick slots

Quick blocks without quick slots

Here’s a half thought alternative to EIP 8198 that has quite some interesting advantages with minor tradeofs. Let’s get straight to the point. Slots remain 12 seconds. Proposer commits to a builder and a blockhash as in Gloas. The builder reveals 3 blocks, one each 4 seconds. Each block commits to the next block hash so blocks are still delayed 4 seconds as today, but transaction inclusion time reduces to a max of 4 seconds. PTC members vote with a bitlist for the timeliness of each of the payloads. The next proposer can reorg all payloads starting from the first one that there was a quorum that the payload was late/unavailable. The bad things: Builders can equivocate, make a mess of split views in forkchoice. Workable, if PTC does not reach quorum the next proposer will just reorg all payload equivocations. These equivocations can be made to not affect finality, they all occurr withing the already anchored block by the consensus layer. Builders have many consecutive blocks (3 in the scheme above) and could potentially do multiple slot MEV, but they are forced to reveal the payloads in time and are constrainged by the next hash commitment. The biggest drawback is that transaction inclusion does not get a beacon committee vote every block, not even a PTC vote every block, votes are only coming per slot. This forces latency bound traders to track for payload equivocations for example. So this is a weak preconfirmation but it’s visibly signed on chain. Traders that need the guarantee of a full beacon vote would need to wait a slot. The good things: Trivially implementable. Does not require any new machinery, we have everything in place and it’s just adding a couple of bits to the PTC attestations. The forkchoice guarantees are what we are moving anyway in new consensus with small committees for the fast vote, notice that anyway we retain the full beacon committee every slot to anchor the beacon chain. We get to immediately pump up transaction inclusion latency without affecting hardware, builders are already supposed to be beefier than attesters. We get to have 6 – 4 seconds blocks in a realistic frame. The most important one: We keep the useless part of the slot exactly as today. Today the consensus block propagation and attestation propagation (because builders will wait to reveal) is dead time in the slot. If we reduce the slot time this dead time per block becomes a higher fraction of the useful time in the slot. With this proposal the dead time remains the same, about 1/3 of the slot in Gloas time, while the chain throughput doubles or triples. We don’t need to pay with extra dead time and thus we can keep the same Gas limit per second that we can achieve in Gloas.

September 19, 2026 · Potuz
Faster blocks in Ethereum

Faster Blocks in Ethereum

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

September 1, 2026 · Potuz
Gloas circuit breaker

Gloas circuit breaker

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

July 28, 2026 · Potuz
Gloas honest reorgs

Honest reorgs in Gloas

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

April 30, 2026 · Potuz
Gloas range sync

Gloas Range Sync

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

April 13, 2026 · Potuz
The meaning of finalization

What is "Finalized" in Ethereum?

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

April 6, 2026 · Potuz
ePBS devnet 0

ePBS devnet 0: sequence of events

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

March 4, 2026 · Potuz
Annotated gloas forkchoice

Gloas Annotated: Forkchoice

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

January 30, 2026 · Potuz
Annotated gloas pubsub

Gloas Annotated: Gossip

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

January 29, 2026 · Potuz
Annotated gloas beacon-chain

Gloas Annotated: Beacon-Chain

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

January 27, 2026 · Potuz