Hey everyone, thought Iād share what I know about Tellor and my perspective.
Itās a relatively simple premise - a decentralised oracle where agents are incentivised to promptly supply accurate data - but when examined in detail thereās a lot to cover, and despite how it looks the following is a short overview.
Before I get into it Iād like to cover a couple more things. Back around May earlier this year when the initial proposal was raised I had several concerns and argued against the integration. In that time the project has announced TellorX, which is a substantial upgrade to how it works. As such Iāll outline how Tellor works currently, what my concerns with that are, how TellorX affects that, and what impact that has on my concerns.
How Tellor works
At the heart of Tellor are the āminersā. Anyone can be a miner, and they do so anonymously. Miners are responsible for putting data onto the blockchain.
The following is a rough breakdown of the system with a few more numbers attached. It doesnāt cover every last detail, and itās written from memory so please correct me if any numbers or described mechanics are wrong. For reference, 1 TRB (Tellorās token) is worth ~50 USD. Anyone interested in a more accurate and more detailed breakdown can read the whitepaper documentation.
- Miners put up 500 TRB as a āstakeā
- Miners perform Proof of Work calculations (PoW), when they solve the challenge they are then eligible to submit a new data feed value. In exchange they earn TRB for doing this successfully
- The PoW is to add Sybil resistance to value submission - a miner can try to submit two values, but then they need to split their PoW power and thus reduce their chances of success accordingly
- Miners are capable of submitting wrong values, these values are capable of being considered the true value by the oracle contract
- To prevent this, submitted values are open to be disputed by anyone for a short time. A disputer puts up 400 TRB as their āstakeā
- The outcome of the dispute is determined by any interested TRB holders voting on the issue. The amount of TRB a voter had during the block the value was stored on-chain dictates their vote power
- If the miner wins, they keep their stake and collect the disputerās stake. If the disputer wins they keep their stake, and get the minerās stake
- Votes can be disputed too, with a mechanism that goes through a series of escalations that requires greater participation to conclude the vote rounds
- The feedās value is actually comprised of the median of 5 values submitted by different miners
- There are a fixed number of feeds that can be mined per ātellor blockā, and which ones are picked is determined by which feeds were last ātippedā
- Tipping a feed consists of paying TRB to make that feed higher priority, and the tip itself is dispersed as bonus rewards to the miners
Concerns
1. Observed miner behaviour deviates from financial incentive mechanism
Miners have demonstrated on several occasions a lack of care with the data they submit. Whilst you would think the threat of losing 500TRB for getting it wrong would act as a proper incentive to get it right that has not always translated into reality. The most recent incident saw miners warned in the discord server that for a specific feed the default configuration they use relies on an API that is returning out of date data, as evidenced by the timestamp included in the API response. Two days later several miners lost their stake because they continued to report objectively wrong values for this feed.
This issue is partially compounded by the mining software including the aforementioned default configuration. It was intended to serve as an example, and as such usually has only a single source API for each feed - something that means that there canāt be any error detection done. Unfortunately many miners do not customise their setup, instead relying on this default configuration and thus falling foul to any naturally occurring issues with the APIs it specifies.
2. Miners incentivised to protect stake rather than pursue true feed value
For the disputes miners are more likely to act to secure their stake than to accurately judge the values based on their merit. The Tellor teamās large multisig wallet has been required to enforce correct arbitration of disputes on some occasions. This issue is again exacerbated by the use of the default configuration mentioned above, as it means multiple miners report the wrong values and look at one another and assume theyāre correct since other miners agree with them.
3. 51% of TRB supply attack
Controlling half the TRB supply allows for the submission of false data. Tellor has argued that it is cheaper to censor the oracle by attacking Ethereum network directly rather than trying to compromise Tellor, however this hinges in part on the premise that malicious data submissions are always stopped at the dispute level. My counterargument is that smaller users will not be prepared to risk losing their dispute stake by trying to win a vote when their opponent visibly has more TRB than them by a large margin. An attacker can also split their large TRB holdings across multiple wallets to give the impression that multiple users agree with their malicious submission being valid and partially disguise the nature of their attack. User participation is also always low for disputes - some TRB will be locked up in staking pools, etc, and other users will simply not pay attention, meaning it is likely far less than 51% of the TRB supply is required for an attack.
4. PoW reduces miner quality
PoW is a needless burden, it just makes it harder for less wealthy users to participate in the core of the project. The Sybil resistance that the PoW adds is ultimately unnecessary, as a determined attacker could simply scale up their mining power at the current levels of competition.
In a similar vein the 500 TRB stake is also high and acts as a barrier to entry. This value was more reasonable when first implemented as TRB had far lower market value at that time.
5. The ātellor blockā system doesnāt scale
The limited number of feeds per ātellor blockā means poor scalability if Tellor were to significantly grow the number of projects dependent on it, with those projects competing at high tipping bids. Whilst this has a positive impact on the value of TRB, it comes at a cost to the downstream projects themselves, and ultimately some might decide itās prohibitively expensive and use an alternate oracle. Tellorās security mechanisms work best at scale, so this isnāt ideal from that perspective either.
How TellorX changes how Tellor works
As before this will be a rough synopsis of what I consider the more pertinent aspects of the TellorX upgrade. For more information I recommend reading the whitepaper.
- Removes PoW entirely, now submitting values is a gas race. Flashbots will surely play a pivotal role. The term āminerā has consequently changed to āreporterā
- Reporter stake reduced to 100 TRB
- Dispute mechanism largely the same, but the TRB used to tip a feed grants the tipper some vote power on any disputes that arise (and I think the ability to raise a dispute too)
- No limit on how many feeds can be reported at any given time
- Reported data structure moved from numbers to arbitrary byte arrays to permit greater flexibility on how the feeds work
Thoughts
The following explains how my concerns about Tellor are impacted by the changes TellorX makes:
1. Observed miner behaviour deviates from financial incentive mechanism
Tipping granting a modicum of dispute power is likely to help keep third parties engaged with validating the data feeds. Indeed, simply having dependent projects that use feeds around will help as the incidents with bad data have been for feeds that arenāt actively used by other projects. Without going into too much detail, TellorX also made reporting for a given feed āmore optionalā which means itās easier for a reporter to avoid reporting for a feed they have doubts about. This too will likely improve miner behaviour.
2. Miners incentivised to protect stake rather than pursue true feed value
Miners forming a cabal to vote together and protect their self interest becomes less viable the more there are, and with the reduced barrier of entry to reporting I would expect to see improvements here too. The other aspects discussed just above also help.
3. 51% of TRB supply attack
The specifics of the TellorX changes have little to do with this, as it can really only be mitigated by growing the marketcap of Tellor as a whole. That said, I think that the improvements that TellorX bring are a step towards growing the project and thus help somewhat in this regard.
4. PoW reduces miner quality
Since TellorX removes the PoW requirement this is no longer a concern.
It will however be interesting to see how reporters react to the gas race / gas bidding instead though. In theory reporters will only bid up to the point of profitability, and thus all have an even chance of success. We might however see deeper pockets attempt to report at a loss for a period to convince other reporters through their sustained lack of success that it isnāt worth bothering with, only to then substantially reduce their gas expenditure after having driven these competitors away. It only takes another user to spot that the cost of competing is low again for competition to resume again thoughā¦
5. The ātellor blockā system doesnāt scale
Since TellorX removes the limit on how many feeds can be reported at once this is no longer a concern.
Further thoughts
With regard to concern #3 there is one potential way of handling it thatās been raised by various people over the years. Another project by the name of Kleros aims to provide decentralised arbitration as a service - that is to say, a trustless way of having decentralised and anonymous jurors decide on the verdict of a case. Tellor could potentially use such a service to rule on contentious votes, and in doing so would make compromising the outcome harder than simply owning the greater share of the TRB supply. With this as a fall-back for disputes users would have greater confidence in their ability to win provided they are right in challenging a value, and so this would likely have a positive impact on disputes even before they escalate.
The Tellor team have been receptive to this suggestion, but obviously it is a major change and so requires a lot of thought before deciding on it. Something to keep an eye on down the line perhaps.
Another concern raised during the first proposal was feed data quality, and another AMPLer by the name of Duck produced some analysis that indicated the feed suffered from significantly higher variance compared to the two existing oracles than those two compared against one another. In the time since then there has been extensive work to improve Tellorās AMPL feed and it should in theory now report more in line with the other oracles based on results provided by the Tellor team.
(Unfortunately time is a scarce resource, and Duck has not yet had the opportunity to produce fresh analysis with the new data)
Conclusion
As mentioned in the proposal, AMPL currently relies on two oracles to supply it with the data it needs for calculating the rebase. It takes the median of the supplied data, but with only two values that median becomes the mean, and thus if either oracle feed is wrong it has a direct impact on the value used. Adding a third oracle remedies this, making it such that one oracle submitting an outlier has no impact on the value used which now becomes the middle discrete value.
On top of that, Tellor is an especially good fit for a third oracle as its structure differs greatly from the existing ones. This means that if any of them break (and given enough time it becomes a matter of when, rather than if) it is likely that they break in different ways and thus at different times, allowing for the overall continued smooth operation of AMPL itself.
Whilst my concerns still apply to the version of Tellor currently live, there are a number of significant improvements in the pipeline. TellorX is moving along and I believe is anticipated to go live towards the end of November. As described above, even after TellorX goes live some of my concerns persist, but realistically speaking it is both highly unlikely that someone will bother to attack AMPL via the oracles at this point in time or that they will be able to affect not just Tellor but also the second oracle required for an attack to actually have an effect. It is also wholly possible to use governance to undo the integration if AMPLers feel it is appropriate to do so at a later date, so we can afford to be a little more bold here and now.
All in all Iām in favour of proceeding with the integration.
