Original Title: "On Attestations, Block Propagation, and Timing Games"
Author: Nero_eth
Translation: Tia, Techub News
Nowadays, proposer's timing games have become quite common, and many studies have analyzed this phenomenon.
This article will take you through the evolution of proposer's timing games and analyze their impact on attesters. Through case studies of Lido, Coinbase, and Kiln node operators, we will delve into the timing games of block proposals and their impact on Ethereum consensus.
As of August 2024, the block construction market is largely outsourced, with about 90% of the blocks being constructed by mevboost block builders. Among them, Titan Builder and Beaverbuild constructed approximately 80% of the blocks.
Kiln is one of the main entities driving the timing games, delaying block proposals by 3-3.5 seconds within a single slot.
In the current mevboost environment, block propagation is mainly done through relayers. While proposers still propagate the block after receiving it from the relayers, the relayers usually have better network connections, allowing for faster propagation. However, timing is still controlled by the proposers, who can delay their "getHeader" call to engage in timing games.
This chart shows the evolution of timing games. We can see that over time, the blocks proposed by Kiln validators are relatively delayed within the slot.
This will have an impact on the network: blocks proposed by Kiln proposers have a significantly higher rate of missed/incorrect block header votes.
Previous analysis shows that the longer the wait time, the higher the expected number of missed block header votes ("80% of attestations occur in the 5th second of the slot"). Kiln's late block proposals result in some attesters missing them and instead voting for the parent block. Approximately 32,000 validators are assigned per slot, leading to about a 10% error rate in block header votes.
Let's take a look at the attestation behavior of three major node operators and compare how they react to blocks proposed at different times. The following graph shows the distribution of timely and correct block header votes in seconds within the slot.
For early blocks, we observe that Lido and Coinbase exhibit a unique "U" shaped voting pattern, which may be due to different geographical locations or client software. In contrast, Kiln shows a distinct peak, slightly lagging behind the first peak of Coinbase and Lido. However, for later blocks, Kiln's attesters also exhibit a "U" shaped pattern.
When the block first appears in the slot at the 4th second (due to the P2P network, each node receives the block at different times), Lido's attesters attest up to 2 seconds earlier than Kiln's or Coinbase's attesters. This pattern does not necessarily indicate Kiln's execution of "individual strategies." Instead, it may be attributed to different clients or geographical locations.
Who is influencing whom?
In the following graph, we compare the performance of node operators under different proposers. For example, the green portion above y=1 indicates that when Kiln proposes a block as the proposer, Lido's attesters are more likely to miss block header votes. However, when Lido is the proposer, Lido's attesters are the most timely in attesting. Dashed line 1 represents the average share of missed block header votes when all entities act as proposers. Histograms below 1 indicate that specific entities miss fewer block header votes compared to the average when acting as proposers alongside their respective proposers.
It is worth noting that node operators perform best when handling blocks they propose themselves.
In summary, we observe:
When other operators act as proposers, most operators' performance is relatively stable.
When Kiln acts as the proposer, Figment, Lido, Kraken, and EtherFi perform poorly.
When Kiln acts as the proposer, only Kiln and Binance perform better.
Kiln performs well as an attester. Early analysis indicates that Kiln excels when it comes to high-performance attesters. For more detailed information on Kiln's attestation performance, please refer to this analysis.
However, Kiln is causing pressure. We now know that blocks proposed by Kiln put pressure on other attesters but not on Kiln's own attesters.
It is currently difficult to explain the "How." One possible explanation is that Kiln's validators are highly concentrated, co-located, or have very dense peer connections. Another reason could be coordinated behavior through custom peer networks/private networks or additional communication layers connecting their validators. The latter is considered more centralized as it emphasizes economies of scale.
When we observe Lido and Coinbase's (timely and correct) attestation times when they act as proposers for their own blocks, we can observe similar patterns.
Interestingly, Kiln has developed a "U" shaped distribution from 3.8 seconds to 6.1 seconds for their own late blocks, while Lido exhibits a peak at 4.2 seconds, and Coinbase starts with a plateau in the 4th second and a small peak at the 6th second within the slot.
Preventing one's own proposed blocks from being reorganized
Let's shift our focus to reorganized blocks. From the perspective of node operators, one strategy may be to never vote for their own blocks to be reorganized. In simple terms, "if I am the proposer, never vote the parent block as the block header."
In the following section, I will use "local blocks" to represent "blocks proposed by oneself."
The following graph shows the percentage of attesters voting for reorganized blocks versus voting for parent blocks. The red portion indicates the percentage of attesters of that entity voting for reorganized blocks.
Kiln has exhibited anomalous behavior. While most node operators' attesters honestly vote for the correct block headers rather than local blocks, Kiln's attesters do not. Over 10% of Kiln's attesters attempt to keep their local blocks on the chain by voting for them. By employing such a strategy, they may incur losses due to voting for incorrect block headers. However, these strategies are generally frowned upon in the Ethereum community: "Don't play with consensus."
The chart uses data from 365 days. Therefore, if some complex strategies have been implemented in the past year, the proportion of the red portion would correspondingly be smaller.
But how do we view collaboration on other levels?
Regarding attestation collaboration, as a community, we seem to accept the fact that validators running on the same node vote for the same checkpoints.
We may not want to make efforts to enhance collaboration between validators that span physical machine boundaries. This should be something that everyone can build. This collaboration may take different forms:
Level 1 - Fall-back Mechanism and Static Peer Connections: Providing a central standby/backup node for multiple physical machines. This could also be a circuit breaker, some specially fault-tolerant machine, acting as a private relayer of information. Configurations with improved peer connections, private networks, or similar setups may also fall into this category.
Level 2 - If-Else Rules: Hard-coded rules to wait longer in certain slots. Those would be installed on multiple physical machines, allowing them to "collaborate" based on predefined rules.
Level 3 - Zombie Network: A centralized oracle communicating with all validators and providing voting checkpoints and timestamps for when they should be published.
In my view, the latter two forms of collaboration (Levels 2 and 3) are problematic, and node operators should take responsibility. Lastly, there may be a gray area for strategies involving static peer connections and private networks.
Such setups could be used to run (malicious) strategies such as:
Ensuring that validators across multiple physical machines never vote for different checkpoints.
Ensuring never to vote for reorganized blocks proposed by oneself.
Collaborating based on consecutive proposers (honest reorg client (y/n)).
Reviewing a certain party's attestations.
Not voting for a certain party's blocks.
Others.
When discussing collaboration, it is important to distinguish between two types:
Collaboration occurring between validators running on the same physical machine.
Collaboration stemming from running the same modified client software or relying on the same centralized oracle.
A potential solution to counter complex collaborative validator behavior is EIP-7716: Anti-Correlation Penalties, which proposes adjusting penalties based on the correlation between validators.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
