Hello Danilo, thank you for your questions.
Decentralized applications cannot reach out to the external world directly, that’s where our service plays a role. Provable (Oraclize) provides a data-transport-layer enabling smart contracts to fetch external data, for example from a Web API. While doing so, the operator providing this connection (Provable in this case) could potentially tamper with the data and deliver to the smart contract data that has been altered.
To reduce the risk of tampering, Provable enables its users to request an authenticity proof to be delivered along with the data. This is a cryptographic guarantee proving the authenticity of the data, by showing that the data delivered to the smart contract is the exact same data that was generated by the original source (the Web API). Let’s say you have a smart contract that needs to know the price of ETH compared to USD and that you decide to get that from cryptocompare.com via our service. Thanks to authenticity proofs anyone can verify that the data delivered to the smart contract matches the one generated by cryptocompare.com.
The concept of authenticity proofs is something we invented and that’s basically a cryptographic guarantee that’s generated thanks to a variety of sandboxing techniques. In the case of TLS Notary proof, we are leveraging software attestation achieved via AWS virtual machines. While all our other proofs leverage hardware attestation and Trusted Computing to achieve the same goal, meaning that to generate the relevant authenticity proof we use physical devices. That’s the case for the Ledger proof — we use the Ledger Nano S device along with its Trusted Execution Environment (the sandboxing technique) to generate the authenticity proof.
Regardless of the proof, all the information are sent back to the smart contract via a __callback transaction. The service is asynchronous, meaning that you will have one transaction (query) to request the data (and any additional information your smart contract may need, for example an authenticity proof) and a second transaction (__callback) to deliver the data.
While developing the smart contract, you will need to integrate our APIs. This includes implementing the __callback function as well. While doing so, you can decide what you would like to be included in the __callback transaction: this could be the data only, the data along with an authenticity proof, the data along with an authenticity proof that you want to store on IPFS, etc. In this context, the proof type indicates what kind of proof you would like to use. If you decide to go with the TLS Notary proof, it means that Amazon’s software attestation provided by TLS Notary will be leveraged in the background. Similarly, if you decide to go with the Ledger proof, it means that Ledger’s hardware attestation will be leveraged in the background, and so on for all the proofs. Additionally, smart contract developers can decide to store those proofs on IPFS or somewhere else — that’s also defined within the __callback function.
Proofs can be verified by anyone anytime off-chain (afterwards), so that if something unusual happens the proof can be checked. This method is helpful so that the workload for the smart contract doesn’t get unnecessarily increased. Alternatively, smart contracts can independently verify the proof on-chain (beforehand) — the ways of doing so depends on on the proof type. For example, the Ledger proof can be verified on-chain straight away, while the TLS Notary proof needs to be combined with the Proof Shield (one of our other features, that lightens the authenticity proof) to be verified on-chain.
I hope this overview helps. In case you have further questions on how authenticity proofs technically work, you can reach out to our public support channel: https://gitter.im/oraclize.