Implement protections against sybil attacks

[bhartnett]

At some point we may want to implement some scheme to make sybil attacks against Portal Network more difficult or costly. For example without any protections there is nothing preventing a malicious actor from spinning up many portal nodes each with a unique ENR and spamming the network with bad offers. If they send offers that fall within the radius of other nodes, these nodes will use resources to accept, download, validate and then reject the data.

We should implement a range of protections to reduce the impact and protect against attacks like this, such as adding misbehaving nodes to a temporary ban list and limiting the number of concurrent offers that will be accepted from each node. Some portal clients may already implement some or all of these protections but even so it is easy to get around these protections by spinning up more nodes with unique ENRs because each new ENR will not be in any ban lists.

In order to make it harder and more costly to create new ENRs/nodes perhaps we could consider using some form of 'proof of work' like scheme that would require some computational puzzle to be completed when creating a new ENR. A modify version of Kademlia called 'S/Kademlia' does just this. It could be used to make it more difficult to create a large number of malicious nodes. Once having something like that in place, you can start to add restrictions or limits per ENR/nodeID which are assumed to be difficult to generate.

The scheme is described here:

• https://telematics.tm.kit.edu/publications/Files/267/SKademlia_slides_2007.pdf
• https://www.giulianomega.com/post/2023-07-24-secure-kademlia/

[bhartnett]

[bhartnett]

[bhartnett]

Perhaps we should also consider using a modern memory hard hash function such as Argon2 instead of sha256 when hashing public keys in order to prevent GPUs and ASICs from bypassing the protections. I'm not sure if the ENR spec allows this, requires more investigation.

[bhartnett]

cc @pipermerriam