However, the problem of trust has reappeared. The oracle is in the position to change the data from the sensors before it even reaches the blockchain. Once in the blockchain the data transacted may be trusted without a TTP – but the oracle providers have to be trusted. The oracle providers are letting themselves be certified by central certification systems. This however means the TTP is back (just in a different form) and also centralized (like Verisign for trusted web pages). A simple denial of service attack on the certificate providers or the oracles themselves could stop the entire IoT system.
One option is to supply the data to several different oracles and use redundancy. However, to set up enough oracles is too expensive for most organizations. An open source universally hostable oracle server could be the solution to serving the data but not to the trustworthiness.
A certificate only “trusts” the oracle node. The sensor which delivers the information could be compromised and the oracle would not know it or - worse - “wouldn’t care”. The oracle producers just provide the service to get the information onto the blockchain and cannot realistically check all sensor providers.
Of course the sensor providers could also certify themselves and say that their hardware/firmware is not hackable and is trustworthy. But there again is the TTP problem, customer lock-in and higher costs involved in your system.
With the introduction of such a TTP, the use of a decentralized trusted blockchain is then questionable. A “standard” database centralized network provides the same functionality with, effectively, the same disadvantages.