---
# System prepended metadata

title: 'Attestation aggregation: in-place aggregation'
tags: [algorithms, data structures]

---

# Attestation aggregation: in-place aggregation
###### tags: `data structures` `algorithms`

**Author(s):** Victor Farazdagi (Prysmatic Labs)  

*Last Updated: Jan 27, 2021*

[TOC]


## Overview
The aim of this document is to describe the optimal implementation of in-place (that's
without any extra allocations) aggregation of attestations using max-cover algorithm.

For the actual implementation of this design, see 
[maxcover.go](https://github.com/prysmaticlabs/prysm/blob/develop/shared/aggregation/attestations/maxcover.go) 
in our official repo.

## API

You are given a slice of pointers to attestations `[]*Attestation` (the actual content of the `Attestation`
type is not important, all we need is to make sure that it stores its bitlist in `Bitlist64` format used
in our max-cover algorithm implementation), which is supported by the following **underlying array**:

```mermaid
graph LR
    a0 --- a1 --- a2 --- a3 --- a4 --- a5 --- a6 --- a7 --- a8 --- a9 --- a10
```

And the aim is to aggregate as many of them, and come up with an updated array:

```mermaid
graph LR
    b0[a0, a3, a5] --- b1[a4, a10] --- b2[a1] --- b3[a2] --- b4[a6] --- b5[a7] --- b6[a8] --- b7[a9] --- b8[nil] --- b9[nil] --- b10[nil]
    style b0 fill:#adf
    style b1 fill:#adf
    style b8 fill:#fed
    style b9 fill:#fed
    style b10 fill:#fed
```

Here, the first two elements **of the same** (hence the title "in-place") underlying array, are aggregate
attestations (the first being the combination of signature of attestations `a0`, `a3`, and `a5`), then we
have items that are not aggregatable (say, they have overlapping bits with some aggregated attestation), and
the last three items are set to nil (and thus can be garbage collected) as they were holding aggregated items.

## Proposed implementation

### Step 1: Prepare variables
Essentially, we want to split our underlying array into 3 parts, by data type they are holding:
- newly created aggregated attestations
- unaggregated attestations
- nil attestations (those elements can be garbage collected)

In order to keep track of them we will need just two variables:
```go
// assuming that all incoming attestations are in `atts` variable:
aggregated := atts[:0]
unaggregated := atts[:]
```

The `aggregated` slice is inited empty, and by pushing into it with `unaggregated = append(unaggregated, aggregate)`
we will be able to update the same underlying array (we will make sure that element which is replaced by
such a push is preserved at some other slot).

And `unaggregated` slice will take care of the second and third parts of the underlying array: all items
that are within range or that slice -- unaggregated, if that slice is shrink i.e. there are items in underlying
array that are not covered by that slice -- those are nil, and garbage collectable.

:::info
**Important Invariant:** 

At any moment the partial solution can be obtained by `append(aggregated, unaggregated...)`.
Indeed, by combining those slices we are getting all the elements of the underlying array except for nil ones (third part)
which are not necessary to return, and will be garbage collected.
:::

### Step 2: Find coverage
All attestations that are pointed by `unaggregated` are candidates for aggregation:
```go
// Obtain maximum (up to whole length of `unaggregated` slice) coverage:
selectedKeys, coverage := MaxCover(unaggregated, len(unaggregated))
```
The `selectedKeys` list will hold all the indexes of attestations that can be aggregated during this round,
and the `coverage` will hold a combined bitlist of aggregated attestations (that's all the bits that are set to 1 when
all those attestations are taken together).

Suppose we have the following three attestations marked as selected by `selectedKeys`:

```mermaid
graph LR
    a0 --- a1 --- a2 --- a3 --- a4 --- a5 --- a6 --- a7 --- a8 --- a9 --- a10
    style a3 fill:#6c6
    style a5 fill:#6c6
    style a10 fill:#6c6
```

### Step 3: Aggregate

Before we decide whether to aggregate those selected attestations we need to check whether their combined
`coverage` contains any bits that haven't been already covered by some previous aggregations, because if all
the bits are already covered, we can simply ignore those unaggregated attestations -- they do not provide any
new information.

So, there are 2 cases:
- The `coverage` has some new bits: in that case we need to create a new combined attestation and persist 
that aggregate in our `aggregated` slice.
- The `coverage` has no new bits: individual attestations can be dropped.

#### 3.1: Create an aggregate attestation
In order to optimize things we accumulate the new aggregation at the memory location where `a3` is stored i.e.
we create an aggregate attestation (which has all the same data as `a3`, `a5`, and `a10`, with bitlist set to `coverage`, 
and signature is combined/aggregated signature of all three items):

```mermaid
graph LR
    b0[a0] --- b1[a1] --- b2[a2] --- b3[a3, a5, a10] --- b4[a4] --- b5[a5] --- b6[a6] --- b7[a7] --- b8[a8] --- b9[a9] --- b10[a10]
    style b3 fill:#adf
    style b5 fill:#adf
    style b10 fill:#adf
```

So, we have an aggregate stored at `a3` location of the underlying array, `a5` and `a10` can be removed.

Now, we need to push that `a3, a5, a10` aggregate into `aggregated` slice, if, however, we do the following:
```go
// Assuming aggregate = Attestation{a3, a5, a10}:
aggregated = append(aggregated, aggregate)
```
we will overwrite `a0` (remember our `aggregated` was initialized with `atts[:0]`), so we make sure we preserve it before pushing the newly created aggregate into `aggregated`. 

All we need to do is to find the first non-aggregated item before the `a3, a5, a10` aggregate, and swap
that item with the aggregate. Non-surprisingly, it is easy to do:
```go
// Assuming idx is index of the aggregate attestation:
idx0 := len(aggregated)
if idx0 < idx {
    atts[idx0], atts[idx] = atts[idx], atts[idx0]
    aggregated = atts[:idx0+1]      // expand to newly added aggregate
    unaggregated = unaggregated[1:] // shift the starting point of the slice
}
```

Underlying array will have the following layout:
```mermaid
graph LR
    b0[a3, a5, a10] --- b1[a1] --- b2[a2] --- b3[a0] --- b4[a4] --- b5[a5] --- b6[a6] --- b7[a7] --- b8[a8] --- b9[a9] --- b10[a10]
    style b0 fill:#adf
    style b3 fill:#f97
    style b5 fill:#adf
    style b10 fill:#adf
```

And if we include `aggregated` and `unaggregated` slices (note that "end" is inclusive):
```mermaid
graph LR
subgraph main["Underlying array"]
    b0[a3, a5, a10] --- b1[a1] --- b2[a2] --- b3[a0] --- b4[a4] --- b5[a5] --- b6[a6] --- b7[a7] --- b8[a8] --- b9[a9] --- b10[a10]
    style b0 fill:#adf
    style b3 fill:#f97
    style b5 fill:#adf
    style b10 fill:#adf
end
subgraph aggregated["aggregated"]
    agg1["start"] --> b0
    agg2["end"] --> b0
end
subgraph TB unaggregated["unaggregated"]
    unagg1["start"] --> b1
    unagg2["end"] --> b10
end
```


#### 3.2: No need to aggregate

No need to do anything.

### Step 4: Cleanup
So, depending on whether we did aggregate during the previous step, we end up with either
```mermaid
graph LR
    b0[a3, a5, a10] --- b1[a1] --- b2[a2] --- b3[a0] --- b4[a4] --- b5[a5] --- b6[a6] --- b7[a7] --- b8[a8] --- b9[a9] --- b10[a10]
    style b0 fill:#adf
    style b3 fill:#f97
    style b5 fill:#adf
    style b10 fill:#adf
```
or 
```mermaid
graph LR
    b0[a0] --- b1[a1] --- b2[a2] --- b3[a3] --- b4[a4] --- b5[a5] --- b6[a6] --- b7[a7] --- b8[a8] --- b9[a9] --- b10[a10]
    style b3 fill:#adf
    style b5 fill:#adf
    style b10 fill:#adf
```
underlying array.

We now need to traverse `selectedKeys` one more time and remove redundant attestations. Essentially, it is
the same procedure, but when aggregation has actually occurred during the previous step, we will traverse
`selectedKeys[1:]`, instead (as at index 3 there's a new element -- `a0`, which should be left intact).

Item removal is also done in-place, let's illustrate for the first case:
```mermaid
graph LR
subgraph three["remove a10"]
    d0[a3, a5, a10] --- d1[a1] --- d2[a2] --- d3[a0] --- d4[a4] --- d5[a9] --- d6[a6] --- d7[a7] --- d8[a8] --- d9[a5] --- d10[a10]
    style d0 fill:#adf
    style d9 fill:#fed
    style d10 fill:#fed
end
subgraph two["remove a5"]
    c0[a3, a5, a10] --- c1[a1] --- c2[a2] --- c3[a0] --- c4[a4] --- c5[a9] --- c6[a6] --- c7[a7] --- c8[a8] --- c9[a5] --- c10[a10]
    style c0 fill:#adf
    style c5 fill:#f97
    style c9 fill:#fed
    style c10 fill:#adf
end
subgraph one["before removal"]
    b0[a3, a5, a10] --- b1[a1] --- b2[a2] --- b3[a0] --- b4[a4] --- b5[a5] --- b6[a6] --- b7[a7] --- b8[a8] --- b9[a9] --- b10[a10]
    style b0 fill:#adf
    style b5 fill:#adf
    style b10 fill:#adf
end
```
Here is what happens:
- When we are removing `a5`: find the highest non-aggregated item at right of the current item, swap.
Once done, you can shrink `unaggregated` to the slot before that highest position -- as all items after and
on it are aggregated.
- When we are removing `a10`: nothing needs to be done -- there's no unaggregated item at the right of `a10`!

:::info
At this point our slices look like:
- `aggregated` starts at 0, has length of 1 (capacity is that of underlying array, of course).
- `unaggregated` starts at 1, has length of 8 (items `a1..a8`).
:::

### Step 4: Repeat..

If there are `unaggregated` items left (and we didn't hit the threshold of rounds), we repeat "Step2: Find coverage",
passing in our updated `unaggregated` slice. Note that `selectedKeys` will be within the range of that updated
`unaggregated` slice, so there will be no problems of the next rounds mixing things for aggregated or nil
attestations of previous rounds. 

Let's illustrate:

```mermaid
graph LR
subgraph six["repeat?"]
    g0[a3, a5, a10] --- g1[a2, a9, a6] --- g2[a1] --- g3[a0] --- g4[a4] --- g5[a8] --- g6[a7] --- g7[nil] --- g8[nil] --- g9[nil] --- g10[nil]
    style g0 fill:#adf
    style g8 fill:#fed
    style g9 fill:#fed
    style g10 fill:#fed
    style g1 fill:#adf
    style g7 fill:#fed
end
subgraph five["cleanup"]
    f0[a3, a5, a10] --- f1[a2, a9, a6] --- f2[a1] --- f3[a0] --- f4[a4] --- f5[a8] --- f6[a7] --- f7[a6] --- f8[a9] --- f9[nil] --- f10[nil]
    style f0 fill:#adf
    style f8 fill:#fed
    style f9 fill:#fed
    style f10 fill:#fed
    style f1 fill:#adf
    style f7 fill:#fed
end
subgraph four["update aggregated/nonaggregated slices"]
    e0[a3, a5, a10] --- e1[a2, a9, a6] --- e2[a1] --- e3[a0] --- e4[a4] --- e5[a9] --- e6[a6] --- e7[a7] --- e8[a8] --- e9[nil] --- e10[nil]
    style e0 fill:#adf
    style e9 fill:#fed
    style e10 fill:#fed
    style e1 fill:#adf
    style e5 fill:#adf
    style e6 fill:#adf
end
subgraph three["aggregate"]
    d0[a3, a5, a10] --- d1[a1] --- d2[a2, a9, a6] --- d3[a0] --- d4[a4] --- d5[a9] --- d6[a6] --- d7[a7] --- d8[a8] --- d9[nil] --- d10[nil]
    style d0 fill:#adf
    style d9 fill:#fed
    style d10 fill:#fed
    style d2 fill:#adf
    style d5 fill:#adf
    style d6 fill:#adf
end
subgraph two["selected attestations"]
    c0[a3, a5, a10] --- c1[a1] --- c2[a2] --- c3[a0] --- c4[a4] --- c5[a9] --- c6[a6] --- c7[a7] --- c8[a8] --- c9[nil] --- c10[nil]
    style c0 fill:#adf
    style c9 fill:#fed
    style c10 fill:#fed
    style c2 fill:#6c6
    style c5 fill:#6c6
    style c6 fill:#6c6
end
subgraph one["before second round begins"]
    b0[a3, a5, a10] --- b1[a1] --- b2[a2] --- b3[a0] --- b4[a4] --- b5[a9] --- b6[a6] --- b7[a7] --- b8[a8] --- b9[nil] --- b10[nil]
    style b0 fill:#adf
    style b9 fill:#fed
    style b10 fill:#fed
end
```


## Conclusion

Since incoming `[]*Attestations` slice can only shrink (we are filtering out aggregated attestations), we
can be assured that enough memory have been already allocated, and proceed with all the filtering/covering
networks without allocating anything.

:::warning
In this whole design there's only one place, where we still need to allocate new memory: 
when creating an aggregated attestation, allocation for that newly created attestation is unavoidable 
(that's also done in the most optimized way possible, without recalculating what we already know, like
combined coverage bits).
:::