What is the Oracle Problem definition exactly and briefly? Does it mean "trusting on a centralized Oracle" ? Or "How to reach a consensus between a group of Oracles" ? Is the matter "centralization" or "being trust-based" ? (that is in contrary to decentralization feature of blockchain.)
The oracle problem is:
"If oracles allow corrupt data to be imported on-chain, auto-executing smart contracts can have disastrous affects"
Once data is reported to a blockchain, that data is now an immutable part of the history of the blockchain. If a smart contract executes incorrectly based off that data, your contract is not only not doing what it was intended to do, but it can cause irreparable damage.
So when you ask if it means "trusting on a centralized Oracle" or "How to reach a consensus between a group of Oracles" the answer to both is yes. You want to figure out how to bring data on-chain without having any piece be centralized so you can have decentral smart contracts.
If your data is centralized (coming from one source) and that source is bribed, hacked, broken, or depreciated, your contract no longer works.
The solution to the oracle problem is to have a decentralized network of oracles bringing different independent sources of data on-chain. We've seen Chainlink solve this issue.
Blockchain is a walled garden.
It's also described as the problem of putting real world state onto the blockchain state.
Data is only trustworthy once it has been entered on the blockchain.
However we still need to trust the values that have been put in initially.
- I have a smart contract that pulls in the current eth/usd exchange rate. I would do an API call on the client side and enter the result as a parameter to my smart contract function.
- If the API fails or is wrong my smart contract will also execute in a way I might not want
- Therefore we would pull in the same data from at least 3 different sources. If 2/3 are within a same really narrow error range you likely have a trustworthy data source.
The oracle problem states that "as soon as you make a smart contract rely on a single central oracle, you have totally sacrificed any decentralization benefits." (See here). It is an issue of centralization, as oracles are generally a single source of truth.
The issue also lies on multiple layers. The oracle layer itself is generally a centralized entity that provides data to a smart contract. A single rogue employee may have the power to falsify the input data to a smart contract if he finds it economically incentivizing. The data layer can also be a centralized layer as well. Imagine a smart contract using Oraclize to get a random number from random.org. A malicious actor with access to the random.org source code could feed a known number into the site, which would be picked up by Oraclize and sent to the smart contract. This actor is able to now make a transaction on the smart contact that he knows the outcome to.
There is much research being done in this area to solve this issue. One possible solution is to use consensus oracles that must agree on a piece of data for it to be propogated to the network. This can be amplified by requiring these members to stake some token, giving them economic incentive to choose correctly (if they go against the crowd, they lose their stake).