From 90dce02406c9846da2e0c75d3e9e7c2234cbcc8b Mon Sep 17 00:00:00 2001 From: Matt Luongo Date: Thu, 26 Sep 2019 01:10:35 -0400 Subject: [PATCH] Moved the price discovery docs and begin a rewrite Refs #254. --- docs/bonding/index.adoc | 2 +- docs/index.adoc | 2 +- .../index.adoc | 28 +++++----- docs/price-discovery/on-price-feeds.adoc | 56 +++++++++++++++++++ 4 files changed, 72 insertions(+), 16 deletions(-) rename docs/{price-oracle => price-discovery}/index.adoc (81%) create mode 100644 docs/price-discovery/on-price-feeds.adoc diff --git a/docs/bonding/index.adoc b/docs/bonding/index.adoc index 1c3e6a855..2baea7e8b 100644 --- a/docs/bonding/index.adoc +++ b/docs/bonding/index.adoc @@ -130,7 +130,7 @@ between the signing bond collateral and BTC. In concrete terms, that means the price of ETH to BTC. Due to only needing prices for a single pair of assets, tBTC will initially use a simple -<>. +<>. == Undercollateralization diff --git a/docs/index.adoc b/docs/index.adoc index 3a868d175..b28c1468a 100644 --- a/docs/index.adoc +++ b/docs/index.adoc @@ -251,7 +251,7 @@ include::deposits/index.adoc[leveloffset=+2] include::bonding/index.adoc[leveloffset=+2] -include::price-oracle/index.adoc[leveloffset=+2] +include::price-discovery/index.adoc[leveloffset=+2] include::minting/index.adoc[leveloffset=+2] diff --git a/docs/price-oracle/index.adoc b/docs/price-discovery/index.adoc similarity index 81% rename from docs/price-oracle/index.adoc rename to docs/price-discovery/index.adoc index 2b15c6326..f0478ed73 100644 --- a/docs/price-oracle/index.adoc +++ b/docs/price-discovery/index.adoc @@ -1,12 +1,12 @@ [env.theorem] :toc: macro -[#price-oracle] -= Price Oracle +[#price-discovery] += Price Discovery ifndef::tbtc[toc::[]] -The price oracle is an integral part of the system, ensuring sufficient collateral backs all tBTC signers. We model the oracle after the https://developer.makerdao.com/feeds/[USD price feeds from MakerDAO], operated initially by a single trusted actor and later governed by the ecosystem. +The price oracle is an integral part of the system, ensuring sufficient collateral backs all tBTC signers. We model the oracle after the https://developer.makerdao.com/feeds/[USD price feeds from MakerDAO], operated initially by a single trusted actor and later governed by the ecosystem. The minimal price feed design is specified completely by the interface below: @@ -29,22 +29,22 @@ This mitigates unnecessary recomputations by maintainers for price changes below == Price encoding -A bitcoin has 8 decimal places, the smallest unit being a satoshi, meaning 100 000 000 satoshis = 1 bitcoin. -An ether by contrast, has 18 decimal places, the smallest unit being a wei, meaning -1 000 000 000 000 000 000 wei = 1 ether. +A bitcoin has 8 decimal places, the smallest unit being a satoshi, meaning 100 000 000 satoshis = 1 bitcoin. +An ether by contrast, has 18 decimal places, the smallest unit being a wei, meaning +1 000 000 000 000 000 000 wei = 1 ether. -To express the price of bitcoin relative to ether, we must use a ratio of the number of wei to a satoshi. -A simple design is to use `x` wei : 1 satoshi. Hence, for a call to `getPrice` when 32.32 ETH : 1 BTC (Jun 2019), -the value 323 200 000 000 wei is returned. +To express the price of bitcoin relative to ether, we must use a ratio of the number of wei to a satoshi. +A simple design is to use `x` wei : 1 satoshi. Hence, for a call to `getPrice` when 32.32 ETH : 1 BTC (Jun 2019), +the value 323 200 000 000 wei is returned. -However, if 1 wei is worth more than 1 sat, then the price can no longer be accurately encoded. This scenario of a 'flippening', -when 1 ether becomes worth 10,000,000,000x as much as 1 bitcoin, we find unlikely in the very short-term. -Rather than prematurely optimize, incorporating a 2 integer ratio of `x` wei to `y` satoshi and changing the call semantics, +However, if 1 wei is worth more than 1 sat, then the price can no longer be accurately encoded. This scenario of a 'flippening', +when 1 ether becomes worth 10,000,000,000x as much as 1 bitcoin, we find unlikely in the very short-term. +Rather than prematurely optimize, incorporating a 2 integer ratio of `x` wei to `y` satoshi and changing the call semantics, we leave this as a future exercise for governance. == Future design The price oracle is integral to tBTC's security and in the future, will be principally governed by -the tBTC ecosystem. The first upgrades will focus on incorporating a medianizer model from MakerDAO, where +the tBTC ecosystem. The first upgrades will focus on incorporating a medianizer model from MakerDAO, where multiple price feeds are voted in and the median price is calculated from their reports. Other on-chain price signals like -decentralized exchanges (DEX's) and liquidity pools (Uniswap) are being considered. \ No newline at end of file +decentralized exchanges (DEX's) and liquidity pools (Uniswap) are being considered. diff --git a/docs/price-discovery/on-price-feeds.adoc b/docs/price-discovery/on-price-feeds.adoc new file mode 100644 index 000000000..1f54f4eab --- /dev/null +++ b/docs/price-discovery/on-price-feeds.adoc @@ -0,0 +1,56 @@ += On price feeds + +Price feeds are a difficult subject in decentralized systems. + +Price isn't a global phenomenon -- it's local to a transaction's participants, +and stems from their subjective beliefs about the value of an asset and the +current and future conditions of a market. + +At first glance, atop the fractured and subjective nature of price, we layer an +additional conundrum -- the long-discussed "oracle problem". How can a group of +pseudonymous actors be convinced to report the trust in a decentralized system, +when they have a strong incentive to lie? + +Addressing these issues in the general case is far outside the scope of this +document. Instead, we can discuss a few common approaches and how they perform +in the context of a system like tBTC. + +There are three common approaches to bringing price data onto a blockchain like +Ethereum + +1. Trusted oracles. If an entity or fixed group of entities can be trusted, + publishing trusted price data is simple. + +2. Schelling point games. These schemes make use of a large number of + participants with difficulty coordinating. Each participant submits their + version of the "truth", and those that differ significantly from the + plurality are punished, while those that reported with the herd are rewarded. + Truthcoin, Augur, Witnet, and UMA have all done interesting work in this + space; the Witnet team has written + https://medium.com/witnet/on-oracles-and-schelling-points-2a1807c29b73[an accessible primer]. + +3. Market-based schemes. One of the surest ways to make price data accessible + to a chain is to bring trade execution onto that chain, using schemes like + batched auctions. + +In a system built to maintain a censorship-resistant supply peg, a trusted +oracle requirement is deeply dissatisfying. A system is only as decentralized as +it's most easily captured component; and a trusted price feed, even one that +mixes data from many + +Schelling point games are an attractive alternative to trusted feeds. A +Schelling point price feed enables permissionless participation, can better +resist outside capture and censorship, + +The downside of a Schelling game approach is what Paul Sztorc calls "parasitic +contracts". Expressive host chains enable "games outside the game" -- incentives +that can warp honest reporting in Schelling games. Growing the size and money at +risk of a reporter set can combat this issue; but when the security of an entire +peg is at stake, imagining a large enough financial interest in honest price +discovery is difficult. + +The last approach, utilizing on-chain markets, can enable direct price data on +a smart contract chain. The devil, however, is in the details -- how does a +scheme prevent miner tampering? How about fake volume and wash trades meant to +manipulate a price? Market-based schemes need to be built to a particular use +case, and are only as resilient as the participation in the market.