I was thinking about attacks on Holo Host, that aim to fraudulently generate holo fuel. Feel free to add your own imaginary attacks…
Can someone explain to me again, the validation rules of fuel transactions?
Say a transaction A to B.
If everyone is honest, the transaction is stored in its neighbourhood in the DHT, plus the updated headers are stored in the neighbourhoods of A and B respectively, correct?
From where to where are links added?
I would expect at least the following things to happen:
-A checks the integrity of B’s chain.
-A checks with B’s neighbourhood whether B’s header is up to date.
-B does the same for A.
-B additionally audits all transactions A received, checking whether they are stored correctly in their neighbourhoods.
-The neighbourhood of the transaction does the same as B.
-The neighbourhood of A checks the integrity of A, when it updates its header
-The neighbourhood of B checks the integrity of B, when it updates its header
What happens if some of the information cannot be found?
Especially in the audit step, say there is a past transaction C to A, that you do not find in the DHT. Who do you blame?
thanks for picking that up
In the devcamp we talked about, how get_entry is (only) relatively ok and get_links is pretty unsafe (cause it returns a set and the likelyhood of different validators getting different answers there is pretty high).
So what if
a) the data of the entry that was pushed to the DHT did not yet propagate to the nodes that you ask, cause you expect them to hold it?
b) the Nodes are currently all offline because the redundance factor was chosen too low
c) there was a network partition and the data was lost, or not yet repropagated properly, so that you do not find it in the fraction of the DHT that is available to you.
I see how all of these cases are not the norm, but would not they contradict the certainty of “not being found means not existing or being invalid”? And it can get problematic, if people create warrants cause of this?
(Furthermore, if the possibility exists, that you did not receive all the data and legitly create a warrant because of that, then people could just pretend not having received everything and cast an attack by excessive warrant placement. The plausible deniability of doing wrong is problematic…)
these are exceptionally relevant to the very beginning of the network developments stages. the dHapp devs hold a large weight of responsibility in this regard.
the good news is that each membrane has plenty of flexibility to code in failsafes and even theoretically provide emergency shut-offs.
i believe that for smaller and/or newer applications, transitionary designs will need to be made initially to help launch completely decentralized applications. one solution the team is developing can be illustrated by the concept of ‘bridging’ DNA.
mostly, Holo inevitably relies on node participation, which is highly incentivized. it should be very unlikely that a well written dHapp is unable to find enough hosts, but if for whatever reason the node threshold is unacceptable / not functional there are still many options for the developer, such as the ability to designate admin who are responsible for the DHT. this would result in a pseudo-centralized environment, but keep in mind that rules can be put in place to phase that structure out over time. also i think its important for the community to recognize that decentralization is not always the most appropriate solution for everything and Holo can provide many relevant use cases for centralized permission-based networks.
