In the latest Ethereum All Core Developers Consensus (ACDC) call #124 held on December 14, 2023, Ethereum developers convened virtually to discuss important updates and developments in the Ethereum ecosystem. The meeting serves as a pivotal platform for developers to coordinate and implement changes to the consensus layer (CL) of Ethereum.
In the meeting, Barnabas Busa, a DevOps Engineer at the Ethereum Foundation, explained the progress made on Devnet #12 throughout the year, noting that all execution layer (EL) and consensus layer (CL) client combinations, including those utilizing Prysm as the CL client, have been successfully onboarded to Devnet #12. He also revealed that MEV-Boost software has been enabled for most client combinations, excluding those with Prysm.
Further into the discussion, Parithosh Jayanthi, another DevOps Engineer at the Foundation, reported an issue with a Besu node on Devnet #12. The team is actively investigating the root cause of this issue. Looking ahead, developers plan to stress test client combinations on the devnet, including intentional testing of bad blocks, and block builders, and running hive tests for the newly added Prysm client.
Besu is a Java-based Ethereum client that can be used to create private blockchain networks. It can be configured to perform as a full node that syncs to the blockchain or as an archive node that contains the data of the blockchain.
It is a permissioned network that allows only specific nodes and accounts to participate. To run a Besu node, one needs to meet the hardware and software requirements, which differ based on the type of network one is willing to sync to.
While the Ethereum community anticipates the shadow forking of the Goerli testnet before the end of the year, the developers engaged in a thorough discussion on slashable message propagation post-Cancun/Deneb upgrade.
One of the attendees known as “Dapplion,” contributed a pull request on GitHub to enhance the Beacon Chain API. This enhancement allows node operators to receive prompt notifications about slashable events, particularly valuable in scenarios involving high volumes of slashable messages.
Dapplion also addressed challenges related to measuring block propagation times in light of the Cancun/Deneb upgrade. Proposed solutions, detailed in a GitHub pull request, involve extending existing Beacon Chain API events with a timestamp field.
Towards the end, they also talked about gossip conditions for blobs and the concerns over unexpected consequences within the existing rules. Although not an immediate threat to the network’s health, developers recognized the importance of revisiting and clarifying rules for slashable message propagation in future updates.
Additionally, there was a conversation about a minor change to the libp2p networking protocol to mitigate the amplification of large messages. This adjustment aims to lessen the impact of substantial messages, like blocks with numerous blobs, on nodes. The proposal involves introducing an “IDONTWANT” control message to notify libp2p peers to temporarily halt sending large messages.
