How can Decentralized Oracle Networks deal with Inconsistent Source Attacks?
Data is inherently messy, and inconsistency is bound to occur within any data structure. This provides a major challenge for Decentralized Oracle Networks (DONs), which must determine and resolve a “true value” of external data, and achieve consensus across claims made by participating nodes in the network.
Furthermore, malicious players may add fuel to the fire, purposefully providing the network with inconsistent data; or an Inconsistent Source Attack (ISA).
What is an Inconsistent Source Attack?
A term first coined by Augur’s Joey Krug in August 2019, our definition is as follows:
an attack on a decentralized oracle network, whereby data requests are issued to query an intentionally inconsistent source — built to deliver erratic and rapidly changing values — thereby causing the network to attain inconsistent data
The community at Witnet, the Decentralized Oracle Network take this threat seriously. If honest nodes are coerced into participating in arbitrary requests and attacking nodes are able to participate in honest requests whilst avoiding their own malicious requests, then any attempt at tracking honesty within the network could be compromised.
Why perform an Inconsistent Source Attack?
We have identified 2 possible intentions behind executing an ISA:
- an attempt to undermine a network’s node reputation system, and “level the playing field”.
- an attempt to redistribute network reputation to one’s own advantage — for example, to perform a Sybil attack, or to increase one's chances of being elected to mine.
In the remainder of the article, we explore each of these potential threats and determine how they might be addressed.
Undermine a network’s node reputation system and “level the playing field”
An attacker might carry out an ISA in order to undermine the functionality of a DON’s reputation system for example in a scenario where an attacker benefits from sabotaging a rival network.
There is no “truth” in an ISA since values reported by a malicious data source are erratic and rapidly changing. This debases reputation systems, which often rely on differentiating between loyal, reputable nodes and newer, potentially dishonest nodes.
Take, for example, a consensus model to determine honesty (such as that adopted by Witnet); nodes that retrieve values in alignment with the consensus are deemed honest and rewarded with reputation, whilst those deviating from the consensus are deemed dishonest and punished by reputation slashing. During an influx of ISA requests, consensus on data reporting would be arbitrary (and potentially impossible to reach). Consequently, honest nodes will be deemed dishonest at random; their reputation slashed. With an influx of ISAs into the request pool, this could level the playing field, by lowering the reputation status of loyal, reputable nodes, whilst increasing the reputation of less reputable nodes, and thereafter effect the reward structure.
Furthermore, since many reputation mechanisms adopt a timeline aligned with frequency of requests, a glut of ISA requests could mean that reputation redistribution happens rapidly.
Solutions:
- Many reputation systems (including Witnet’s) have been deliberately designed to rapidly redistribute reputation points between active participants in the network. In Witnet’s design, reputation points cannot be sold, hoarded, or removed from the network. Reputation score does affect allocation of mining the native token, but since redistribution of reputation is so rapid, ISAs should have little effect on any node’s chance of mining. Furthermore, a built-in reputation “shelf-life” means that even if an ISA is executed, the system will naturally correct itself over time.
- Protocols can enforce an upper limit on request replication, to prevent an attacker from rapidly deploying many identical ISA requests. This makes it much more expensive to swamp the network with malicious requests, since the attacker will need to pay for a plethora of data requests.
- Protocols can enforce a request parameter limit; if a request's source is erratic, delivering results with a high standard deviation, these could be excluded from reputation redistribution.
- Running requests on any DON is financially costly, especially when doing so continuously and rapidly. Taking the above considerations into account, it’s hard to imagine any situation where a lengthly, consistent attack would be viable or worthwhile.
Redistribute network reputation to the attacker's advantage
The Witnet community has also put forward situations where an attacker might use ISAs to give them an advantage within a DON. For example:
- attackers might use ISAs to “level the playing field”, and quickly increase the reputation score of their own nodes (if they avoid participating in their own malicious requests, they may even give themselves a better reputation than other nodes)
- after adding lots of fresh nodes to the network, attackers might use ISA to quickly redistribute reputation, and “validate” their numerous nodes. In a worst-case scenario, this may give them an opportunity to perform a Sybil attack on the network.
Solutions:
- Enforcing an adequate collateralization system is a clear method to mitigate against these risks. If an attacker will suffer from price depreciation on their collateral due to their own attack, then they are disincentivized to perform it.
- A network could preempt an attack — for example, if lots of new nodes join the network in a weird timeframe, and all hold a small amount of collateral, then an attack may be imminent. The time for preempting an attack can be further lengthened by enforcing a coin age— for example, WIT tokens gained by any other means than mining cannot be used for collateral for a length of time — which gives the network time to catch and deal with possible malicious attacks.
- All nodes (or a selection of nodes) could check a data source for consistency, by probing a source several times from different IP addresses (with the use of anonymity network such as Tor).
- As in Witnet’s design, protocols can ensure that if a node is “dishonest” once during an epoch, then all the requests made by that node are discounted. This means that if there is more than one attacker on the network, then all attackers run the risk of “canceling out each other’s attacks” — i.e. they may participate in another’s ISA and be discounted from reputation redistribution for that epoch. By definition, an attacker can never know that they are the only attacker on the network.
- Participation in more vulnerable parts of a protocol could be designated only to reputable nodes, or those staking large collateral. For example, the active reputation set, which controls Witnet Bridge Interface with Ethereum is much more vulnerable to fundamental damage from a Sybil attack than Witnet’s own chain.
- Networks could blacklist nodes that seem to be acting dishonestly, such as those consistently avoiding participation in ISAs, and quickly gaining reputation points in an unusual manner.
Final thoughts
As we can see, there is no silver bullet solution to solving inconsistency within a decentralized network reliant on external data. Natural inconsistency occurs in any data ecosystem, especially when that data is retrieved from multiple sources.
As decentralized network communities mature, it’s likely they will autonomously build and integrate new solutions to deal with data inconsistency (both malicious and natural). Smarter node operators will implement software to detect gambits that the others don’t, become more profitable, avoid malicious and risky requests, and build a strong, trusted reputation on the network.
