Click to expand detailed summary
The meeting begins with a discussion about the recent Petra update, with Parithosh noting that no significant issues have been reported by client teams. The main focus then shifts to planning for Fusaka Devnet 0. Parithosh outlines the EIPs included in this devnet, which are Pierdas, MoD XP upper limit, MoD XP gas cost increase, and blob parameter only hard forks. All client teams present (including Besu, Geth, Reth, EthJS, and Nethermind) express agreement with including both MoD XP EIPs in Fusaka Devnet 0. Parithosh shares a link to the Fusaka Devnet 0 specifications and invites teams to reach out once their clients are ready for testing.
The group discusses how to handle Blob-carrying Proof of Obligation (BPO) changes in Ethereum. Marius suggests treating BPOs as normal hard forks on the execution layer, using existing mechanisms to update fork IDs and specify forks. This approach would limit the number of BPOs that can be specified but is seen as sufficient. On the consensus layer side, Potuz notes that while the peering issue is similar, they prefer to avoid a hard fork if possible, suggesting signaling changes at the handshake level instead. Raúl argues that BPO changes alter rules and break backwards compatibility, so they should be treated as hard forks for clear communication. The group considers whether to implement hard forks or explore alternative approaches for both layers.
The group discusses implementing Blob Payload Ordering (BPO) changes for the upcoming Fusaka upgrade. They agree to use a hard fork approach on the execution layer (EL) side, setting multiple BPO times in advance. On the consensus layer (CL) side, they will use a handshake approach. The participants also discuss the need to update the consensus spec regarding BPO changes and peer connections. They clarify that timestamps are not needed in the blob schedule for EL implementations.
The group discusses the format for representing values in the EIP and chain specifications, with Andrew suggesting using decimal integers instead of hexadecimal strings. Mario agrees to investigate potential issues with using decimal numbers in JSON. Parithosh confirms that Nethermind can handle non-hexadecimal formats, and the group agrees to standardize on integers rather than hexadecimal strings. The discussion then shifts to the CL side, where potuz raises concerns about how to signal different forks in the P2P layer. The group considers options for peer scoring and handshake-level signaling but ultimately decides to leave the current implementation as-is to meet the Fukuoka devnet 0 deadline.
The group discusses implementing changes to peer-to-peer networking without a full hard fork. Potuz suggests adding a configuration to the handshake message, while Raúl proposes adding a field to communicate the change on the wire separately. Terence questions whether a hard fork approach might be simpler, given the limited scope of changes. The team agrees to explore adding a protocol field to avoid the traditional hard fork machinery while still implementing the necessary changes. Raúl volunteers to help steer this effort.
The group discusses the progress of PeerDAS implementation and testing. Devnet 7 is running smoothly, with backfilling being the main focus for client teams. Barnabas asks if client teams can ship PeerDAS 0.1 images by next Monday, with at least 3 ELs and 3 CLs needed. Mario indicates that Ethereum spec tests are still in progress, particularly for PeerDAS blobs and proof verification, making next week a safer target for their release. The group agrees to reassess on Thursday whether to proceed with Fusaka devnet 0 or wait for test releases. They also decide to use Kurtosis for BPO testing initially, rather than adding it to execution spec tests immediately.
The group discusses several open issues and pull requests related to Ethereum development. Manu explains a proposed “blind and local” flag for beacon nodes to reduce data transmission between beacon and validator clients. Will brings up an open pull request that hasn’t received attention for weeks, and he plans to follow up with Francis about it. Potuz provides an update on random linear network coding for block broadcasting, noting that its application for blob propagation is still uncertain. Raúl mentions that the peer-to-peer networking team plans to help drive this work, which may require changes to meshing topologies and transport protocols.
The group discusses several topics related to Ethereum development and testing. Barnabas mentions issues with the mock builder for MEV, and Parithosh suggests pushing for more testing once basic Fusaka functionality is working. Kamil provides an update on performance testing, mentioning preparation for a second version of the performance devnet and ongoing research on opcodes. The team agrees to increase the gas limit on the Hoodie testnet to 60 million, following Sepolia’s example. Ben emphasizes the importance of implementing a 10 MB block size limit in Fusaka to prevent network issues. Parithosh notes that they plan to test Hoodie at 60 million gas with attestation slashings to ensure proper network handling.
The group discusses potentially reducing the transaction limit from 30 million to 5 million gas, as transactions above this limit are typically subdividable or related to mining. Parithosh suggests adding this topic to the ECD meeting agenda for wider discussion. The topic of history expiry is briefly mentioned, but no progress updates are provided. Parithosh notes that a portal call about history expiry will follow the current meeting.