TLDR Let's ship PeerDAS in Fusaka. Other things can wait. Long-ish version Since we finalized Pectra's scope in 2024, data availability has become a major concern for the network. More blobs have been a long promise, and even after Pectra's slight increase, it is still falling short of the needs and expectations of the community. We believe that PeerDAS (EIP-7594) is the most important item for Fusaka. This is a complex EIP and involves different components of the client. Therefore, we are committed to making it our number one priority for Fusaka. Any other EIP should be considered only if we strongly believe it does not risk the opportunity of delivering Fusaka later in 2025.

This post is an overview of the Teku team's Pectra retrospective. It exists to (try to) consolidate the individual and shared opinions of team members into a somewhat structured document. Summary It is impressive to see how much we have evolved in our testing capabilities, largely due to the support from EthPandaOps and the tooling they have developed. We cannot stop praising them for all their work and how much more productive we are because of their help. It is really good to see many teams working together and collaborating towards making the protocol better. Interop events and Eth R&D workshops have been super valuable. Scope creep has impacted our productivity and workflow and made us take longer to deliver value. We should try to have a better understanding of the features going into a fork earlier in the cycle, and converging into a stable scope sooner. Ideally, every fork should have a clear goal (associated with the Ethereum roadmap). This can help core-devs to understand where to focus and also help us during the process of scoping and prioritizing features. We need to rethink the way we make decisions about EIP inclusion in a fork. Ideally, we want more mature EIPs being scheduled, after teams have had time to understand their value, impact and implementation details. The separation between ACDE and ACDC seems artificial and creates more harm than good. We believe that we should move towards having a unified call, to talk about scope, priorities and governance related to the protocol. Separate “technical” calls can be held between Execution teams and Consensus teams to discuss anything relevant just to one of the layers.

10 October 2024 Description A clash in the library jc-kzg-4844 version between Teku and the Besu dependency (v2.0.0 and v1.0.0) caused a startup issue on Windows machines only. Ubuntu and MacOS do not seem affected. A manual workaround was needed (delete jc-kzg-4844-1.0.0.jar from /lib) for Teku to start. Link to Pull Request with fix User Impact

08 October 2024 Description Teku 24.10.0 version had a regression bug that caused an error when loading a user-supplied proposer config file. The error was preventing teku from starting up. Users had to downgrade back to 24.8.0 to be able to start Teku again. The problem was caused by a recent refactoring in our Validator API code. Unfortunately, our testing code used a different code path than production to initialize ProposerConfigLoader, preventing our automated tests from catching this issue. Only our testing fleet in the Sepolia network had a node using this option. This was an oversight on our part, as our Sepolia fleet is not used as part of our release testing process. Link to GitHub issue A minor unrelated issue was that the release notes for 24.10.0 had the wrong hash for the tar.gz file. This has been reported by one user.