Tellor is a decentralized oracle that fetches pricing data for smart contracts on Ethereum. Since Ethereum and Tellor are the future of finance and will eventually back all financial contracts, we may have some security holes if the trillion dollar financial markets migrate over to our network without us properly thinking through the security of our price feeds.
There are just three big security problems for any oracle on Ethereum:
- Ethereum under seige
- Malicious Miners/Data providers
- An attacker tries to hack or break our contracts
When we think of attackers we have to remember these are individuals that have motives. To broadly categorize the incentives that could drive one to be malicious towards an oracle provider, there are two possibilities:
- they want to profit from altering a value the oracle is providing (e.g. they own a derivative contract settling to the value) or,
- the attacker just wants to destroy the system (e.g. they’re a competitor to this system)
It’s an important distinction since the first attack vector is much easier to measure, and therefore provide security for; while the latter is a more theoretical number with a difficult to determine cost/reward analysis as it can be both subjective and abstract. It’s a difficult proposition to determine how much is it worth to person X to put person Y out of business.
There are security measures that can help prevent any attacker that is trying to break an oracle system. If you imagine our system as a theoretical bank vault that we are protecting, each piece adds something to protecting the assets in that vault. They are:
- Nondeterminism — will the stolen assets be worth anything?
- Complexity — How many locks are on the vault/ what is the procedure to open it?
- Staking — If you want to walk in the bank, you have to give us money.
- Difficulty to submit — Having a random party chosen as who gets to open the vault.
- Disinterested Parties — Let’s only let parties into the vault who don’t care about the assets located in the vault.
- Punitive measures — We’re going to call the cops and force you to leave town
Ethereum under siege
If you build an application on top of or utilizing the Ethereum network, you expect that Ethereum and it’s miners will a) not cease to exist and, b) will not spam or block your application. This is mainly out of our hands; but it’s undoubtedly in our best interest to be good citizens of the Ethereum ecosystem, assisting and monitoring the network where applicable. Whether it’s mining, looking out for blocks containing your applications’ transactions differently, or even assisting with research, helping Ethereum can go a long way. Probably the best way that this attack surface can be minimized in the future is not allowing miners to view on-chain values through privacy features. If malicious Ethereum miners can’t see what they need to modify and just have to alter everything, it becomes a much grander attack on the network, such that you hope Ethereum and other stakeholders would help deal with it.
Non-determinism — Will the stolen assets be worth anything?
Believe it or not, this is the primary means of security for Bitcoin and Ethereum alike. Just look at the costs to break them: https://www.crypto51.app/ (as of 8/30/2019, it only costs 730K and 140K to break Bitcoin and Ethereum for an hour respectively). Billion dollar systems with sub one million dollar security profiles …what gives you ask? The thing you have to realize is that even if you break Bitcoin for an hour and give yourself millions of free BTC, the network will almost certainly revert back as soon as you stop attacking it. Everyone knows this. The only reason it makes sense to break one of these chains is for something that has finality — a time that says “this is the truth.” All of the big 51% attacks take advantage of this through the feature that most exchanges have a 1 hour confirmation time. The attacker alters the network for the hour, then quickly sells them for cash (or likely a different crypto) and runs away as the network reverts and the exchange is now on the hook.
This same security features of non-determinism can and should be used for oracles. It is extremely difficult to create something fast and secure and decentralized (scalability trilemma). Once this clicks, you’ll start to understand the quixotic nature of many projects claiming or aiming to have their decentralized financial contracts settle real-time; the numbers don’t add up. The realistic option that will likely win will be slow financial contracts, with limited finality, listening to a feed of prices and/or multiple oracles. The goal of any security measure is to increase the cost or difficulty to break something, ergo creating a system one has to break in perpetuity is almost indestructible.
Complexity — How many locks are on the vault/ what is the procedure to open it?
Most chains that have been attacked by 51% attacks are all chains that utilize similar hashing algorithms to the larger chains. As one can probably guess, the miners on the more valuable chains can easily point to the smaller chain and take it over. Complexity carries a great deal of weight when it comes to preventing attacks even with non-PoW networks. If all you have to do is buy a crypto, stake it, and can now easily measure whether you have 51% of the validators, that’s a very simple model that is not hard at all to attack. If on the other hand, attackers must develop an asic, stake with an illiquid crypto, and have multiple lock-up periods and/ or confirmations necessary to even begin submitting values or withdrawing their gains, then they really have to work hard for it. Think of how the complexities of making the prison, Alcatraz, an island, acted as a major deterrent to potential escapees.
Malicious Miners/Data providers
There are several things one can do to prevent attacks from a network’s validators (or data providers): a) choose miners carefully, b) make them liable for any attacks and also c) make it difficult for them to attack and get away with it. The first piece on choice is an odd one. When you look at the reasons someone would want to attack an oracle, it’s usually for financial gain (e.g. a derivative contract settling to the price), so it should be obvious that the data providers in your system are better if they are completely disinterested in everything to do with the oracle. They should be third parties with no ties to the users or even to the holders of your tokens (who may be incentivized differently than a truly neutral third party). It’s tough to get neutral groups, but the Ethereum space is a great example of where miners are a completely different subset than the developers and even more so than the main users of applications built on Ethereum.
For the second piece, making miners stake is the answer.
Staking — If you want to walk in the bank, you have to give us money.
If a malicious miner loses all of his money when he gets caught lying, he’s not very likely to lie. Other projects have recognized this, but part of the problem comes in the fact that the miner’s gains from attacking the system might not be immediately apparent. For instance, they could be working for a competitor with a lot more to lose than even the current value of your system. In this case, the miner would care less about losing his stake.
For the last piece, to make it difficult for them to attack and get away with it, making it difficult to submit a bad value and being open about and having punitive measures can help.
Difficulty to submit — Having a random party chosen as who gets to open the vault to add/subtract.
This comes down to how hard it is for a miner to submit a bad transaction and have it be accepted by the network. One of the best examples of this is Bitcoin. Even though the ‘data providers’ (aka miners) have no stake, they have to compete ruthlessly to submit any value to the system and it is immediately apparent to every other party whether or not they are malicious.
Attacker tries to hack or break our contracts
For oracles, there are many broad-based attacks that are not performed by data submitters and can include parties that try and hack your smart contract, exploit solidity bugs, DDOS your network, or even physically go and take down your miners. It’s a different problem to try and disincentivize non-data providers, because although the incentives to attack may be the same (a competitor or a derivatives contract pointing at the oracle), you have no hold or even knowledge of this person like you would a miner; so the question now becomes: How do you deter someone from doing something?
Punitive Measures — We’re going to call the cops and force you to leave town
Besides the nondeterminism piece, most of the security measures are still about when a thief is in the bank. It should be obvious that a strong vault only goes so far if once out the door of the bank, the criminal is in the clear. Arguably most of the security of modern-day banks comes from the fact that the criminal will be hunted for years to come after any robbery attempt. Oddly, though crypto folks have a weird relationship with hacks. The dogma of “code is law” is strongly represented; for example, a large portion of the community wanted to let the DAO hacker enjoy the stolen funds. When the community values the supposed anonymity and sanctity of the initial deployment so much that any attempt to alter the state of the chain or even attempt to find and prosecute the hacker as a criminal is discouraged, it may benefit the claim of censorship resistance, but does little to discourage attacks. If one truly wants to build robust/ secure systems, the DAO and other smart contract systems should do their best to both revert unintended changes (prove non-determinism) and more so hunt down the criminal and make sure everyone knows they will do so. Oracles can pull from this security by making sure that malicious attackers are found and punished.
Tellor and other systems can and do use these security features to make oracles and their utilization by smart contracts more secure. Of course, even after this non-exhaustive overview, there’s one question that should be still in your mind: how do you determine what ‘malicious’ activity is? The quick answer is that it’s what the community deems it to be. There must be a group of people (“We the people”?), that determine what truth is on a network, and that’s a bigger question than any of this … who is the community?. The “we” that determines truth is a topic that I could write a thesis on; it at least deserves its own article.
…coming soon.
Written by Nick Fett, CTO of Tellor
If you’d like to use our oracle, don’t hesitate to reach out to us at [email protected] or on our official discord server.
