Caching data has 2 main advantages:
It avoids DDOS attacks on the group of vaults managing a piece of data. Everything that is free will be abused by attackers. As GET commands are free, we can be sure that someday an army of bots will try to disrupt a section by using this operation. Imagine N1 clients controlled by an attacker, each client being able to issue N2 GET commands per second. Without caching the load on the target section is N1 * N2 requests to handle per second. With caching the load is removed from the target section and split among the vaults directly connected to the clients of the attacker, each one handling only N2 requests by second.
Popular data is returned more rapidly to clients. The result is the inverse of standard web sites on legacy internet for which the more popular will be the slower, due to the heavy load on the web site. On safe network this load is removed from the sections holding the data and split among the caching nodes.
The problem is that caching is applied only on Immutable Data and not on Mutable Data, nor on non-existing data.
At first glance it seems that caching cannot be applied on this kind of data, precisely because it is mutable so a copy of this kind of data in a vault may not be in phase with the source data anymore. But sometimes this data doesn’t change very often (for example the directory containing the files of a static web site) and it is a waste of resource to fetch this kind of data from the source vault every time.
I propose to add mutable data in the cache of vaults and define a global expiration delay to the cached copies of mutable data, say for example 10 minutes.
Most of the time when browsing a site, the user doesn’t need the latest information up to the minute. For very specific needs of more accurate information I propose a new kind of get that is not free: the user must pay a small fee to ensure that the request fetches the information from the source group storing the mutable data.
This way the DDOS attack is avoided in both cases:
With free get because data is cached
With paid gets because the small fee multiplied by the N1 * N2 requests per second is too costly to sustain for the attacker.
To be clear, what I propose is not 2 classes of mutable data but 2 kinds of get commands that can be applied on every mutable data and using free or paid gets is the choice of the user.
Remark: I am only talking of mutable data; immutable data remains free and DDOS attacks are mitigated with caching
Another kind of DDOS attack is to request a chunk of data that doesn’t exist. To mitigate it, the information that an address doesn’t contain data should be cached. Not only this address but also the biggest range of free space containing it (to also mitigate an attacker targeting a group by trying millions/billions of addresses in a small range). This special structure is similar to a prefix.
The global expiration delay mentioned for mutable data is also applicable to these cached prefixes. The 2 kinds of gets are also applicable when a cached prefix indicates that data doesn’t exist:
With free gets then fetch is stopped at the caching vault.
With paid gets fetch is resumed towards the group managing the address