3

I'm a bit concerned that oracles used professionally would need a lot of disk space.

The blockchain is not growing rapidly since if a contract didn't change its state, the next blocks state tree just links to the state of its ancestor.

But using oracles with very frequently changing states (e.g. price tickers, wheather data,...), wouldn't they effectively spam the blockchain?

of course with only very few applications using oracles, this wouldn't be a problem - but if you imagine some financial products running on the blockchain I expect a huge traffic?

Is this something that could be solved with sharding?

I highly appreciate your input!

3

Edmund Edgar here, I run Reality Keys.

If people are doing a lot of transactions based on this data then it's not necessarily going to be huge compared to the data generated in the actual transactions. If you're using the pattern where you send data to a contract then people read it from there, that'll take some storage, but it can probably be freed up later once contracts that use it have settled.

However, sending large quantities of data to the blockchain and having somebody read it from there isn't the only way to do it. The way Reality Keys work is that we publish data off-chain, with a signature, and anyone who wants to use it in their contract can grab the signed data from our website and send it to their contract, which can check the signature then discard the data as soon as it's used it.

You can take this to another level with various economic hacks; For example, if you know that your counterparty can ultimately get the data from us if they need to and extract the payment whether you like it or not, you can set up an incentive mechanism - either a bond or just reputation - so that in most cases, you don't actually need to get the data from us at all: The counterparties recognize when they owe something to the other and just send each other money.

This is also the thinking behind state channels (in the bitcoin world the famous one is the proposed Lightning Network) that you'll probably want to use for fast trading at high volumes: By making it possible to enforce the settlement of a debt on the blockchain, you remove the need to actually do it.

  • Interesting approach and thanks for the clarification. I guess data-friendly decentralized data-streams (e.g. Augur) should work off-chain then as well, regarding your answer? Also so far I only read about real-time and future data, but how can one get historical data if needed? – FelixA Jul 19 '16 at 13:53
  • As I understand the current Augur design seems like it's going to use a lot of storage all over the place, although again it can be freed after use: You don't just have the result of the reporting, you have all the different reporters' reports. I doubt this design will be used for high-frequency data, as it looks very expensive and slow. But yes, a decentralized reporting system probably could do a lot of its work off-chain, if sharding doesn't make that moot. I don't know what you'd need a trusted source of historical data for but all the same considerations apply. – Edmund Edgar Jul 19 '16 at 21:39
  • Yeah I guess all systems built on the concept of Schelling Points are really expensive if not used off-chain. Well, there are a couple of use cases, e.g. I can think of a smart contract that aims to calculate the future exchange rate for bitcoin based on the rates of the last years. Then people could make automated bets against my smart contract. But yeah, kind of exotic – FelixA Jul 20 '16 at 19:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.