Tellor is live and better than ever. We’ve laid out a solid plan with tellor360 for removing any lingering issues of governance, token centralization, and team dependence and the protocol is well on its way to changing the space in a big way. As we continue to mature and move to countless chains, there are still a few issues that we need to solve. As you can imagine, these aren’t issues with the code or the token, but rather just off-chain best practices, tools, and tangential points of centralization that need to be addressed in any decentralized ecosystem worth its salt.
For any decentralized protocol, the first step to achieving censorship resistance and decentralization is that you must be technically decentralized. It sounds simple, but it rarely is. This is where a project removes admin keys, multi-sigs, or reliance on a single point of failure (e.g. a single API or off-chain user). Most don’t even get past this step, but this is actually just the first of many steps to becoming truly decentralized.
After removing all technical barriers, you need to be practically decentralized. If there’s governance, who holds the majority of the voting shares? Is it the team? Is it a handful of centralized exchanges? If there is no governance, how are upgrades handled? How many nodes do you have, how are they distributed both globally and ideologically? Are most of them hosted by a handful of services or on a few cloud providers? How many validators do you have? Is there active competition/ monitoring? Is it just a handful of people and do others have the technical know-how to compete even if they wanted to?
These are hard questions for any system. But without addressing them, it’s all just for show. They matter for L1’s and there’s a series of questions that matter for oracles too and we’re just starting to address them.
Decentralizing the Data Specs
The data specifications are one of the most critical pieces of any oracle and it has nothing to do without how you get data on-chain. It’s the answer to the question, “What data are you looking for?”.
To give an example, if someone wants the price of Bitcoin, this could mean a lot of different things. What API’s do you want? Just one is always a bad idea, and so you’re stuck with either a vague “valid BTC price determined by our willingness to dispute you” or you could pick a median of certain exchanges. This latter can work, but there’s a huge issue….where does that list live and how do you update it?
As in any decentralized system, a random validator should be able to fufill the request. They get the request, and now they need to know what the hell it means.
Currently we host these lists on our github, but we know that’s not ideal. We need to move to a system where the users can oversee the data and we need to create a system or at least a general rough consensus about what the data specs represent and how to change it.
For tellor, we plan on making or data more decentralized in three ways:
- IPFS hosted, no longer on github
- Allowing user or group governance of a given data spec
- Creation of documented standard feed definitions for most common queries
To give examples, a user for a certain piece of data will be able to go to IPFS to look up details. Regristry contracts can be created that point from a given piece of data to the IPFS link (e.g. BTC price points to a list of exchanges to medianize from). This way if you want to update the exchanges, the registry can be governed by whoever owns the rights (e.g. a multsig, a user, or just no one if you don’t want upgradeability of the dataspec).
Minimizing governance is a huge goal of Tellor, but educating and creating tools for users to own their data and make their systems more resilient is essential.
Testing and Mocking Disputes
There’s a weird game theory that happens with oracles and any system that rewards people for catching bad actors, no one does it in the long run. To explain, if a system is such that dishonest are parties are accurately monitored and punished if they misbehave, no one will misbehave. Then if no one misbehaves, no one will run monitors…. It’s a hard problem. Ideally you hope that the users and other reporters will monitor, but if people can be lazy, most of the time they will.
The usability of Tellor, especially with regards to disputes is still in the process of getting better. If someone starts disputing every value coming through Tellor, it makes sense for parties to ramp up submissions and make it prohibitively expensive for an attacker to succeed. This all works in game theory, but getting the software prepared and waiting for a scenario is something that we’re continuing to work on.
This is why Tellor is building dispute monitors, making it a default when reporting, and we even plan to mock disputes live on mainnets (e.g. submit bad data on purpose) throughout the system to make sure that the monitors are live and incentivized.
Usability
Docs can always get better. There can always be more examples, more edge cases drawn out, and better articles/ videos on how Tellor works and how to use it. We’re going to continue the process of growing and expanding our content. We’ll keep vigilant on stack exchange. We’re going to be in every mentor group we can and get feedback from anyone willing to give it.
And docs aside, Tellor can do any data on any chain, but people still love seeing working code and examples. We always had talked about bringing snapshot votes on chain, but when we built the snapshotOracle, it all of a sudden clicked and people realized it was possible and started asking about it. This is why we’re going to be funding more feeds, launching on more chains, and creating more examples. From derivatives protocols, lotteries, bridges, stable coins, insurance, and more; if you have an idea and it shows the capability, we’ll build it and get it out there. In the process of bootstrapping usage, we’ve been learning a lot about how users actually use the system and it’s helped us make it better and will continue to do so.
Education and Best Practices
Probably the hardest part about being a piece of infrastructure for smart contracts is that you have to see all the mistakes people make in implementing their smart contracts. From relying on super fast price feeds with no fallbacks, having minimal oracle testing, or simply relying on a single API endpoint, there are so many easy fixes for users of Tellor (or any oracle) and it’s just an issue with education. We’ve done talks, written articles, and made videos, but we’ve got to do more. In the same way that solidity development has grown throughout the years, oracle usage has to mature as well. How do we get auditors to step up? How do we get users to actually take the time to think about the hard questions vs just using an out of the box centralized solution with an admin key to fix it? These are hard problems and we’re working with ourselves and the ADO on creating best practices and even providing audits to projects looking to implement an oracle and are curious on how to make it better.
—
As you can tell there’s still a lot more work to do, but we move fast and purposefully.
Come help us build Tellor.
