the other day while napping on the couch a thought popped into my head:
HoloPort owners can decide which hApps to host, right? So they could start hosting a happ, but later decide to not do so any longer. Once they delete the hApp from their HP, they wouldn’t hold or serve the data anymore.
What if too many HoloPorts deleted a particular hApp at the same time?
Could they accidentally (or deliberately via a coordinated exit-attack) compromise the integrity of the DHT before the network could heal itself?
Or will there be protocols in place to prevent that? Like, a HoloPort must make sure that all data points it holds have sufficient redundancy, before they are allowed to delete a hApp.
I think some rules need to be in place to prevent this exit-attack angle.
Hm, yeah, if an app depends mainly on HoloPorts for its resilience (or even just regular old nodes too) this kind of exit attack is certainly likely. I’m not sure about the best options for this — on the one hand, you want hosts to be able to leave a network they don’t want to support, but on the other hand, you could get hosts attacking an app too, as you said. Maybe this ought to reflect in the port’s reputation or uptime?
Interesting question, especially in the anarchic world of real decentralization. I’m absolutely against taking this into account in any reputation system. On the other hand I’m also absolutely for transparency. So what if we all get to know the statistics of how many hPorts run an app, and how many, after running it have disallowed it?
AND it seems to be tantamount that no hPort should be identifiable as to location…
Here are my considerations about that, which started to become lenghty, sorry:
If there is no willingness co connect back, it depends on the resilience factor of the happ whether data is lost or not. That factor is crucial for your question if the network could heal itself fast enough.
But my first guess is, you need to control an very big portion of the network, to have a chance of causing trouble.
I would say a priori for an entry the probability to be lost is PortionOfTheNetworkLeaving^ResilienceFactor
Say the resilience factor is 10 and the attacker controls half of the network. So for any entry to be lost all 10 members holding the entry must be in control of the attacker, which is .5^10. That means about one in thousand entries is lost. With a 25% attack you break only one in a million entries. Now it depends on the happ how fatal that is…
The greatest damage i can think of that you can deal with this in the example of HoloHost is, that you do a lot of transactions, outgoing from accounts that belong to the attacker, but stay in the network, and receive some return for those transactions. Then you make the exit attack and hope that some of your transactions are lost. However the receiving member of the transaction will still have it. So you try some kind of double spend. You delete the transaction from your chain and spend the money again fast, then the receiving party does not know where to look for for the transaction you deleted.
Since your header is stored in your neighbourhood and the transaction is stored in its neighbourhood, you need the lets call it “p^r-superiority” in both…
And this would be easily preventable, by after such a noteable event of a big portion of the network leaving, waiting a bit for the heal, that the data from the member that received the first transaction spreads through the network before one accepts further transactions.
Long story short, to me it seems like an attack vector to keep in mind, but one that is in most cases unproblematic.
