Tellor’s security protocol is a staked PoW system which requires five miner submissions before adding an official value on-chain. Each miner is required to be staked to be allowed to submit the Proof-Of-Work solution along with the requested data value and the first five miners are rewarded.
This article will attempt to explain some of the thinking behind this design and our reasoning for answering a few frequently asked questions such as: Why do you need PoW if miners are staked? How did you determine the reward structure for the five miners? Why do you need 5 miners? Why not use mining and “longest chain?”
Why not a blockchain (order blocks and have one miner win and build on the longest chain)?
In a traditional PoW blockchain system like Bitcoin or Ethereum, it is relatively easy to tell when a malicious miner is active (no double spends, no giving yourself free coins, etc.). In our system however, it cannot be programmatically determined what a correct value is (we would need an oracle for our oracle). Hence, Tellor must be flexible enough to allow for a range of ambiguous values. The problem though is that we still want the property of traditional blockchains where multiple miners validate each block (blocks are validated by subsequent blocks (the longest chain principle)). Unfortunately, we cannot accomplish this in the same way Bitcoin or Ethereum does. The reason is that each block on Bitcoin is actually secured by every block built on top of it (since the previous hash and current block’s validation ensures almost “unambiguously” there are no double spenders and as blocks are added it approximates certainty). Therefore, one block is not secure, but 6 blocks is very secure (this is why 51% attacks are measured in cost to break for a certain time period (number of blocks)). Tellor, instead of reaching a higher degree of certainty with the longest chain (numerous miners build and validate each subsequent block), has multiple miners confirm each block, one block at a time and provides a mechanism for disputing misreported values.
Why 5 miners?
In traditional blockchain systems, the success of malicious (or simply competing) chains can be measured by how many blocks have been reorganized in the system. To explain, if a malicious miner attacks Bitcoin and mines 3 blocks in a row, the next block will still not build on top of it. Honest miners will instead ‘reorg’ or reorganize the blockchain by 3 blocks and take out the blocks mined by the bad actor. In this sense, one can never break Bitcoin; you can only break it for a certain amount of time.
In Bitcoin, the longest chain reorg was four.[1] In Ethereum it was 7, but the short block times actually make it much less severe. In our system, attacking our chain with 5 miners is similar to breaking a traditional system for 3 blocks; maliciously getting 3 out of 5 is sufficient to enter a malicious value. In the 10 years of Bitcoin, 3 or 4 length reorgs happened 6 times.
In our system however, we have additional security even above the longest chain security mechanism due to our staking requirement. Our security, unlike Bitcoin, does not rely 100% on PoW. Whereas the cost to attack Bitcoin for any number of blocks is defined as:
[Cost to 51% attack] x number of blocksour security model with staking can be defined as the:
[Cost to 51% attack for n/2 submissions + n/2* staking amount]Assuming an array X of n submitted values, we must take the median value of array X as our official value to ensure that an attacker must break at least n/2 submissions to be successful.
The question now is how does one reward each miner? Is it more beneficial to reward the median miner more than the rest? And how does one system structure the payments. We have identified five potential structures for organizing this reward:
- Winner take All (Median position)
- Position (to Median) based reward
- All parties receive equal rewards
- Time of Submission based rewards
Attributes to Avoid in Reward Mechanism
There are two main problems we want to avoid when structuring our reward mechanisms:
- Race Conditions
- Mirroring
Race conditions occur when a user can see a pending transaction on Ethereum and then submit their own transaction with a higher gas price to front run this transaction. The main problem with race conditions in Tellor is that users will waste all of the potential mining reward on gas to outbid one another. When this happens, the security of our system goes down because as the expected return (mining reward minus gas costs) decreases, so does the PoW difficulty of our system.
Mirroring is when parties copy the previous submission’s value. So if you have 5 miners submitting the price of BTC, you want to avoid everyone just copying the first miner’s submission. The goal of the five separate miners is for each miner to independently check the value and report it. When mirroring occurs, there is only one miner who is actually checking the value, thus reducing your n number of miners securing your system to one.
Winner take All (Median position)
The first question we should ask is whether we should reward the median more than the others.
Unfortunately, a higher payout for the median value encourages race conditions and mirroring.
The crux of the argument here is that parties will compete to submit the median by using increased gas cost on the Ethereum network by fundamentally front running other submissions. This exact same issue has been explored within the idea of an on-chain orderbook. [2], [3]
The easiest of the potential structures to see this with is the Winner take All (Median position) scenario. In this case, you have 4 solutions with no reward and the median with all the reward. Parties will be incentivized to solve the Proof-of-Work and then wait for 4 other submissions so that they can see the values submitted and then use the exact median value. Using some game theory, we can extrapolate that if all parties do this, no one will even submit first. All parties will simply solve all 5 proof-of-work challenges on various miners and then seek to submit them at the same time. Besides now going from the security of 5 miners to 1, the other issue is that this party can be front run. As the miner is trying to submit his 5 transactions in order, other miners will try to jump in as the 5th miner in the transaction order using a high gas price. Since the original winning miner knows this, he is willing to spend a very high amount of gas to ensure that he pushes his transaction through. The maximum amount of gas being equal to just under the total profit expected from the mining reward. Higher gas prices indicate that Tellor security is being paid to Ethereum miners rather than Tellor miners and our system is less secure.
Position (to Median) based reward
This same race condition occurs as well with any system where the median is rewarded greater than the uncles (non-median values). To attempt to formulate this:
p(W) — probability party can visualize ALL n submissions (so if you have 1 solved, you need to see values for all other 4. If you have 2 solved, it needs to see 3) and win the race to submit their own transaction. The probability, once one is solved, that you can see and can win the race to submit your transaction. It goes down over time since other parties are more likely to be involved in the race.
x = n — number of solved solutions held by the ‘same’ miner
nP = number of proof-of-work solutions at given moment
mR = main reward
uR[t] = uncle reward at position t
So race conditions exist where:
p(W) * (mR + (nP-1) * uR[t]) > nP * uR[t]
Once you solve 1, you wait until:
p(W) * (mR ) < nP * uR
To explain, if the expected profit from trying to visualize the incoming transactions and win the gas race is greater than the uncle reward you will likely get, you have an incentive to wait and compete in the race. This will always lead to the last party winning, but in good news, it will be the median of the previous four.
Another unintended consequence of rewarding the median value with the highest payout is that it leads to inaccurate values. Say the value of BTC is 100. If the first two miners are malicious and pick 0, but the second two miners pick 100 (the correct value), the final submitter is actually incentivized to pick 99. It might be tough for a Tellor vote to say it’s a ‘bad’ value, but it’s definitely not the most correct value.
All parties receive equal rewards
Distributing rewards equally among the 5 miners leads to less severe race conditions. Miners are no longer trying to maximize their reward by trying to target the median value. The incentive in this structure is to solve the PoW and submit it ASAP (which is good).
THIS IS THE ONLY ONE THAT PREVENTS RACE CONDITIONS.
So the next question is, what are they willing to do to be first? And the answer is mirroring.
Mirroring is the biggest problem with rewarding everyone equally. What happens is that basically whoever sets the value first will have his answer copied by everyone.
Unless, the first miner is malicious, then the parties will NOT want to mirror or they will lose their stake. But the question is; Does the time lost in checking the mirrored value affect your payout greater than just accepting a slash occasionally? If Rewards lost from not mirroring > stake => then mirroring will occur.
Unfortunately, mirroring occurs when bad actors are absent. The only way that mirroring can be mitigated is by introducing a bad actor. If it is fairly certain that malicious values are being submitted, then it is in the miners’ best interests to check that the first value seems plausible or get the value themselves.
Time of Submission based rewards
Rewarding miners by decreasing their reward based on the submission time or order would magnify both race conditions and mirroring. Miners would be attempting to get though and pay the maximum amount of gas to Ethereum miners to be one of the first five. Furthermore, they would be more likely to mirror the first miner to save time and get a higher reward. The first miner would still be incentivized to get the value since they are still risking their stake.
Why do you need PoW if miners are staked?
PoW provides randomness for selecting the miners acts as a filter and provides security by diversifying the parties securing the system. Since the median is used as the official value, to break PoW, a party would be required to successfully submit three of the five values, making it less likely and more expensive to do a 51% attack. Additionally, a pure decentralized PoS system suffers from two fundamental challenges: how does one randomly select the miners, and how does one prevent Sybil attacks. PoW helps to address both of these problems. In addition (and mainly), since we utilize voting (the number of tokens held as our ultimate security), this outlay to acquire the tokens does not help with the mining piece. In a pure PoS example, costs to break are defined along one vertical, which is cost to acquire tokens. Our system adds in a different element which is the cost to acquire hashpower This security model is seen in other systems too, as miners tend to be agnostic third parties, likely not the largest holders of your coin.
Conclusion
Based on the scenarios above we concluded that:
- Higher payout for median value encourages race conditions and mirroring
- Rewarding the median leads to bad values
- When all miners are rewarded equally race conditions are reduced, but mirroring remains
- Mirroring occurs when bad actors are absent
The official value will still be the median value but all miners will receive equal rewards. If we just take the 1st submitted value the cost of attack for POW would decrease. Race conditions will still occur but with less severity than when the median value is paid a higher reward. In addition, since we anticipate mirroring to be a problem and the only way to prevent it is to actually submit fake values on occasion to keep the system honest we plan to police the environment by submitting fake values, similar to Truebit.[4] [1] https://bitcoin.stackexchange.com/questions/3343/what-is-the-longest-blockchain-fork-that-has-been-orphaned-to-date/4638
[2] https://blog.0xproject.com/front-running-griefing-and-the-perils-of-virtual-settlement-part-1-8554ab283e97 [3] https://pdaian.com/flashboys2.pdf [4] https://truebit.io/
