Overview
Types of attacks on Tellor
Tellor is a robust decentralized oracle that’s been live for more than three years. Over that time, we’ve been hacked, attacked, audited, and beat up more times than we can count, but with that, we’ve learnt a lot about the attack vectors present in the system and how to use the oracle in a secure manner. Rather than doing a yellow paper style analysis of attack vectors though, (which you can find a bit of here: https://tellor.io/security-201/ ) this article will just talk about the attack vectors and what you as a user can do to protect yourself.
For those that don’t know, there are two main types of attacks on a protocol using tellor, system wide attacks (attacking the core tellor functions) vs implementation attacks (attacking tellor due to how the protocol is using tellor). This article will cover the following subset:
System wide attacks
- griefing / censoring
- standard attack – submitting bad values
- network level censorship
Implementation issues
- usage delay
Time Traveling via disputes
- tight read windows
- underlying data quality issues
Attacks and Solutions
Standard attack – submitting bad values
attack – This is the base scenario for attack on the tellor system. An attacker stakes TRB and reports a bad price (or lots of them).
solution – The good news is that the system was literally set up with this problem in mind. The solution is that it comes down to monitoring and waiting. Any bad value pushed through in the tellor system can be disputed. The only caveat to this working perfectly is that you (or other self-interested individuals) need to see the bad value and submit a dispute on that value. So you need to make sure you’re waiting for bots and monitors to detect and dispute malicious values. How long to wait? Well that’s up to you. Is 2 seconds enough? Probably not. Is 12 hours? Almost certainly, but there’s a lot of nuances about how easy the data is to verify and how many reporters are monitoring it. Finding that sweet spot given your/ tellor’s monitoring tools is the hard part. The other part is disputing. Disputing costs TRB. Be sure to have some set aside in case a slew of bad values gets through.
Griefing / Censoring
attack – Censoring tellor is simple, you just dispute every good value that comes through. A common “attack vector” we hear is that “tellor reports once an hour on price X, so therefore it would only cost me one stake amount per hour to shut down the tellor network”. This “attack vector” is only slightly more delusional than the conclusion stemming from the common conversation:
Them:”how many reporters do you have?”
Us: “X”
Them: Oh so X * stakeAmount for disputes and I shut down tellor?”
solution – The way the tellor system works is that the dispute fee is 10% of the stake amount for the first dispute, 20%, 40%, 80% for the second through fourth, and then 100% thereafter. This means that it quickly costs one stake per value to dispute it. The truth is that as long as your protocol can handle being delayed at the cost of 1 stake per block, you’re just fine. The main flaw in the reasoning of our “attacker” comes in the presumption of no outside actors looking to save the system or benefit from the attack. When a good value is disputed on tellor, this is actually a profitable opportunity for any reporter. Assuming the voting mechanism is not broken, anyone who simply submits a good value will double their TRB in 2 days(the voting period on the dispute). This means that in order for this attack analysis to hold, you would need all of the reporters and participants in the attacked system to not realize this. This is a similar assumption as saying you could throw a uniswap pool and expect no one to see an arbitrage opportunity.
This said, there are things that you as a protocol can do to ensure liveness. Maintaining a healthy number of reporters on your price feed, keeping some TRB handy to stake and report yourself, as well as education for your community on what to do in case of an attack are all things that make this attack vector unprofitable and a nice opportunity for guardians in the system to make some extra cash.
Network level censorship
attack – Believe it or not, on shorter time horizons, blockchains aren’t really the most secure thing. This was painfully obvious with proof-of-work, as you’d oftentimes have to wait a large number of blocks to actually confirm a transaction (e.g. exchange withdrawals). With proof-of-stake this has largely been solved, but there are still risks for oracle users due to manipulation by validators(or miners). The first one to know on EVM networks is that some validators can be in charge of multiple blocks in a row. This means that if you use a uniswap twap, it can be thrown almost effortlessly by the validator. And the same goes with tellor. If you don’t allow a long enough time for disputes, malicious validators can submit bad values and prevent calls to dispute the transaction. And malicious validators aren’t the only network level attack. Censorship in the form of DoS attack can happen when gas prices can rise to such levels that transaction times are unstable and/or prohibitively expensive. This can cause delays in price feeds and even worse delays in disputes.
solution – You have to be very careful which networks you interact with. Knowing the details of the finality, who runs validators/ sequencers, and ultimately whether they’ll care about what you’re doing (censorship attack) or have the ability to profit off your system. There’s no magic bullet here, but a robust and decentralized chain should have been consideration numero uno, even before your obvious oracle choice of tellor.
Not waiting for disputes
attack – When parties use tellor, they need to be aware that tellor is optimistic. Any value can be put on-chain. The tellor community and network does, but you too need to monitor and dispute bad values. You’re financially incentivized to make this happen, but an easy attack is in play when a protocol does not wait long enough for disputes.
solution – wait longer. It’s easy but also tough to be patient. You like your protocol to be fast and real time, but the truth of the matter is that blockchains are slower than tradfi databases and competing on the “real time” feel is a losers game. The scalability trilemma holds for oracles too and sacrificing security and/or decentralization for speed is something you should work hard to avoid. If you really need fast, the usage of monitors is key. Tellor provides several options here, but ultimately you’ll want to have back ups and things that don’t use the data as the reporters (that way api failures don’t hit both monitor/reporter).
Time Traveling via disputes
attack – Let’s say the prices for ETH/USD are 100,102,105,99,98,97… all pushed by Tellor and read by your protocol. You wait for disputes, things work great, but the problem is that an attacker could just dispute 97,98,99 and then get to 105. Granted 105 was a good price at the time, but the dispute optionality may have unintended consequences if the price of ETH moves rapidly or your protocol can get wrecked by this behavior.
solution – there’s a few easy ones here. Just make sure your protocol a) doesn’t let people go back in time, and b) makes sure that values aren’t too old. Making this read window though () can be tough in and of itself.
Tight read window
attack – A read window is the time difference between waitTime (e.g. at least 15 minutes old) and tooOld (e.g. 4 hours old). So for an attack example, let’s say you’re a tellor expert just made sure your data is 5 minutes old and no more than 20 minutes old. The problem…someone just disputes every value for those five minutes and freezes your system.
solution – This is an implementation problem. If your system stalls if you don’t get an update, there’s a problem. The tellor protocol is easily censored for short periods of time, so you need to expect it. That said, monitoring and getting ready to submit values every block if this attack starts (you double your TRB every submission with the false dispute), can be a great way to negate this attack by making it unprofitable.
Underlying data quality issues
attack – can you actually manipulate or censor the underlying data? If so, you could be in trouble. The usual problem here is that someone will ask for a price feed on an illiquid token. Oftentimes this token will only trade on uniswap and have very little liquidity. Obviously tellor doesn’t really help here. Iit will then be very easy to simply manipulate the pool and you’ll be stuck with a “bad” price that’s actually accurate from the oracle’s standpoint.
solution – the solution to bad data quality is to just choose better data. Multiple API’s, the ability to calculate without an API, and/or making sure your underlying asset isn’t susceptible to manipulation. In our example, this means using twaps or vwaps for price feeds, adding in outlier protection in your smart contract, and just being able to be patient if data sources go down. There’s no magic bullet here, but thinking through and documenting the points of centralization and fragility are key in creating a robust system.
Conclusion
Decentralization is hard. Attacks are possible and expected. There’s no magic bullet and trying to ensure liveness and that no small group of individuals owns your data is hard to get right. That said, its worth it. What we’re building and continuing to improve is the radical vision that crypto visionaries have had for the past decade. We’ll continue to work on making it harder to break and we’ll continue to document how to build truly unstoppable applications.
