CryptoToit
commented
4 years ago Hey Justin, great write up!
Couple questions: 1- Which "Price Networks (PN)" are currently available from the ChainLink network? 2- Do you have an available list? 3- Does these cover our current list of Synths? 4- If not, what would it take to 'get' a new PN up and running? It seems that it would require at least 14 independent nodes contributing to a specific PN.
My concern wrt the questions above is that we end up with 70% of Synths reading price from the ChainLink network and still have to sit with a centralised Oracle for years. I'm thinking of when we start getting to synths like AAPL, MSFT, FB, GOOGL etc.
I do however agree and like the phased approach of migrating specific synths over one at a time.
Cheers
jjgonecrypto
JohannEid
ghost
ChainLinkGod
Arthur0x
RewKang
dongzhuoyao
Problem
The current Synthetix (SNX) oracle is a centralized point of failure. It runs constantly, reading in prices from a range of real-world pricing services and updates the
ExchangeRatescontract (currently at 0x99a46c4 at this time) with the latest prices for all of the assets underlying each of our synths (priced inUSD).The code for the SNX oracle is closed-source and centralized. It is closed in order to prevent bots from calculating differences in prices off-chain and profiting from delays in Ethereum transaction latency. It is centralized and managed by the Synthetix team, and while vigorously monitored and maintained, has significant centralization risk, with users forced to trust the team, their processes and integrity.
Proposal
To migrate to a decentralized oracle solution for all of our synths. The most robust solution available with the highest level of community engagement is the Chainlink ecosystem of pricing networks.
We propose to enter into agreement with Chainlink, upgrading our
ExchangeRatescontract to using their pricing networks gradually.However, in order to prevent front-running of decentralized oracle prices, there is a strict dependency on Synthetix first refactoring the
exchange()functionality to a new queuing mechanism (more details below).Terminology
The Chainlink ecosystem uses certain language around oracles and pricing that makes sense to incorporate into the Synthetix nomenclature.
oracleis an instance of theirOraclecontract that supplies a price for a single asset (ETHUSD,BTCUSDorAUDUSDsay). Each oracle is supported by anodeon the backend, who is paid inLINKfor their services.aggregatoris an instance of theirAggregatorcontract which aggregates requests to all oracles in its list, yielding a single aggregate price (the public propertycurrentAnsweris the price multiplied by some power of 10 for decimal support) for the asset.networkis a collection of oracles that provide the same price. It is served by a singleAggregatorthat can be read on-chainFor example, here is a visualization of the ETHUSD aggregation network: https://eth-usd-aggregator.chain.link/
networkthat provides theETHUSDpriceoraclesserving the network.Aggregatorcontract which aggregates these oracles on-chain, yielding a single readable price for ETHUSD: 0x79febf6. The current price isAggregator.currentAnswer(which is the current market price ofETHUSDmultiplied by1e8for decimal support). The last block number used for any oracle update isupdatedHeight. As per the contract'sminimumResponsesproperty, only when14oracles have returned a price for a request will theAggregatorupdate thecurrentAnswerandupdatedHeight.Implementation
To work with the Chainlink ecosystem, our
ExchangeRatescontract would need to be refactored.Unlike our current oracle which pushes multiple prices updates simultaneously, Chainlink uses a one-price-per-contract approach for modularity and reuse purposes. We agree with this approach, though some light refactoring will be required so that our
ExchangeRatescontract knows where to find the price for each synth. It will need a mapping of synth keys to a ChainlinkAggregatorfor that pricing network (e.g.mapping(bytes32=>address)).For inverted synths - such as
iETH,iBTCet al - we propose reading the regular rate from theAggregatorand then inverting it in ourExchangeRatescontract, as we do currently.Cost Basis
Currently the Synthetix Foundation is paying both the API costs for real world pricing of assets and the gas costs of updating the
ExchangeRatescontract on-chain.Moving towards decentralized oracles will offload these costs from Synthetix directly. Synthetix and Chainlink are working together to find a reasonable cost basis for ongoing upkeep of the various pricing networks for all synthetic assets used.
Considerations
Pricing networks
Since inception, Synthetix has been fairly flexible with trying out different synths. This will be marginally more difficult under a decentralized system as a price network needs to form and be available on mainnet for every new synth added to the ecosystem. This will mean more lead time for adding new synths to the system.
Index synths
For indexed synths - such as sCEX and the upcoming sDEFI which are a weighted basket of number of prices - we propose working with Chainlink nodes to do the weighted calculations off-chain and provide the pricing of our indexes on-chain directly. The alternative would be a pricing network for every price inside each index (if it didn't exist already), which would be too costly.
Concerns
Front-running
The current Synthetix system tackles front-running of SNX oracle updates by limiting how much Gwei an
exchangecan be performed with (see SIP-12). This works as the centralized SNX oracle can be guaranteed to ensure all oracle updates are performed with higher Gwei than the aforementioned limit.With Chainlink's network of decentralized oracles, this cannot be guaranteed. However with a large number of oracles per price network, and the
Aggregatortaking the median of a minimum number of updates, front running a price network becomes marginally more complex.Frequency of updates
The SNX oracle runs regularly and updates prices on-chain, ensuring that small price movements are tracked. If an on-chain price deviates by more than the current exchange fee (currently
0.5%but lowering back to0.3%soon), we update it, preventing bots from taking advantage of the difference between on-chain and real-world pricing (what we refer to as "technical front-running"). Morever, the SNX oracle ensures that every price is updated at least once an hour - and if any price is more than 3 hours stale (configurable viaExchangeRates.rateStalePeriod), the system freezes.Chainlink's pricing networks will target on a
1%price deviation and a heartbeat of approximately twice a day. While the slower heartbeat can be incorporated into our system, the larger price deviation would expose the system to an unacceptable amount of "technical front-running".Dependencies
Thus, in order to migrate to the decentralized oracle system of Chainlink and not expose the system to front-running attacks mentioned above, a different mechanism of exchanging is required. What we propose is to overhaul the
exchange()functionality inside Synthetix. Instead of exchanges happening immediately, they would be placed into a queue to be processed FIFO once prices for both the source and destination synths has been received. This introduces its own challenges (such as who pays the gas), but has the added benefit of supporting limit orders on-chain.This queuing mechanism will be a prerequisite to migrating to a decentralized oracle service. Once applied, we can begin the transition to Chainlink's pricing networks, one synth at a time.