Oracle offline detection with multi collateral about interbtc HOT 4 CLOSED

I think we'll have to operate under the assumptions that:

1. We will allow only a few currencies as collateral where we can reliable get price data for
2. Not all oracles might provide price data for all assets, e.g., I can imagine that if we add staking derivatives, only Polkadot specific oracles might provide prices for that whereas other oracles might lag behind

My current preference is option 2 since it's the most simple to implement and under the assumption that we have at least one oracle submitting prices for each asset, this works.

On a related note, there are many reasons why an oracle may no longer provide a particular price feed - e.g. attack on the origin network. How do we plan to deprecate a currency? This might be worth splitting into a separate research ticket.

You mean an attack on the oracle network or an attack on the currency we want to get the prices for?

from interbtc.

What is the difference between solution 1 and 2? In 1, you'd just fail the setter if not all currencies are in included and in 2 you'd allow partial setting but you'd halt if one of them is outdated. Is that correct?

My main concern is around the time when we add a new collateral currency. I think once live, the oracles would not do partial updates, but I am concerned that if we add a new collateral currency and oracles are not catching up in time that we halt the entire functionality of the chain.

On the other hand, solution 3 adds a lot of complexity on the code side that would increase with every new asset we are adding (increasing the diff for a runtime upgrade).

I am currently leaning towards solution 2 whereby we need to ensure out-of-band that our oracles are up-to-date as it is a lot simpler than solution 3 and seem to be less impactful on future runtime upgrades/slightly better for performance as well.

But I would also like to hear what @alexeiZamyatin and @gregdhill are thinking.

from interbtc.

What is the difference between solution 1 and 2? In 1, you'd just fail the setter if not all currencies are in included and in 2 you'd allow partial setting but you'd halt if one of them is outdated. Is that correct?

Yea in solution 1 it'd be mandatory for all oracles to supply all exchange rates at the same time, otherwise feed_values returns an error. This way you don't need separate offline detection per currency - either all are outdated or none are. In the second solution, you allow the omission of currencies in feed_values, so you have to do offline detection per currency. When a single currency is considered offline, this solution marks all of them as offline (such that most of the system can remain unchanged).

My main concern is around the time when we add a new collateral currency.

We could implement some activation logic. I.e. right after adding a new currency, oracles can start including the new exchange rates in their submissions, but the currency does not become active until a certain number of vaults include the new exchange rate. Until the activation, vaults can not register with the currency, and an insufficient number of inclusions does not trigger an oracle offline event.

The number of required active oracle feeds for 'activation' could be higher than the minimum number required to be considered offline. E.g. activate only when it is included by 3 oracles, but don't trigger 'oracle offline' unless the number of oracles is strictly less than 2.

from interbtc.

Guess it could prove tricky to enforce that all oracles have all price feeds, but I would certainly prefer that to the additional complexity introduced in the other strategy.

On a related note, there are many reasons why an oracle may no longer provide a particular price feed - e.g. attack on the origin network. How do we plan to deprecate a currency? This might be worth splitting into a separate research ticket.

from interbtc.