---
# System prepended metadata

title: BBA update performance vs back of the envelop estimates

---

# BBA update performance vs back of the envelop estimates


## Estimates

**Scenario 1**: `U`users; each updates a single counter

Server Costs:
- `C_0` + `U` * `C_1`, where 
    - `C_0` is a larger constant (≈ 100-200ms) and 
    - `C_1` is a small constant (≈ 2-5ms)


**Scenario 2**: `U`users; each updates `n_1` counters

Server Costs:
- `C_0` + `sum_{i=1}^U (C_1 + C_2 n_i)`, where
    - `C_0` is a larger constant (≈ 100-200ms) and 
    - `C_1` is a small constant (≈ 2-5ms)
    - `C_2` is a small constant

*Note*: If the user updates counters `j_1, ... j_n` with changes `a_1, ... a_n`, the server has to compute an elliptic-curve multi-scalar multiplication `sum_{i=1}^n a_i G_{j_i}`. 


## Performance results

Based on bechmarks of https://github.com/imeckler/bba

![](https://i.imgur.com/zitA3DX.png)

## Questions:
- Would it be possible to achieve similar performance of update per counter for 100 users, 1 update (currently at ≈1.5ms per ad) as in 100 users, 30 counter updates ( currently at ≈ 0.0032ms /ad).

Why? ---> ≈ 0.0032ms /ad would improve the server-side costs compared to the current privacy-pass scheme. However, we want to avoid batching ad updates per BBA (i.e. having to update more than 1 ad per user request) so that we maintain the threat model as we have nowadays, that claim that we are not able to link 2 ad interactions together (even if the user is anonymous).