---
# System prepended metadata

title: Libp2p and stream handling

---

# Libp2p and stream handling

## The problem
Current version of libp2p has an attack surface where a remote peer can cause resource exhaustion by making a large number of connections.

## Solutions

Upgrading to libp2p version 0.19.4 in order to use it's new resource manager.
Configure the resource manager to have some reasonable limits on number of streams and memory allocation.

Downsides:
Our code base was not written with a hard limit on stream count in mind.
This approach will likely require changes in our protocols.

## Workarounds

### Cache
By using a cache we can recycle the streams. It can become a bottleneck for the protocols with a high churn rate of streams.

Requires writing a custom scheduler which is a high effort/high risk effort.

NEXT TO TRY: implement the cache as a pool that would take back the stream upon reset

todo: metrics 

### Stream multiplexing
Opening one stream per peer but introducing an intermediate layer that will multiplex the requests. To Be Elaborated.


### Upgrade to latest version of libp2p (monorepo)
It introduces an auto-scaler that could help us with resource management. The issue is that they updated their elliptic curve cryptography library that is not compatible with our keys.

todo: add issues
dropping btc, new underlays

TO TRY: start a fresh cluster (generate keys with P256())

### 
