# Devnet 5 Proposal

## 1. Devnet 4 Summary

Over the last few days, the specifications for Devnet4 have been finalized and are expected to remain stable, aside from ongoing refactors and test improvements.

Devnet4 introduced the following key features:

#### 1. Proposer Keys for Validators
Each validator now maintains two keys:
- **Attestation key**
- **Proposer key**

This enables block signing.

#### 2. Recursive Aggregation per Message
Proofs for a single `attestation_data` can now be **recursively aggregated**.

#### 3. In-Block Aggregation by Proposers
During block construction, proposers:
- Aggregate all proof payloads for a given `attestation_data`
- Produce a **single aggregated payload** per `attestation_data`

#### 4. Maximum Attestation Data Limit
A constant `MAX_ATTESTATION_DATA` limits the number of unique `attestation_data` included in a block to **8**.

---

## 2. Outcome of Devnet4

With recursive aggregation:

- Each `attestation_data` now has **one aggregated payload** instead of multiple proofs
- This reduces:
- The number of payloads per block
- Overall block size (proofs are the largest component)

As a result:
- Network bandwidth usage decreases
- Block propagation becomes more efficient

---

## 3. Remaining Limitation

Despite these improvements:

- A block still contains **multiple aggregated payloads** (one per `attestation_data`)
- Proofs remain the **largest component** of the block

This motivates further compression.

---

## 4. Devnet5 Proposal: Block-Level Proof Aggregation

Devnet5 proposes **multi-message aggregation**, where:

- Proofs across all `attestation_data` in a block are aggregated
- The block signature is included in the aggregation
- The result is a **single proof per block** (**block proof**)

### Goal

- Replace multiple aggregated payloads with **one block proof**
- Further reduce:
- Block size
- Network bandwidth
- Gossip overhead

---

## 5. Key Challenge: Loss of Reusability

While block proofs reduce size, they introduce a key limitation:

> A block proof does not expose the underlying per attestation_data aggregated payloads.

### Why this matters

- Future blocks require **per attestation_data proofs** for aggregation
- Validators receiving only the block proof:
- Cannot extract underlying payloads
- Cannot reuse them for future aggregation

---

## 6. Example Scenarios

### Scenario 1: Hidden Payloads


**Figure 1: Block proof hides intermediate aggregated payloads**

- Block 2 contains a block proof for `attestation_data1`
- Validator 3 receives Block 2 but **does not receive intermediate aggregated payloads via gossip**

#### When building Block 3

Validator 3:

- Can follow fork choice correctly
- Cannot reconstruct aggregated payloads for `attestation_data1`
- Cannot include those votes in new aggregations

#### Implication

- Fork choice remains correct
- Proof state becomes **incomplete and non-reusable**

---

### Scenario 2: Fork Justification Issues


**Figure 2: Fork leads to store justification**

- Block 4 contains a block proof for `attestation_data_1`
- Latest head is at Block 3 because the latest justified checkpoint is still `0`

#### When building on head

- Store justified > head justified
- Indicates payload propagation issues

Treat the node as **not synced** and avoid block production

---

## 7. Impact on Aggregation Workflow

With block proofs:

- `known_aggregated_payloads`:
- Can be updated during block construction
- But:
- Cannot be reconstructed from block contents
- Cannot be reused unless received separately

This creates a **gap between block validation and proof availability**

---

## 8. Initial Approach: Multi-Message Aggregation

As a first step, we can explore **aggregation across a small number of messages (e.g. 2)**.

### Example

From Block 1:

- `proof_ad1` → proof for `attestation_data1`
- `proof_ad2` → proof for `attestation_data2`

We aggregate them into:

- `proof_ad12` → combined proof

If a **common message format** is defined, this allows:

- Iterative aggregation
- Construction of a **binary aggregation tree**

---

## 9. Toward a Block Proof

Using binary aggregation:

- Leaf nodes → individual proofs
- Intermediate nodes → aggregated proofs
- Root → **block proof**

This provides a path toward full block-level aggregation.

---

## 10. Open Questions and Considerations

### 1. Reusability
- Does this design impact fork choice?
- Current assumption: fork choice remains correct since blocks are built on parents, even if aggregated payloads are missing.

### 2. Aggregation Structure
- Steps to acheive multi message aggregation.

---

## 11. Summary

- Devnet4 introduced **per attestation_data recursive aggregation**, reducing proof overhead
- This improves efficiency but introduces:
- **Loss of intermediate proof reusability**

---

## 12. Next Steps

- Implement and test **2-message aggregation**
- Evaluate:
- Feasibility of aggregation trees
- Impact on proof reuse
- Interaction with gossip
- Iterate toward full **block proof design**

> Note: Block proof generation may require a longer block proposal interval