De Risking Oracle Sources
4 Layers of protection for building robust oracles on PegNet
TL;DR PegNet oracles relies on:
1. Honest miners.
2. Miners rely on honest data aggregators.
3. Data aggregators rely on honest exchanges.
4. Exchanges rely on correct user trading data.
This proposal looks at all four levels of where data is generated by users, recorded on exchanges, aggregated into APIs and read by miners.
Level 1: Miners / Aligned Incentives
The first and most important security of oracles comes from a globally distributed community of miners reporting honest prices. As mining power grows on PegNet this level has been secured with hundreds of thousands of machines and incentivized pools / miners earning PEG every block. But the market cap of PEG is still small relative to other projects and the cost to conduct an attack low enough that it has been done.
Weighting PoW & PoS
First, there is still a need for more hashpower on the network.
Second, by using proofs from miners in the past the PegNet can increase the cost of an attack over time as the miner must can a valid signature from many blocks previous.
Third, users Staking pAssets or PEG can be included in oracle price record submissions and any difference in the PoW & PoS could be a reason to pause conversions of the effected pAsset or PEG that has a price spike up or down.
The data that is read by the miners is typically from aggregated sources such as CoinMarketCap.com, CoinCap.io, ForexAPI, and PegNetMarketCap.com. Those aggregators are pulling from a variety of independent exchanges where the cryptos, fiats, and metals listed on PegNet are traded. Let’s examine how these layers can also be made stronger.
Level 2: The Risk of Faulty Data From An Aggregator Provided to Miners
The second level of risk and the most obvious risk is from one of the aggregated data sources (such as CoinMarketCap.com, CoinCap.io) providing miners with faulty pricing. This faulty pricing would lead to negative outcomes such as those converting pAssets getting incorrect conversion rates, either too high or too low. If a bad actor manipulated an aggregated data source and knew what the price was going to be they could gain un justified additional pAssets for example.
FOSEP — (Faulty Oracle Source Exclusion Parameter)
A proposed solution to this risk vector is for PegNetd to poll all enabled datasources for a pAsset, and compare results from multiple data provider API’s to protect against bad prices being published on chain. If one datasource returns a price out of the defined tolerance band (ex: 100%) in comparison with the other sources, it will not allow that source’s price to be included in that block. This can be described as a “validation check” to ensure a primary datasource for any asset (ex: PNMC) is not compromised. This keeps bad prices from being published on chain, and closes the exploit loop if one were able to manipulate a primary datasource.
This is a solution that can be implemented at a miner level.
Level 3: The Risk of Bad Exchange API Data Provided To An Aggregator
The third layer of risk comes from the exchange data itself that is reported to the data aggregator. Even in the case when the aggregator is averaging prices across many sources, if one exchange reports extremely high prices or extremely high volumes than the average can still be massively effected.
For example if there are two exchanges being averaged. The first reporting $1.00 price for pUSD and $10,000 of volume per block (good data) and the second exchange reporting $100.00 for pUSD and $1,000,000 of volume per block (bad data) then the resulting average is $1,010,000 divided by two exchanges equals: $505,000
The solution here is similar Faulty Oracle Source Exclusion Parameter described above except at this level it is implemented by the aggregator.
In fact PegNetMarketCap.com has already implemented a system that watching for erroneous data and excludes it from being passed along to miners. So any miner using PegNetMarketCap.com for oracle prices will be protected from this bad data being sent to them when requesting PEG and pAsset price data.
Level 4: The risk of a bad actor on an exchange
The forth layer of risk comes from bad actors on an exchange conducting for example wash trading in order to massively inflate trading volumes and thus passing along erroneous data up the chain exchange to aggregator to miner.
This is the most difficult bad data to eliminate but exchanges that strive to do so will be more likely to attract PegNet trading pairs and for aggregators to include their data in their own reporting.
Conclusion: 4 Layers of protection
If the user data is corrupted, manipulated, or otherwise faked, ideally the exchanges will catch that fact and not report the bad data from their API.
If the exchange reports bad data via their API, next the aggregator has a chance to detect bad data and disregard it from their API.
If the miner’s PegNetd software sees bad data from the aggregator it has the opportunity to detect it and disregard it before submitting their oracle price records to the chain.
If the PegNet software detects bad data on chain, ultimately conversions should be paused for the effected pAsset or PEG and thus prevent the error from effecting user conversions in the system.
