Traditional Oracles vs Alternatives

So in today’s community call we stumbled onto the subject of blockchain oracles and how it seems that the community has collectively turned a blind eye to centralization in the space (e.g. Chainlink, but there are many others).

It was here that @nullchinchilla mentioned how even using Uniswap price feeds can be a better alternative, because it is much harder to manipulate price feeds when you have to go against the free market to do it, something that resonated heavily with me and which I’d like to discuss more in depth.

Something else that was mentioned was how this “market price feed” method of obtaining prices could even be better than, say, various oracle protocols voting on price, because with the former you are trusting market forces and with the latter it comes back to non-endogenous trust (i.e. trusting that the majority of the nodes will be honest).

I know I spanned quite a few topics, but what do you guys think? Are problems with current oracles really that bad? Can we design a better, decentralized, and trustless system to replace them?

2 Likes

I don’t think the problems with Oracle have been so bad until now, but perhaps they will be magnified in the future as cryptocurrencies become more widely used in the world, when a fully decentralized, non-trusted system is needed more than ever.

The tricky thing is that oracles vs market feeds depend on whether your protocol needs accurate short-term or long-term prices.

On-chain markets like Uniswap are relatively easy to manipulate on the short term, since they tend to have less liquidity than big CEXes. If your protocol will crash and burn if, say, the WBTC/ETH exchange rate it sees is 10% off from “correct” for a few minutes, then Uniswap prices are probably not a great data source, and the centralization of something like Chainlink could be a reasonable cost to bear.

Furthermore, because blockchains are slower, stuff like MEV and frontrunning can become bigger issues if you’re using on-chain prices that lag a few minutes behind “real” prices.

But in the long term, DEX prices are very robust, something I talked about more on my post on Melmint stability. In short, long-term market manipulation is essentially impossible whether the on-chain market is highly liquid or not — the attacker still needs to outspend the “rest of the world”.

And I believe that most useful DeFi protocols (e.g. Compound) do not really need precise, up-to-date prices; something like an accurate measurement of the average exchange rate in the past 24 hours should be sufficient unless the protocol is trying to squeeze out every last bit of efficiency.


Now, I think you probably shouldn’t design on-chain protocols that rely on precise real-time data anyway. Precise time on the blockchain is extremely tricky, and even if you trust your oracle completely, there are always things like “hyper-MEV” attacks where miners colluding to delay signalling of major price movements to your contract can lead to massive attacks that benefit miners, and it’s hard to patch up every possible attack.

The “correct” way of doing “defi HFT” might be some sort of off-chain protocol tied on-chain by something like zk proofs that prevent L1 consensus participants from being able to extract any value, but then it probably just kicks the “MEV” problem to whatever L2 ordering mechanism you use.

Maybe short-term trading should actually belong on centralized exchanges, except we might have a highly competitive market of darknet, crypto-only custody-minimizing exchanges connected to users with something like payment channels. Essentially a massive peer-to-peer “OTC” market over the internet.

1 Like