Jul 28, 2026
Invited Francesco Sukun Tarachandani raul.kripalani@ethereum.org Ben Edgington Roberto Saltini Yann Vonlanthen Kamil Salakhiev anton.nashatyrev@consensys.net mikhail.kalinin@consensys.net
Attachments Fast Finality + Networking
Meeting records Transcript
The meeting prioritized prototyping updates and finality parameters while establishing a new repository for consensus design documentation.
Prototyping and Finality Progress
Updates confirmed completion of specification work presented at recent industry meetings. The team established a target of 100-second finality using 8 slots.
Strategic Documentation Initiatives
The team decided to create a new, separate repository to centralize design rationale, requirements, and simulation benchmarks for better transparency. This replaces the consensus specifications repository for iterative work.
Technical Trade-off Discussions
Discussions centered on optimizing bandwidth through pre-aggregated attestations and evaluating the impact of potential post-quantum signature requirements. The group also reviewed validator consolidation trends and shuffler mechanisms.
-
New repository for design documentation The team will create a new, dedicated repository to house design documents, requirements, and simulation results, independent of the existing consensus specs repository.
-
Simulation methodologies for current and proposed systems Simulation efforts will utilize both the current system and the 'pre-aggregated attestations at source' proposal as baselines to evaluate network performance.
-
Aggregation at source EIP development commitment The team committed to collaborating with Francesca and George to draft an EIP for the 'aggregation at source' proposal.
We've updated the Decisions section using your feedback.
Let us know what you think: Helpful or Not Helpful
-
[Mikhail] Try Brave: Switch to Brave for future meetings to improve performance.
-
[Sukun Tarachandani] Send Finality Update: Provide findings from finality simulation results asynchronously.
-
[Sukun Tarachandani] Check Gossip Protocol: Investigate if gossip sub supports 4 slot rounds.
-
[Sukun Tarachandani] Prototype Aggregation Timing: Implement a proof of concept for voting during the aggregation phase.
-
[Sukun Tarachandani] Create Design Repo: Establish a new repository for consensus specifications and simulation results.
-
[Roberto Saltini] Draft EIP: Contact Francesca and George to initiate the drafting of an aggregate at source EIP.
-
[Ben Edgington] Migrate Project Tracking: Rebuild project tracking systems in Linear.
-
[The group] Evaluate Coding Schemes: Assess arithmetic coding or other coding techniques to manage potential increases in aggregation bit field sizes.
-
Browser Compatibility and Meeting Logistics: Mikhail and Yann discussed browser compatibility for Google Meet, noting that Mikhail experienced performance issues on non-Chrome browsers, while Yann suggested using the Brave browser to access additional features (00:00:11).
-
Meeting Agenda and Prototyping Updates: Yann opened the meeting by suggesting discussion points, specifically focusing on prototyping progress. Sukun confirmed they were midway through their work on the prototype and proceeded to provide an update (00:01:14).
-
CIP and Consensus Specification Progress: Sukun reported that their work on the CIP and consensus specification was complete and had been presented at the ACTC the previous Thursday. Sukun explained their decision to use a minimal approach for Hagata, leveraging existing data column machinery to maintain feasibility and avoid networking risks associated with more complex, unproven solutions .
-
Finality Simulation Parameters: Sukun clarified that the proposed algorithm aimed for 100-second finality using eight slots, which requires completing two full rounds of voting. Ben noted that this necessitates one round of voting within four slots, and Sukun committed to verifying if the gossip sub protocol supports this configuration .
-
Simulation Methodology and Scope: Sukun described the simulation setup using the E slot sim emulator to model validator voting fractions and network block propagation. The current configuration includes an availability chain with a 4-4-4 structure and a finality chain involving 1-second computation, 8-second vote propagation, and 4-second aggregation .
-
Documentation and Development Repository: The group discussed the best location for design documents, simulation results, and networking specifications. They agreed that the current consensus specs repository was not well-suited for iterative design work. Consequently, the team decided to create a new, separate repository to house the design, rationale, requirements, and repeatable simulation benchmarks, allowing for better collaboration and transparency .
-
Shorter Slot Timing Considerations: Yann raised concerns regarding potential industry pressure to implement shorter slots, such as a 10-second duration, earlier than expected. The participants acknowledged that if such changes are introduced for the star protocol, they would need to adjust their simulations and models accordingly to reflect the impact on finality and network performance .
-
Pre-aggregated Attestations at Source: Sukun advocated for the inclusion of pre-aggregated attestations at the source, arguing that it could reduce total bandwidth usage by at least 30%, even in worst-case scenarios where only a portion of validators cooperate. Mikhail noted that while some developers expressed mixed opinions, the team agreed it would be a beneficial optimization to pursue .
-
Post-Quantum Signature Challenges: The participants debated the impact of post-quantum (PQ) signature requirements on current development efforts. There was a discussion regarding the ongoing proposal to potentially retain BLS infrastructure or utilize one-time private keys to avoid the complications of current aggregation methods, acknowledging that the PQ argument remains a significant factor in decision-making .
-
Validator Consolidation: Ben and Yann discussed the trend of validator consolidation, noting that some operators are actively consolidating stake. This trend impacts the necessity of certain aggregation proposals, and the group generally agreed to continue monitoring the situation rather than forcing premature architectural changes .
-
On-chain Commitment Mechanism: Roberto proposed an on-chain commitment mechanism where entities would guarantee aggregation at the source. Mikhail expressed reservations, suggesting that such requirements might be difficult for node operators to manage if they need to split or move validators. The team concluded that while it is an interesting concept, they would consider documenting it in an EIP to facilitate further discussion .
-
EIP Creation and AI Tools: The group briefly touched upon the process of drafting EIPs, with some members noting the difficulty of reading or writing them using AI-assisted tools, and agreed to coordinate with other researchers like Francesca and George to move these proposals forward (00:47:23).
-
VRF and Shuffling Mechanisms: Yann proposed exploring the use of a Verifiable Random Function (VRF) to assign rounds instead of the current shuffling mechanism. Ben and Roberto noted that while shuffling is computationally expensive, moving to a VRF could introduce significant variance in set sizes and increase aggregate size due to the requirement for full bit vectors. Mikhail explained that the current shuffling is critical for mapping smaller bit fields to the larger beacon state voting flags, and the team decided to continue evaluating these trade-offs .
You should review Gemini's notes to make sure they're accurate. Get tips and learn how Gemini takes notes
How is the quality of these specific notes? Take a short survey to let us know your feedback, including how helpful the notes were for your needs.