Original title: Ethereum All Core Developers Consensus Call#120Writeup

Original author: Christine Kim

Original translation: Lucy, BlockBeats

Last meeting

On October 19, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) Call #120. The ACDE 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 progress on the following topics:

1. Version 1.4.0-beta.3 of the CL specification;

2. Devnet-10 startup conditions;

3. Analysis of blob latency by Gajinder Singh, a software developer who maintains Lodestar and EthereumJS clients.

The Summoning

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

1. Mainnet KZG config: Completed the required formatting work for Ethereum trusted setup ceremony output and included it in the latest CL spec release.

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

Devnet-10

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

Developers of the Prysm client, who use the pseudonym "Potuz," noted that the mainnet KZG configuration included in the latest CL spec could not be merged into Geth and Prysm before changes were made to "go-kzg," a separate code repository that implements the KZG commitment scheme into the Go programming language. Developers expressed frustration on the call about the dependencies between the go-kzg, Geth, and Prysm repositories. This is not the first time Potuz and other developers have raised challenges regarding the use of the KZG library for EIP 4844.

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

This week at Devnet-9, developers discovered an issue in the CL client implementation. Mario Vega from the Ethereum Foundation testing team explained that the validator failed to properly handle invalid blocks of data (blobs). Vega said that if the validator maliciously broadcasts valid blocks to some nodes and invalid blocks to other nodes, the nodes that receive the invalid blocks will not be able to track the head of the chain. 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 understand whether their fix for the issue is effective.

Regarding this issue, Enrico Del Fante mentioned that when a block contains one or more blobs with indices that do not match the existing blob commitments in the block, in certain cases, the Teku client will not import this block. Dankrad Feist, a researcher at the Ethereum Foundation, pointed out that validators who deliberately propose blocks containing invalid blobs have no other benefits except that they may increase the computational burden of the Ethereum peer-to-peer network and cause some validators who receive the block to lose synchronization with the network. Feist emphasized that there is no economic benefit from such behavior, and even if validators do so, the additional computational burden of the Ethereum peer-to-peer layer will be limited by the maximum number of blobs per block.

Nonetheless, to discourage validators from engaging in such behavior, developers are discussing the possibility of adding a new slashing condition. The new slashing condition would attempt to monitor the inclusion of invalid blobs in blocks to discourage validators from intentionally putting pressure on the peer-to-peer layer. However, due to the high cost of research and analysis required to change Ethereum validator economics, Ryan suggested further discussing this proposal in the context of Prague/Electra, the next upgrade after Dencun.

Ryan added that developers can set appropriate behavior for this situation in Dencun's CL spec, where validators should import blocks even if the blob index does not match the block commitment. He believes that since validators have no economic incentive to propagate blocks with invalid blobs in the way Del Fante describes, the network burden that this irrational behavior could cause is most limited by the maximum number of blobs per block. Therefore, minor changes to the CL spec should be enough to solve the problem in the short term, while developers can consider more permanent solutions for future upgrades, such as new slashing conditions.

Jayanthi reconfirmed with Ryan that at least Devnet-10 will not be launched on the Prysm client until developers set up the mainnet KZG configuration on the client and resolve the issues raised by Mario Vega. Ryan emphasized that the discussion about the new slashing conditions was only in the context of the Prague/Electra upgrade, not Dencun, and that changes to the CL spec regarding importing blocks containing invalid blobs should not be an obstacle to launching Devnet-10. Representatives of the Prysm and Lighthouse client teams said they will release updates for their software on October 20 (tomorrow).

Block Delay Analysis

In a talk on Saturday, October 14, Gajinder Singh, maintainer of Ethereum clients Lodestar and EthereumJS, shared new analysis on the relationship between the number of blobs propagated based on gossip and block import latency. Singh noted that in his experiments on Devnet-9, the greater the number of blobs received by validators, the more noticeable the increase in block latency.

The following table summarizes Singh’s findings. The first column lists the percentage of complete blocks that arrived, while the values ​​in the table represent the number of seconds it took to import the block.

Block import latency (in seconds) versus the number of blobs included in a block. Image credit: Gajinder Singh, Twitter

Singh tweeted that while having only one blob per block would create negligible latency, any number higher than two would introduce significant latency. Dankrad Feist said that the data from Singh’s analysis is very different from the results of his experiments on propagating large blocks on the Ethereum mainnet. "It looks like there's no way this data is correct," Feist asserted, adding that since blobs are processed in parallel with blocks, adding blob processing delays to block times is an inaccurate way to predict Mainnet block propagation time. Singh’s predictions about block propagation with blobs can be found at

Singh said on Twitter that while having only one blob per block would create negligible latency, any number higher than two would introduce significant latency. However, Dankrad Feist pointed out that Singh’s analysis data is significantly different from the results of his experiments on propagating large blocks on the Ethereum mainnet. “There’s no way this data looks correct,” Feist asserted, adding that since blobs are processed in parallel with blocks, adding the latency of blob processing to block times to predict mainnet block propagation times is a problem. an inaccurate way. Singh’s predictions about block propagation with blobs can be found here. Feist called Singh's analysis "overly pessimistic."

Despite their disagreement, Feist and Ryan both agreed that Singh's analysis is indeed worth learning from for other client teams. Ryan encouraged other CL teams to try to reproduce Singh's experiments on Devnet-9 to see if they can get similar data and results. If there is new data on block latency after the introduction of blobs, Ryan suggested revisiting this topic at the ACDE call next week.

「Original link」