Talk:Blockchain oracle

This article is rated Stub-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Cryptocurrency Low‑importance This article is within the scope of WikiProject Cryptocurrency, a collaborative effort to improve the coverage of cryptocurrency on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptocurrencyWikipedia:WikiProject CryptocurrencyTemplate:WikiProject CryptocurrencyWikiProject Cryptocurrency articles Low This article has been rated as Low-importance on the importance scale.

@Komonzia: This is what the source says (I have re-typed it, the possible typos are my responsibility):

Development of a smart contract becomes a very time-consuming process, which naturally increases the number of critical errors ... it is impossible to change the smart contract or stop its operation ... oracle ... ensures reliable implementation by supplying trusted information

My reading of this is simple:

1. Real life is complex, programs handling it will have bugs
2. Software bugs on the chain are impossible to fix. In real life, altering can be done, say, fraudulent bitcoin trades are sometimes reversed (by forcing new records to be entered, of course) so I used the word "hard" instead of "impossible"
3. Therefore, there is a benefit in encapsulation as much complexity as possible in the oracle that is outside the blockchain, thus is mutable and can be debugged and fixed later when the smart contract is already running.

This was the reasoning behind the text you removed ("since the on-chain critical errors are hard to fix."). I think that this text is correct and should be restored.

I disagree with your reasoning that the facts needed for the contract do not exist on-chain, and without it, only on-chain information can be referred to. From the abstract point of view, some information has to be fed into the contract anyhow to trigger its execution. For example, to buy bitcoins at certain price, a real-time signal has to be fed somewhere. This signal can be either a single bit "condition met" or multibit market price, with no difference at the theoretical level (say, Solidity allows functions to accept pretty complex inputs). The (huge) real-life difference is that for the multibit input much more code will be required to validate this input, so there will be a much higher probability of a software bug. This bug in the contract will be unfixable, if the same code is moved into oracle, it can be fixed, since the oracle is not on the blockchain. This is IMHO the primary reason for the use of oracles: they allow to move the potential points of failure to the place where the bugs can actually be fixed. Викидим (talk) 08:07, 25 July 2024 (UTC)[reply]

Okay, my impression was more that Solidity (and frameworks of the same class) are not capable of getting complex information with purely on-chain code - for example, the current president, or the outcome of a football match - things that don't have anything to do with blockchains or exchange rates (unless there is a blockchain input from an oracle somewhere for these real-world outcomes).

How about this?

"A blockchain oracle is a third-party service for smart contracts. Oracles provide trusted information based on the outside-world sources to the on-blockchain smart contracts. An oracle typically encapsulates the real-world complexity outside of the blockchain. This provides different engineering advantages, chiefly that critical errors and potential points of failures are easier to mitigate off-chain than on-chain."

--Komonzia (talk) 07:41, 26 July 2024 (UTC)[reply]

Sounds perfect. Викидим (talk) 07:57, 26 July 2024 (UTC)[reply]

Cool, I've added it into the article now. Thank you for providing that explanation. Komonzia (talk) 12:23, 26 July 2024 (UTC)[reply]