Proposal to Add Tellor as an Oracle (part deux)

Greetings AMPL governance community, Tellor team here again, reaching out with an update on your feedback and hopefully making a good case to include us in the oracle!

This post summarizes ACCP-4 30, a proposal to add Tellor as an additional oracle to the Ampleforth system, and focuses on the reasoning behind it. Please refer to the actual proposal for more details.

Summary

The goal of adding Tellor is to further decentralize the protocol and create a more robust, censorship-resistant price feed. Tellor is a decentralized oracle that uses a network of staked miners who compete to fetch off-chain data and place it on-chain.

Abstract

We propose that Ampleforth will use Tellor to bring on two values: the AMPL/USD value and the US Personal Consumption Expenditures (a key measure of inflation). The values will be medianized with the current price feeds provided by Chainlink and the Ampleforth team.

Motivation

In order for AMPL to do its daily “rebase,” it requires a price of AMPL/USD on-chain so that the protocol knows how to adjust the supply. It doesn’t peg directly to the dollar, but rather an inflation-adjusted dollar. Using the US Personal Consumption Expenditures Price Index, it can track the value of the US dollar versus costs. This means that AMPL will still hold a stable value versus goods and services, even if the US dollar collapses in value. There is no reliance on traditional banks or lenders of last resort to guarantee liquidity.

As an oracle that specializes in decentralization and censorship-resistance, we believe adding Tellor into the system greatly helps Ampleforth’s own efforts of decentralization and adds further security and robustness to the price feed.

Additionally, AMPL currently relies on only two feeds (the AMPL team’s feed and LINK). Since, there is currently just an average taken of the two, any one oracle provider can maliciously attack the system. By adding a third oracle, the AMPL system will be able to take a median of the three values, meaning that you would need 2 of the 3 oracles to be corrupted in order to break the system.

Rationale

In order for the Ampleforth community to fulfill their vision as a decentralized financial primitive, the censorship resistance of the protocol must be the first and foremost priority. The communities of Tellor and Ampleforth have similar drives towards and beliefs as to what constitutes a decentralized protocol and the ability of the two projects to work together will help further the entire space.

Tellor’s system is a completely on-chain data feed that can be accessed by Ampleforth smart contracts. The design for integrating Tellor into Ampleforth includes creating an adaptor that pulls values from Tellor and pushes them to Ampleforth’s oracle medianizer, and configuring this adaptor as a new provider in the medianizer.

Tellor added the AMPL/USD price calculation in mid 2020 and has been updating it since and they have also created scripts for automating the price updates before they are needed by the AMPL system. More recently (summer of ‘21), we have been working directly with the AMPL team to ensure good data quality of the AMPL prices pushed on-chain. Over the past few weeks, the Tellor feed has been closer to AMPL’s than LINK and is done in a completely open source and censorship-resistant manner.

5 Likes

Tellor.io doesnt have an ssl certificate. That should be renewed. Otherwise adding additional oracles is always great

2 Likes

It does make sense to add multiple oracles. The reason is simple; you make projects more decentralized by having more nodes, more participants, which is the case with price feed as well, but in this case participants are oracles. This way we are actually making a more abstract decentralization, with multiple levels. I like the idea!

As for Tellor itself, it’s completely decentralized, and with Tellor X at our doors, lowering the entry price, it will further increase the potential number of validators.

4 Likes

Absolutely makes sense to add Tellor as another oracle. They are far more decentralized than Chainlink is as well. Don’t get me wrong. I love chainlink, just stating a fact about Tellor being much more decentralized. I’m ecstatic to see TellorX is in audit. While auditing slows the launch, I 1000% agree that it is a necessary step & I believe it will produce tangible concerns & actionable steps to code that can be addressed before it goes live. I also believe Tellor’s philosophy’s as a project align very well with the Ampleforth communities philosophies. Lastly, I believe the integration of Tellor to Ampleforth would be great for both protocols.

1 Like

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.

6 Likes


Updated AMPL comparison

I don’t know where you are getting your data from but it doesn’t align with the on-chain data (see below). Where did you source that from?


