# Signature Aggregation Networking Simulator

*Authors:* George Kadianakis, Dmitry Khovratovich, Benedikt Wagner, Kevaundray Wedderburn

In this note, we explain our vision of having a networking simulator dedicated to signature aggregation. The simulator should take as input several parameters and the aggregation topology and output several statistics and metrics.

The simulator could be used in the context of the *Beam chain*, but is also useful in the context of the *Beacon chain*. Our hope is that someone is interested enough to implement it, thereby significantly contributing to the Beam chain effort.

## Protocol

The signature aggregation protocol looks roughly as follows.

1. Validators sign blocks.
2. Individual signatures are sent around and received by aggregators.
3. Aggregators aggregate several signatures and forward the resulting aggregations with the bitmask of signers.
4. The aggregations are either posted as is to the chain or undergo several hops in order to accumulate sufficiently many signatures.

## Expected Deliverable
Our vision would be a framework or tool that simulates networking behavior for signature aggregation.

### Input
We expect the tool to take the following inputs:
- A networking topology and parameters:
- Average connectivity (number of outgoing connections)
- Average latency (amount of time needed to send and receive a packet) -- as a function of packet size
- Bandwidth of nodes (different nodes may have different bandwidths)
- A topology/strategy of aggregation (see below)
- Several parameters modeling the cryptography:
- Signing time
- Signature size
- Aggregation time (maybe as a function of #sigs to aggregate)
- Aggregate signature size
- Time to aggregate aggregates
- Time to verify aggregate signatures
- *Note.* The cryptography is not fixed yet, so all of this has to be variable

### Output
We expect the tool to then output several statistics, e.g.,
- How long did it take from nodes receiving the message to the point where sufficiently many nodes have received and an aggregate signature of sufficient weight?
- Has the full available bandwidth been used?

## Aggregation Topologies
Aggregation topologies specify in which order we aggregate signatures. Roughly, we can think of them as a directed graph.
Same example topologies:
- *Star:* All parties send to one party, this party aggregates and then redistributes the aggregate signature.
- *Redundant Star:* Like Star, but with multiple aggregators.
- *Chaotic:* Nodes gossip around their signatures and greedily aggregate whatever they can find.

## Nice To haves and Future Work
After an initial version of the tool, we envision the following additions in the longer future:
- First, a local simulation on one machine is already good, but later one may want to extend the simulation to run the nodes on different machines.
- First, one could hardcode topologies, but then it would be nice if one could easily extend it with other topologies.
- One topology that is more complex is the *Tree* topology. We can think of the Star as a depth-1 tree with fan-in `n-1` for `n` nodes. We can generalize this to a depth-`k` tree with fan-in `f`. One reason why it is more complex is that we now need to take into account that aggregating aggregates is a different task (e.g., may take longer) than just aggregating signatures. Therefore, the inputs to the tool will also change.