The Tellor oracle is a decentralized network of reporters dedicated to providing data to various chains. Having been live for several years now, with several upgrades, Tellor has become quite the robust system, consistently driving towards decentralization and security. This article should give you a solid understanding of the current crypto-economic guarantees underlying the system and even the best ways to attack it and how much it will cost.
Looking at the best projects in the cryptosphere, ‘security’ isn’t defined by a single feature or one line of code, but by an aggregate of several attributes designed to prevent any potential misuse of the network and any tangent attack vectors. Before we jump into Tellor’s system, we’re going to clarify some pieces about blockchain security in general, notably on L1s or L2s like Ethereum that we’re built on, so we can clearly differentiate between attacks on Tellor vs attacks on the base protocol layer, both of which would shut down Tellor.
Lack of Finality
Ethereum isn’t fast. It’s faster than Bitcoin, but in general, blockchains are inherently slow compared to centralized systems. This is because in order for the state of the network to reach consensus, it is generally recommended to wait for a certain amount of confirmations. Even when the block-time is faster, waiting for several blocks to be added successfully (confirmations) will always be slower than a centralized system. Taking Ethereum for example, according to the whitepaper seven confirmations should be enough to confirm the transaction (about 2 minutes). On first pass this doesn’t sound too unreasonable, but oftentimes exchanges and others who want to be really sure will wait for over 30 confirmations!
This means that if you have an application that needs to run real time on Ethereum and will make updates according to the change in state, each change in state opens an attack vector. In the long run, you introduce a lot of risk because executing in real time can lead to unexpected or unwanted outcomes . It’s the nature of this decentralized space that we need to acknowledge more, especially in DeFi. Transactions just take time and if you want to leverage a distributed consensus network, you will have to be patient.
This is important for oracles because speed is always of concern. People want the price of X and they want it very quickly (similar to what they are used to in web 2.0 with instant connectedness, instant gratification, etc). The problem is that oracles, (even centralized ones) won’t be “finalized” to the off-chain viewer until well after it’s real time. As we’ll see with Tellor and with base layer protocols, security and time cannot be separated. There hasn’t been a solution to the “scalability trilemma” and making a secure and decentralized system comes at the price of speed.
The dreaded 51% attack
As a quick review, a 51% attack occurs when a miner/validator (or group of them) controlling more than 50% of the network can abuse the system by
- Preventing new transactions
- Reversing old transactions
- Adding new transactions that aren’t valid (e.g. printing Ether)
Basically it’s the cost to produce every block for a certain period of time; this is why the cost to 51% attack is measured in dollars/time or cost to break for 1h, 1 day, etc. This is critical for oracles (or any smart contract on Ethereum), because mining every block on Ethereum doesn’t always lead to reversions or forks. The more nefarious attack for a system is simply not allowing certain transactions to go through, namely price updates or calls to our oracle contract. The reason it’s so dangerous is that Ethereum as a whole would still function, your app would just be inaccessible and stale. This means that no matter how secure your on-chain oracle is, if the base chain you are on is controlled by one group of people, they can prevent you from updating your oracle.
If you had to guess how much it would cost to successfully perform a 51% attack on Bitcoin today, you’re probably thinking of some ridiculous amount. This is, however, not the case at all. In fact, relatively speaking, it’s quite cheap to perform a 51% attack on Bitcoin. When we think of most protocols that are built on top of layer 1 protocols, such as Bitcoin or Ethereum, you can actually come up with an estimated cost to successfully attack that protocol based on several factors, including market cap, hash rate, miner costs, block time, etc. For example, the cost to successfully conduct a 51% attack on Bitcoin’s network for one hour (or 6 blocks) in March of 2022 is about $1,512,736. This is with a market cap of $773 Billion, making the cost 0.0002% of the market cap to break Bitcoin for an hour. If you want to look at the estimated cost to break other protocols, you can visit Crypto51’s website for more information. To save you the trip, the cost to break ETH is roughly the same as BTC and the cost to break BSV for an hour is a mere $3,000. So if you have a smart contract on Ethereum that needs a price update within 5 minutes, it only costs someone $126k to completely guarantee that you don’t get an update.
Cost to Break Analysis
There are three ways to break Tellor:
- Break Ethereum or prevent contract calls to Tellor
- Vote an incorrect disputed value as correct
- Stall the Tellor system so it becomes unusable for customer needs (by disputing all values or by reporting all bad values)
The first avenue to break Tellor has been explored above in the 51% attack of a network. But the second and third paths to successfully attack and break the Tellor oracle are determined by several factors:
- P = Price of Tellor TRB tokens (assume USD)
- MC = Market Cap of Tellor
- Average time in between blocks in the Tellor system.
- SA = Staking amount for reporting (currently 100 TRB)
- VS = Voting Share of honest tokens
- CTB = Cost-to-Break
Cost to Break a Tellor Vote
For the vote, multichain Tellor has moved beyond just a simple token weighted vote. The cost to break the vote is a little bit more complicated now than just 51% of the market cap. For Tellor systems on various chains, the governance system set up is based on the input of four different stakeholders in the Tellor system:
- Token holders on that chain (H)
- Reporters (R)
- Users (U)
- The Tellor core team (T)
Assuming equal weightings (as is currently the case), the cost to break (CTB) the network is:
CTB = min(2)(CTB(H),CTB(R),CTB(U),CTB(T))
or simply the cost to break two of the four individual pieces.
To calculate out each individual piece next, we’ll start with breaking the token holder portion:
CTB(H) = VS * MC
This means that if you buy up enough votes to 51% attack the voting system, you can potentially break a dispute vote on Tellor. This is why community is everything for Tellor. It’s very important for the system to have a high percentage of its community voting in order to stave off parties trying to vote bad values through. Unfortunately for an attacker, even just breaking a simple vote doesn’t break Tellor; Tellor has a caveat of multiple dispute rounds. This means that if a vote goes in favor of the attacker, any participant can pay to challenge the vote outcome . This process goes on ad-infinitum as the system will need to repeatedly vote and hopefully get more and more votes to beat the attacker. Therefore, the only way that a party will be able to actually break Tellor is if they gain 51% of the tokens in the Tellor system and are able to break a second stakeholder vote.
CTB(R)= VS * (# Reports all time on system)
For each new report (data submission) on Tellor, the reporter is rewarded a non-transferrable “reporter token” that allows it to vote in Tellor governance. The token is non-transferrable, but a smart contract wrapper over the reporter could be used to enable transferability. If this were the case (we have yet to see any evidence of this), the cost to break this piece of the vote would be the cost to buy 51% of the reporter tokens. If the wrappers are not present, the cost to gain 51% of these values would be the cost to report 51% of the values on the network (assuming full voting by historical reporters). If the reporters do not have a high voting share, you could report less. To formalize this:
CTB(R) = Voting Share(Reporters) * (Gas cost per report * (# of reports on system+1))
For example, if at the time an attack is initiated there are 10,000 reports by voting reporters on a Tellor system, the attacker would need to report 10,001 additional reports to gain 51% of the reporter vote. As with the CTB(H) piece, you would need to maintain this ratio (reporting 1 for 1 with honest voting reporters) over the various rounds of disputes.
For the next piece, the cost to break the user set is formalized as:
CTB(U) = VS* (Cost to Bribe user set)
In the Tellor system, the governance contract can vote on a “user set”, or a list of users/protocols who rely on the Tellor system. Adding and removing new users is done through the governance system and this array of users represents 25% of the voting share. Granted, users do not have to be a part of the user set to use Tellor, however for users wishing to have a say in the governance process, they should request to join via a governance proposal. The cost to break this set is simply the cost to bribe 51% of the users in the set or to double the size of the user list adding malicious users. The latter should be unlikely given a functioning and watched system, however the first may have a price. The users in this set will have smart contracts that rely on Tellor, so they would likely not want the system to go under, however bribes can happen even if the cost is high. As with all bribe costs, it’s relatively unknown if the number is feasible or if the bribe costs are simply impossible. That said, this portion of Tellor’s governance represents a piece of governance where hopefully those using Tellor are likely to preserve it.
The last piece is the cost to break the team’s voting share:
CTB(T) = Cost to bribe/compromise Tellor Team account
This portion is pretty simple. Obviously it’s just the cost to hack or buy off the core Tellor team. Currently it represents 25% of the voting power, however the plan is to reduce this amount over time as the other user’s voting share continues to go up. Since Tellor is deployed on different chains, the governance on one-chain does not affect the governance on another chain, so the reduction of team voting share on one chain will not mean that all chains will be reduced equally. As better voting tools, delegation strategies, and community efforts come into effect, the cost to break Tellor via a voting attack will be drastically reduced.
Overall, the cost to break a vote in our mind seems both unfeasible and also unnecessary. Most protocols will use Tellor in such a way that they will not even rely on the final vote of a system to matter. They will simply use a value and if it gets disputed, they will just request it again and use the next value. For these reasons, other attack vectors may play more of a role.
Cost to Stall Tellor — Mining Bad Values
Depending on how protocols use Tellor, stalling the Tellor system is likely the most viable attack vector. Similar to breaking BTC or ETH, the cost to break Tellor via stalling is measured in time, so CTB/hr or CTB/day. If a user requires a query every 10 minutes, a party will just need to break (or stall) Tellor for 10 minutes and then they succeed in the attack. Education of users on waiting for several confirmations is key to preventing a stalling attack. Just as building things that should be realtime on Ethereum is a bad idea, it’s also a bad idea on Tellor, so making sure that projects build the right kind of projects for utilizing Tellor (and a given network in general) is the first and probably most important security measure we can take.
Here’s how we calculate the cost to break Tellor for one block. Staking (and value of the TRB token) gives the Tellor oracle network its real security. The formula is simple:
CTB/ Block = Cost of submission + Cost of staking
Cost of Submission = The gas or transaction costs on a given network. This is minimal compared to staking costs on most networks, however as speed becomes an issue, it can factor in on more expensive networks.
Cost of Staking = staking requirement. Currently on Polygon (and for other near instantaneous chains), the stake amount is 10 TRB, however this is a customizable amount for each chain. The faster the chain, the lower the stake amount can be. An important concept to note is that faster block-times on a chain mean increased security Tellor.
If you want to stall Tellor to prevent any values from getting through, you would have to report a value theoretically every block. In reality, the way it would work is that someone would put up a bad value, get disputed, put up another bad value, get disputed, and so on. Basically if at any point in the process, someone submits a good value, they would need to dispute the good value. However, assuming parties are actively monitoring and ready to dispute, reporting every block (so no one can submit a good value) is insanely expensive with Tellor’s model. A more practical choice would just be to dispute all values coming through.
Cost to Stall Tellor — Disputing All Values
The other option to stall Tellor is to simply dispute every block. The current cost to dispute is hardcoded for each Tellor deployment and then goes up based on either the number of dispute rounds for a specific dispute or the number of disputes on a given query ID:
baseFee = base dispute fee (currently 1 TRB on polygon)
openDisputes = number of open disputes on a given query ID
voteRounds = vote Round number for given dispute
if (voteRounds == 1) {
_fee = baseFee * 2**(openDisputesOnId- 1);
} else {
_fee = baseFee * 2**(voteRounds- 1);
}
_fee = min(_fee, stakeAmount)
So in plain English, the cost to dispute is the base dispute Fee, but it doubles with each open dispute on that queryID. The cost to dispute a vote result also doubles each time. The max cost of the dispute Fee however is the stake amount.
The reasoning for this is that we want initial disputes to be cheap, however if someone is trying to spam the system with disputes, they should have to pay more. Since anyone can simply buy more TRB and re-stake, the cost is capped at the stakeAmount. In the future, liquid markets for borrowing TRB will make the ability for new stakers to simply borrow (or buy) new TRB at a cheap rate since each time they would be disputed will lead to a doubling of their stake (the dispute fee goes to the wrongly disputed reporter). This incentive would mean that as long as the voting mechanism is secure, parties will rush to stake new reporters and report on that queryID in the case of a censorship via disputes.
Therefore, to simplify it, the cost to break Tellor via disputes is similar to the cost of breaking it via submitting every value:
CTB / hr= StakeAmount * blocks / hour
On Polygon for example (2 sec blocks) and assuming a $20 price (currently, this would be:
10 TRB * 20$ * 1800 blocks per hour = $360,000 / hr which puts Tellor at the same cost to censor as Ethereum a few years ago. Strategies such as using multiple queryID’s, allowing for very long delays, or even making a censorship strategy unprofitable from the users side can greatly increase the security as well.
Conclusion
So it costs a lot to break Tellor. If you’re actually talking about getting bad values on chain, it’s going to cost you in the tens of millions of dollars to break the voting and will cost you $360,000/ hr to report bad values or dispute all values for a given ID. The Tellor network is secure for participants who use the lack of finality in the system properly, allow for disputes to settle and for proper wait time(or confirmations) between reports if the system comes under attack. The best way to protect your protocol is by acknowledging its vulnerabilities and adding processes to mitigate risks. A good design and transparent, measurable security of its own and third party components are only a few of the key items to consider.
If you need data in your smart contracts and you’re thinking about using Tellor, reach out to Discord and we’d be happy to discuss the pros and cons as well as the necessary steps to building a robust data feed for your system.
