Original Title: "Ethereum All Core Developers Consensus Call #120 Writeup"

Original Author: Christine Kim

Translated by: AI Assistant

上一次会议 translates to "Previous meeting" in English.

On October 19th, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) Call #120 meeting. The ACDE conference call is a bi-weekly series of meetings hosted by Ethereum Foundation researcher Danny Ryan, where developers discuss and coordinate changes to the Ethereum consensus layer (CL). This week, developers focused on the progress of the following topics:

1. CL specification version 1.4.0-beta.3;

2. The startup conditions for Devnet-10;

3. Gajinder Singh analyzes blob latency. He is a software developer who maintains the Lodestar and EthereumJS clients.

召唤（The Summoning）

translates to

召唤（The Summoning）

in English.

Danny Ryan has announced the release of new CL code specifications for the Cancun/Deneb (Dencun) upgrade, called "Summoning". This version has been officially marked as version 1.4.0-beta.3 in the CL GitHub repository and includes two main changes:

1. Mainnet KZG Configuration: The formatting work required for the Ethereum Trusted Setup Ceremony output has been completed and included in the latest CL specification release.

2. New Gossip Rule: Teku developer Enrico Del Fante has created a new gossip rule to ensure that CL nodes do not propagate blobs exceeding the maximum blob count per block, which is currently defined as six in the specification. This will ensure that validators cannot use invalid messages exceeding six blobs per block to spam the network.

Devnet-10

The changes in version 1.4.0-beta.3 of the CL specification will be tested on the next development network, Devnet-10. However, there are still some obstacles to the launch of Devnet-10. Barnabas Busa, a DevOps engineer at the Ethereum Foundation, said he is still waiting for the client team to release a new software version. Once these preparations are ready, Busa hopes to launch the next development network on Tuesday, October 20th.

The developer of the Prysm client using the pseudonym "Potuz" pointed out that the latest CL specification includes the mainnet KZG configuration, which cannot be merged into Geth and Prysm until changes are made to "go-kzg". "go-kzg" is a separate code repository that implements the KZG commitment scheme in the Go programming language. Developers expressed disappointment in the dependency relationship between go-kzg, Geth, and Prysm repositories during a conference call. This is not the first time that Potuz and other developers have raised challenges about using the KZG library for EIP 4844.

Ethereum Foundation's DevOps engineer Parithosh Jayanthi said that developers can launch Devnet-10 without the mainnet KZG configuration and the release of a new client, but this means that developers will not test any new code on Devnet-10, but instead retest the released code on Devnet-9.

This week, developers discovered an issue in the CL client implementation on Devnet-9. Mario Vega from the Ethereum Foundation testing team explained that validators failed to properly handle invalid data blocks (blobs). Vega explained that if a validator maliciously broadcasts valid data blocks to some nodes and invalid data blocks to other nodes, nodes receiving the invalid data blocks will be unable to track the chain's head. To address this issue, a hive test has been created to easily replicate these conditions and test against new client releases. This will allow developers to immediately determine if their fix for this issue is effective.

Regarding this issue, Enrico Del Fante mentioned that in certain cases, the Teku client will not import a block if it contains one or more blobs that do not match the existing blob commitments in the block. Dankrad Feist, a researcher at the Ethereum Foundation, pointed out that validators who intentionally propose blocks with invalid blobs will not gain any economic benefits and may only increase the computational burden on the Ethereum peer-to-peer network, causing some validators and the network to fall out of sync. Feist emphasized that even if validators do so, the additional computational burden on the Ethereum peer-to-peer layer will be limited by the maximum number of blobs per block.

However, in order to prevent validators from taking this action, developers are discussing the possibility of adding a new reduction condition. The new reduction condition will attempt to monitor the inclusion of invalid blobs in the block to prevent validators from intentionally putting pressure on the peer-to-peer layer. However, due to the high research and analysis costs required to change Ethereum validator economics, Ryan suggested further discussion of this proposal under the background of the Prague/Electra upgrade after Dencun.

Ryan pointed out that developers can set appropriate behavior for this situation in Dencun's CL specification, even if the blob index does not match the block commitment, validators should still import the block. He believes that since validators have no economic incentive to propagate blocks containing invalid blobs in the way described by Del Fante, this irrational behavior may result in the maximum network burden being limited by the maximum number of blobs per block. Therefore, minor modifications to the CL specification should be sufficient to solve the problem in the short term, while developers can consider more persistent solutions for future upgrades, such as new reduction conditions.

Jayanthi and Ryan have confirmed again that Prysm client will not launch Devnet-10 until the developer sets up the mainnet KZG configuration and resolves the issue raised by Mario Vega on the client side. Ryan emphasized that the discussion on the new slashing conditions should only take place in the context of the Prague/Electra upgrade, not Dencun, and that changes to the CL specification for importing blocks containing invalid blobs should not be an obstacle to launching Devnet-10. Representatives from the Prysm and Lighthouse client teams have stated that they will release updates for their software on October 20th (tomorrow).

Block Delay Analysis

During a sharing session on October 14th (Saturday), Gajinder Singh, the maintainer of Ethereum clients Lodestar and EthereumJS, shared a new analysis on the relationship between the number of blobs propagated based on gossip and the delay in block import. Singh pointed out that in his experiments on Devnet-9, the more blobs validators received, the more obvious the delay in blocks became.

The following table summarizes Singh's findings. The first column lists the percentage of complete blocks reached, while the values in the table indicate the number of seconds required to import the blocks.

The relationship between block import delay (in seconds) and the number of blobs contained in the block. Image source: Gajinder Singh, Twitter

Singh stated on Twitter that although the delay caused by a single blob in each block can be negligible, any number higher than two will introduce significant delays. Dankrad Feist commented that Singh's analysis data is very different from his own experimental results of propagating large blocks on the Ethereum mainnet. Feist asserted that "it seems unlikely that these data are correct" and added that adding the delay of processing blobs to the block time is an inaccurate way to predict block propagation time on the mainnet, as blobs are processed in parallel with blocks. Singh's predictions about block propagation with blobs can be found in the link provided.

Singh stated on Twitter that while the delay caused by a single blob in each block can be negligible, any number above two will introduce significant delays. However, Dankrad Feist pointed out that Singh's analysis data differs greatly from his experimental results on the propagation of large blocks on the Ethereum mainnet. Feist asserted that "these data seem unlikely to be correct" and added that predicting block propagation time on the mainnet by adding the delay of processing blobs to block time is an inaccurate method, as blobs are processed in parallel with blocks. Singh's prediction on block propagation with blobs can be found here. Feist called Singh's analysis "too pessimistic".

Despite differences, both Feist and Ryan believe that Singh's analysis is indeed worth emulating by other client teams. Ryan encourages other CL teams to try to replicate Singh's experiment on Devnet-9 to see if they can obtain similar data and results. If there is new data on block delay after introducing blobs, Ryan suggests revisiting this issue at next week's ACDE conference call.

"Original article link"

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia