Off-Chain Computation Ideas

[joepetrowski]

A few ideas for off-chain computation:

• Tools for computationally heavy tasks (e.g. Fourier transforms)
• Oracles (will be better once http requests are merged)
• Supply chain (oracle for sensor data + off-chain compute, store result on chain. example: accelerometer measuring shock/vibration in transit, computing FFT off chain, storing ASD (just two short arrays as opposed to long time series) on chain)

cc @tomusdrw

[4meta5]

• could be cool to make a price oracle that accounted for price slippage; so it would take the T::AccountId's balanceOf (amount staked) as an input and then estimate liquidity conditions (from exchanges) to calculate the price if the given account needed to immediately exit and sell

the justification is that most protocols benefit from instant withdrawals and fast exit (like a dao, or plasma chain)) so it would be cool to provide a tool to check the price based on amount (to improve on the current view of price which doesn't account for the slippage that occurs with large sales/purchases)

[joepetrowski]

could be cool to make a price oracle that accounted for price slippage; so it would take the T::AccountId's balanceOf (amount staked) as an input and then estimate liquidity conditions (from exchanges) to calculate the price if the given account needed to immediately exit and sell

the justification is that most protocols benefit from instant withdrawals and fast exit (like a dao, or plasma chain)) so it would be cool to provide a tool to check the price based on amount (to improve on the current view of price which doesn't account for the slippage that occurs with large sales/purchases)

The problem with this is that block times are much greater than order-book latency, so a trading strategy would be to create an inefficiency by making a strong order book to give the illusion of liquidity, watching for unstaking events, and cancelling orders as soon as the first dust order was filled, removing the liquidity so the actual fill is at a much worse rate. All this could happen in an interval much shorter than a single block.

[4meta5]

could be cool to make a price oracle that accounted for price slippage; so it would take the T::AccountId's balanceOf (amount staked) as an input and then estimate liquidity conditions (from exchanges) to calculate the price if the given account needed to immediately exit and sell
the justification is that most protocols benefit from instant withdrawals and fast exit (like a dao, or plasma chain)) so it would be cool to provide a tool to check the price based on amount (to improve on the current view of price which doesn't account for the slippage that occurs with large sales/purchases)

The problem with this is that block times are much greater than order-book latency, so a trading strategy would be to create an inefficiency by making a strong order book to give the illusion of liquidity, watching for unstaking events, and cancelling orders as soon as the first dust order was filled, removing the liquidity so the actual fill is at a much worse rate. All this could happen in an interval much shorter than a single block.

In that case, could create a DEX that enforces some order-book latency greater than the block time. Also, could use a consensus mechanism that trades consistency for availability -- for faster block times with a some relatively higher probability of reversion. I need to understand rhododendron better, but what if we could get block times below order-book latency -- would that patch this attack?

Also, we're going to need a price oracle either way so I think this is a better approach than ignoring liquidity as an input for price for sale/purchase. What we could do is aggregate data from multiple exchanges and use some randomness to make this unpredictable as to make the oracle more difficult to game in the way you described.

[joepetrowski]

what if we could get block times below order-book latency -- would that patch this attack?

Not really possible, for example, a lot of exchanges run on AWS. If you host your trading bot in the same data center as the exchange, latency for placing/cancelling orders is intra-building and only requires a single, one-way message. Latency for consensus is worldwide and involves multiple messages between peers.

[JoshOrndorff]

Offchain workers have been documented in both the recipes and main Substrate repo. I'm closing this as we switch to the new CMS repo. Feel free to open specific actionable issues about any of these ideas in the new repo.