My point was not to bring up AMMs as a solution (they aren’t) but to suggest how broad the solution space could be without having a clear winner. IMHO, if there is a large solution space and there is no obvious good-enough-for-everyone solution, it’s best for a low level of the stack to stay agnostic and let higher levels (contracts/dapps/L2s) decide what is appropriate for their use case.
Since we seem to be concerned primarily with fiat price oracle and my example doesn’t work for that, I’ll offer an alternative to make my point (but please don’t attack the solution, it’s purpose is only to indicate the non-trivial extend of the solution space): Maintain a list of credible sources and have validators relay authenticated messages from them. This could be straight-up signed messages like in the case of Coinbase’s friendly new oracles, on-chain state for on-chain sources, or recorded authenticated HTTPS transmissions. The consensus rules would verify authenticity. Happy to discuss the pros and cons of this approach, but, again, that is not really the point. More alternatives have also been brought up by others above (trusted council like MKR, prediction markets).
I’m just wondering why the proposed solution in particular is being singled out for beacon-chain-consensus status when the solution space seems to me an active area of innovation with no clear winner. It’s also not entirely clear to me what we gain by promoting it to the consensus layer, though I see a lot of the drawbacks articulated by others above.
Also agreed It will be interesting to see the design space evolve, especially as DeFi grows and puts more pressure on the oracles.
The suggestion is less of a “solution” than an unopinionated low-level data feed. The raw price points can be mixed-and-matched with other price sources to build hybrids that explore a wider design space. It aims to strictly provide more power and flexibility for oracle designers, and spur innovation.
The raw price feed suggestion was singled out because it is the most low-level and generic primitive (in a similar vein to an EVM opcode) I could think of.
We already have similar functioning oracles in SKALE used for internal purposes.
SKALE V2 will have embedded programmable Oracles very much similar to what Justin described but PROGRAMMABLE in Solidity. You will be able to connect to any internet source of info. We believe Oracles are a feature and not a product.
As far as Unswap is concerned, I would not recommend anyone using at as a secure Oracle since it can be trivially manipulated. It can only be used as rough data.
the implementation is very hacky and only serves the purpose to show that this is possible… in future work we’ll focus on answering some other questions this raises (e.g. incentivisation to avoid nodes reporting that there was no response, language and VM structures to support the mechanism)
I’m strongly against it for a bunch of reasons but one of the main ones is that updating which price feeds to use is a governance hassle that will have to be undergone every year or two, which infringes upon the security of the base layer.
Governance is an attack vector, and I’m also skeptical of hard forks as a defence. Hence I’m in favour of further ossification of the base layer and less control by ACD or so-called community governance. This proposal does not allow for that.
