Don't accept (many?) concurrent offers for the same content key

[kdeme]

Currently, when an offer comes in, the content key is checked on whether it is inRange and next whether it is not yet in our db.
If both are true, content transfer is accepted. If there are more offers of the same content before it gets transferred, validated & stored in the db, these will also be initiated.

We should cache the content key or content id and verify if no offer/accept is already ongoing for the same content.

One important side node, if the ongoing transfer fails or the content is not valid for some reason, a RFC should be launched for that content so that node can still receive it from another node.

[kdeme]

Related Portal specs issue: ethereum/portal-network-specs#242

[bhartnett]

To solve this, why don't we limit the number of concurrent offers per key for each ENR to one. ENR's contain a signature so there is some benefit to this. To further improve this there are some schemes that add a kind of proof of work requirement when generating a node id where for example all node IDs must have a certain number of zeros prefix. I wonder if something like this could be used with the existing ENR spec.

This would mean a malicious node could only send 1 bad offer for a given content id at a time without expending some cost generating more nodes.

The 'proof of work' nodeId generation scheme is from S/Kademlia. See here:

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

Of course what I've described above doesn't prevent accepting multiple offers for a given content key from different nodes and I think this is ok because we don't know how many of these offers will fail validation so we shouldn't reject until successfully validating and storing one in the database.

[kdeme]

Of course what I've described above doesn't prevent accepting multiple offers for a given content key from different nodes and I think this is ok because we don't know how many of these offers will fail validation so we shouldn't reject until successfully validating and storing one in the database.

This issue is about that. Not about one node sending the same data at the same time. That would be a rather malicious cased (or buggy software) and likely resolved more easily with a temporary ban list (I created an issue here to explain that: #2809).

But yes, we could also not accept additional same offers that come from the same node.
We might also want to put a limit (sort of rate limit but per content offer) on amount of offers (different content keys) per node.

Regarding PoW on contentid, sure it is possible and has been talked about in the past. It would be required to add this to the to the Portal spec. The issue there is always, at which value do you set it? You still want it to be fairly fast for a light device to be able to generate this and start the client.

[bhartnett]

Regarding PoW on contentid, sure it is possible and has been talked about in the past. It would be required to add this to the to the Portal spec. The issue there is always, at which value do you set it? You still want it to be fairly fast for a light device to be able to generate this and start the client.

Well the PoW would be on the nodeId rather then on contentId in this case. It would increase the cost of creating lots of nodes quickly and sending bad data into the network which would be a way around the node blacklist idea. I don't imagine it would be something as slow or difficult as is used in bitcoin. More likely something that any node can run in a few seconds perhaps. This reminds me of how password managers use slow/memory hard hash functions such as Argon2 to make it difficult to brute force and reverse the hashed value. As a user unlocking the application only takes a few seconds so not a big deal but it dramatically increase the cost for an attack.