Wsrtjtyk

I'm trying to understand how corda oracles work from an example on github. It seems like in every example oracle verification function checks the data in command and data in output state. I don't understand why that should work because we (issuer node) manage that data and put it in command/output state.

// Our contract does not check that the Nth prime is correct. Instead, it checks that the

// information in the command and state match.

override fun verify(tx: LedgerTransaction) = requireThat {

    "There are no inputs" using (tx.inputs.isEmpty())

    val output = tx.outputsOfType<PrimeState>().single()

    val command = tx.commands.requireSingleCommand<Create>().value

    "The prime in the output does not match the prime in the command." using

            (command.n == output.n && command.nthPrime == output.nthPrime)

}

In this example state gets Nth prime number from oracle but after it's issued the verification function doesn't rerun generateNth prime function to make sure that this number is really the one we needed. I understand that data in this example is deterministic since Nth prime cannot change but what about the case where we have dynamic data like stock values? Shouldn't oracle verification function also send another http request and get current values to check them?

Firstly, note that contracts in Corda are not able to access the outside world in any way (DB reads, HTTP requests, etc.). If they could, transaction validity would be non-deterministic. A transaction that is found to be valid on day n may become invalid on day n+1 (because a database row changed, or a website went down, etc.). This would cause disagreements about whether a given transaction was a valid ledger update.

However, we sometimes need a transaction to include external data for verification (whether a company is bankrupt, whether a natural catastrophe happened, etc.). To do this, we use a trusted oracle that only signs the transaction if a given piece of data is valid.

We could embed the information in the input or output states. However, this would require us to reveal the entire input or output state to the oracle for signing. For privacy reasons, it is therefore preferable to embed the data in a command that only contains the data of interest to the oracle, so that we can filter out all the other parts of the transaction and only present this command to the oracle for signing.

The oracle will usually perform a DB read or make an HTTP request to check the validity of the data before signing.