This is a research article co-authored by @mostlyblocks (former Head of Research at Chorus One) and @ThogardPvP (CEO of @0xFastLane).
This article provides an accessible first perspective on validator timing games on Monad. Practically speaking, validators may intentionally build and gossip their block as late as possible to capture additional value from the incrementally larger set of transactions accruing over slot time.
While timing games have been practiced for multiple years on Ethereum, Monad’s performance-first architecture introduces additional risk considerations. The article recaps timing games, outlines Monad’s architecture, including a recent overhaul of MonadBFT consensus, and describes how sophisticated validators may approach timing games on Monad.
We can loosely define a decentralized network as a set of geographically distributed nodes. More rigorously, we can approximate such a network by its (stake-weighted) network graph, which has a center from which the expected latency to the set of nodes is minimized. As not all nodes are equally close to this center, the network must allow appropriate latency leeway to allow distant nodes to participate - this is a design choice.
In practice, a fast blockchain can be built by co-locating all nodes, but such a structure comes with resiliency trade-offs (e.g. the datacenter shuts down). A more resilient, decentralized architecture like Monad must allow sufficient consensus time for a node that is e.g. located in New Zealand to participate.
Competitive validators may take advantage of this latency leeway to improve the expected value of their blocks by performing two successive actions. First, they minimize their latency to peers, and second, they artificially delay their block proposal. This is referred to as a “timing game”.
To understand why this is profitable, note that as the slot progresses, users keep sending transactions, and therefore, the proposer has a larger amount of transactions to select the final block from. A more nuanced reason is that as the slot progresses, traders have access to more information, and in the case of arbitrage between the chain and another venue (e.g. the most liquid CEX), the expected opportunity value increases as the square root of block time, over time.
Timing games exist on a risk reward curve - the longer the validator delays, the higher the risk of an unwanted timeout resulting in a zero- or negative- payoff. For this reason, an informed validator must quantify the payoff of each unit of delay versus the marginal risk it runs. In summary, a sophisticated approach to timing games hinges on a strong understanding of the network’s topology and transaction arrival dynamics (i.e. the block value over slot time).
Monad's consensus mechanism is an improved version of HotStuff called "MonadBFT." HotStuff is a leader-based Byzantine fault-tolerant consensus protocol designed for high throughput and low latency. We will first examine parallelization, before describing how blocks are gossiped to the network.
In MonadBFT, the leader for a slot executes the transactions of the preceding slot **while composing the list of transactions it will include in its block, which will then be executed by the upcoming leader. Intuitively speaking, this means that during its slot, a validator fulfills two tasks: it simulates and settles the transactions passed to it by the validator preceding it in an optimized manner (execution), and packs a block to pass to the validator succeeding it (consensus).
An implication is that any transaction with a state dependency does not yield an execution guarantee until settlement time, which takes place one slot after the transaction has been included. For a typical user, this will not usually be noticeable. For traders competing for limited opportunities, the main implication is a less informed priority gas auction, and if carrying inventory risk (e.g. arbitrageurs), an additional risk margin applied over the other leg(s) of the trade.
Once a validator has decided on its block*,* it sends it out alongside either a quorum certificate (QC), or a timeout certificate (TC) for the previous block. Specifically, a QC attests that the validator has built on the preceding block n, and that this block has been attested to as valid by 2/3 of the network (i.e. an aggregated signature). Conversely, a TC attests that the preceding validator has missed its slot and that the validator has built on the preceding block n-1; a valid TC must also be signed by 2/3 of the network.
The latest iteration of MonadBFT couples any timeout vote with a quorum vote for the most recent block a validator has attested to, which means that any validator which garners a supermajority of votes eventually finalizes. This stands in contrast to previous versions, where a successful timeout quorum would have resulted in a reorg of the validator that had preceded the timed out leader (”tail fork”).
Timing games on Monad are a race between the QC (validators vote on a block) and TC (validators vote on a timeout) paths. The QC path is faster, with linear overhead (one message per peer), while the TC path is slower, validators must multicast timeout votes and aggregate these into a TC (quadratic overhead).
"Linear overhead" refers to communication complexity that grows proportionally with network size - one leader sending a single message to each of N validators. "Quadratic overhead" occurs when each validator must communicate with many others, causing message volume to grow with the square of the network size as validators both send and receive messages from their peers.
A validator playing timing games must ensure its block reaches a supermajority of the network before a timeout vote does, and therefore, there is a strong incentive to optimize connectivity with the closest 2/3 of peers plus a risk margin for latency or timeouts. Put another way, validators in distant locations might timeout more frequently due to slower block receipt, issuing TCs even as QCs form elsewhere. The upshot is an increased incentive to centralize as timing games spread.
The extent to which a proposer may risk a timeout depends on the marginal value of any delay. This is an empirical question, as traders will time their transactions such that they are late but still run a high inclusion chance (i.e. model the network), whereas retail transaction arrival times can be thought of as unpredictable. An aspect that can be stated is that due to Monad’s shorter block times, the expected value of cross-venue arbitrage is significantly lower than on e.g. Ethereum.
A validator playing timing games benefits from capturing transactions that would have otherwise accrued to a later slot; if all validators play timing games, this results in a competitive outcome with an increased risk profile. Economic incentives are likely to encourage competitive validators to engage in timing games in any scenario, as a decentralized network must accommodate distant participants, and therefore, a delay margin is available for well-networked nodes.
Under previous version of the MonadBFT design, an elevated timeout risk reflected as an increased risk of reorgs. This would have reduced block value upfront, as traders holding inventory risk (e.g. arbitrageurs) adjust their risk margin over the compound risk of not executing due to pipelined consensus plus the reorg risk. In this context, a validator playing timing games on Monad would have reduced the value of the preceding proposer as well.
This is not the case anymore under the current iteration, as timeout votes now carry a quorum vote for the latest block a validator has attested to. This additional information must be gossiped around the network with quadratic overhead (i.e. the message gets larger, increasing arrival latency), and therefore, likely adds more room for timing games.
In summary, timing games on Monad are possible and will favor sophisticated validators. While profitable for this subset, they in expectation reduce the block value of the proposers succeeding them, via excess transaction capture. Timing games are geographically centralizing by reducing the network visibility of nodes in distant locations, which reflects in inaccurate timeout votes, and a loss of influence to high performing low-latency hubs.
