Holidays for za: Family Day - 2024-04-01 to 2024-04-01 (1 days) Freedom Day - 2024-04-27 to 2024-04-27 (1 days) Workers' Day - 2024-05-01 to 2024-05-01 (1 days) Special Public Holiday (Elections) - 2024-05-29 to 2024-05-29 (1 days) Youth Day - 2024-06-16 to 2024-06-17 (2 days) National Women's Day - 2024-08-09 to 2024-08-09 (1 days) Heritage Day - 2024-09-24 to 2024-09-24 (1 days) Day of Reconciliation - 2024-12-16 to 2024-12-16 (1 days) Christmas Day - 2024-12-25 to 2024-12-25 (1 days)

Optimal Attestation Packing in Lighthouse Motivation Attestation packing is the process by which Ethereum consensus clients chose the attestations to include in a block. This is a topic that client teams did significant work on even prior to the Merge because the block proposer's rewards are directly affected by how closely the packed attestations match the canonical chain. Currently, Lighthouse implements a greedy strategy for deciding which attestations the proposer includes in the block. This leads to near optimal solutions in many cases, but there are outliers that do not have a known lower bound on quality. For instance, during testing the Lighthouse team and Satalia found an instance where the performance of the greedy strategy was about 60% of the optimal solution. And over the course of an 8 day data collection period the greedy algorithm was about 0.26 ETH lower than the optimal attestation packing reward. Our project seeks to remedy the situation by implementing an optimal attestation packing algorithm that runs in production at least for stronger machines. Project description After the great work of Sigma Prime and Satalia during their collaboration on the topic, we propose implementing their solution to maximal clique enumeration for attestation aggregation, as well as an improved maximum coverage algorithm that takes advantage of the structure of the problem. Specification

<- Last Update This week was spent implementing the original MIP solver-based algorithm for the Maximum Coverage Problem. Before jumping into the implementation of the new approach, I'll explain how the currently implemented Greedy Algorithm works. The maximum_cover accepts an iterator over a list of objects which implement the operation_pool::MaxCover trait, which is defined as follows: /// Trait for types that we can compute a maximum cover for. /// /// Terminology: /// * `item`: something that implements this trait

<- Last Update The attestations aggreagtion problem can be broken down into two parts: The aggregation stage, which takes existing attestations (unit and pre-aggregated) and produces the best possible aggregations subject to the constaints of BLS aggregation. The packing stage, which selects $K$ aggreagates from the output of the first stage in-order to maximise the validator coverage. Here, $K=128$. Me and Geemo agreed that the best way to split the tasks would be for him to handle the aggreagation stage, while I would be working on the packing stage. As I mentioned in my previous update, most of my research was targeted at the Aggregation Stage and the Bron-Kerbosh algorithm, so started afresh and began my research into the Packing Stage. Existing Implementation

Hello everyone! I'm Ankur and am excited to participate in the 4th cohort of the fellowship as a permissionless participant! Since I have a full-time job I plan to contribute in the mornings of my weekdays and primarily on the weekends. I'm highly interested in working on the Lighthouse consensus client, and the project on optimising attestation aggregation looks very interesting to me. I've decided work on this project for this fellowship. I'll use this note to document my updates prior to the fellowship officially kicking off, over a period of 2 weeks. Learning Rust The majority of this week was spent learning Rust from scratch. The Rust Book was my primary reading material here, and videos from NoBoilerplate to get a general sense of the ideology behind Rust. I then solved a few challenges from the Advent of Code 2022 in Rust to get a hang of things, the solutions to which can be found here. Coming from a Typescript background, I was very curious about the concurrency models supported by Rust. I was surpised to learn that pretty much everything is possible, and EventLoop style concurrency is supported via custom community maintained runtimes like Tokio. I reviewed the Async Book to get a general understanding of Rust's support for async/.await, and also spent some time playing around with Messaging Passing style of concurrency via channels. In the coming weeks I would be interested in trying out the Shared Memory style of concurrency as well.