Here is the recent on-chain data (thanks to ImagineBeingAtComputers#0001 on discord for scraping it) of the three oracles reporting a 24 hr VWAP.


In this chart I simulated what an actual rebase feed from Tellor would look like by choosing the on-chain data points closest to the AMPL oracle report.


This graph represents the variance of each oracle with respect to the AMPL oracle for each simulated rebase.

You’ll notice that the Chainlink oracle didn’t provide data for a good chunk of time recently. I’m still not clear on why this is. The Tellor data appears to lag significantly behind both other oracles. Given the extreme variance this could cause in an AMPL rebase if one of the others fails to report, I recommend against proceeding with Tellor integration until they either fix the lag or -as Mandalore suggested on discord- set up a recurring tip around the same time as the AMPL and Chainlink oracles report to prove that their data isn’t actually lagging and it’s just not being tipped at the right time. If anyone wants the source data I posted a CSV in the governance channel of the Discord.

2 Likes

Hi all,

I’ve occasionally posted on the Discord and formed my opinion from the discussion there and on this forum. I would advise anyone coming to this post to read Fiddlekins’s summary in this thread. I believe that it’s accurate and reflects my impressions.

Overall, I’m persuaded that the state of oracles in AMPL needs improvement. For example, as Duck proposed, a Keeper to call the Chainlink oracle or a look under the hood of the AMPL oracle. Although the AMPL team are, at now, the people with the most at stake in AMPL, they’re still human. For the dangers of this, look at Tellor’s attempt at a derivatives platfrom or wrench attacks more generally.

However, I’m opposed to a Tellor integration at this current time.

Current faults with Tellor. Although this isn’t a complete list, there’s the possibility of self-disputing, which allows an attacker to reclaim their stake if their attack fails, the current centralisation of Tellor miners and the fact that Binance controls 35% of the Tellor supply. Although these problems are solvable, the Tellor team haven’t publicly acknowledged these problems and moved to meaningfully solve them. Although they did deploy a parachute function to break up any ETH wallet which holds =>51% of the Tellor supply, this is trivial to defeat with two wallets which contain 25.5% of the Tellor supply. The Tellor team have also improved the quality of their data feeds relative to the AMPL native oracle. From Ducc’s recent post, there appear to still be faults with the data.

Future faults with Tellor. When Tellor was launched, it would have been impossible to predict these current problems. Now that Tellor has been used in the wild, exploits have been found and some of them have been patched. Over enough time, eventually I would come around to supporting an integration with Tellor as all the faults were solved.
However, Tellor is updating to an entirely new model called TellorX. Fiddlekins has speculated about the possible use of Flashbots but that’s been a sentence. There has been no serious attempt, both with Tellor in it’s current state or TellorX to wargame an attack. If Tellor is integrated with AMPL and then moves to TellorX, the AMPL ecosystem will be the bug bounty for TellorX.

It’s obvious from the PRL projects that they believe AMPL’s current state is good enough to build some extremely impressive projects and I agree with their assessment. I think that it’s fair to describe AMPL as a potential USD-killer. I admire the mission and dedication of the Tellor community. I just don’t think that AMPL is an appropriate testing ground for their products. With a couple of years of battle-testing and integrations, as Chainlink had to do before integrating with AMPL, I would be a lot more receptive.

tl;dr - get more experience but in principle, yes

Afterthought: If the Tellor team could return to Daxia and Daxia saw wide use, I’d take that as sufficient credentials for Tellor.

2 Likes

Hey @tsar_impersonator , thanks for the post! I think you make some good points, but to just clarify the things about Tellor:

  • self-disputing isn’t guaranteed (it’s a race, so assuming you want to attack AMPL around the rebase, you’d have to hope no one slashes you for a couple hours, so not likely).
  • On the tokens. CEX’s do suck. This is a common problem with any coin and we’re trying to address some of it with TellorX (giving some users/reporters more say), but yeah, if Binance wants to attack Tellor it would be hard. In our own defence, other coins are usually this high held by the team (cough LINK), and more so if CEX’s in general want to fuck us all over it’s probably a doomsday scenario for anything not completely decentralized (which Tellor definitely is a notch up in that category from the other two guys).
    -And on MEV, it’s actually part of the design! Wrote an article here about how it’s inevitable in oracles: https://medium.com/@nfett/on-oracle-extractable-value-f6c7a0d64af5. So same as arb bots for AMPL, you should try and get the miners on board in my mind!

But I can tell you took some time to think about it, and respect the criticism that we just need more testing. It’s a hard one to ever respond to or in space ever quite get enough of. We’ve been pushing values on chain since Aug ‘19 and there have been hiccups, but it’s getting more robust each day and that’ s all we can continue to do. From a fan of AMPL though, the current design is basically beholden to two separate parties (either one could really mess up the rebase if they attacked it) and you guys would be better adding the number 1 as a third oracle for a median vs the current design. Tellor adds some nice characteristics of decentralization that the other two don’t have, so it works well.

And lastly…man can’t you believe remember Daxia! Awesome to hear and unlikely given our team’s current workload, but maybe in the future!

1 Like