Plutus pattern/technique for finding original datum preimage of TxOutDatumHash?

Question

Every UTXO at a script address must have a TxOutDatumHash (or will be unspendable). To spend the UTXO at the validator you provide a datum and a redeemer, the script must validate with your redeemer, and the datum you provide must hash to the TxOutDatumHash of the UTXO you're spending. The problem, as discussed in CIP-32:

This is quite inconvenient for users. Datums tend to represent the result of computation done by the party who creates the output, and as such there is almost no chance that the spending party will know the datum without communicating with the creating party. That means that either the datum must be communicated between parties off-chain, or communicated on-chain by attaching it to the transaction that creates the output (which is also inconvenient in that the spending party must watch the whole chain to spot it).

But when I look at the code of, for example, the Oracle in Week 6 (or even the English Auction in Week 1), there seems to be a way of pulling the original datum from somewhere:

x <- oracleValue (txOutTxOut o) $ \dh -> Map.lookup dh $ txData $ txOutTxTx o (source)

Can someone please explain what is happening here? I assume it is the "on-chain communication" technique that the CIP mentions. Does the datum need to be explicitly handled in a particular way for this to be possible? What are txOutTxOut and txOutTxTx? Thanks!

Answer 1

Datums are stored on-chain. There is part of PAB called chain-index - it follows the node, pulls Datums and stores them in local database (see here section Plutus Application Backend).

So for your example, you can see couple lines above

utxos <- Map.filter f <$> utxoAt (oracleAddress oracle)

utxoAt performs call to chain-index co-located with PAB. This call will return transaction output(s) with Datum(s) which chain-index saved while following the node (to dig a bit deeper: the hash of the Datum is known from UTxO at script address, so chain-index can find Datum by hash in its database, and provide transaction output with the Datum itself).

One note, that for this to work Datum must be properly embedded to the body of locking transaction (i.e. transaction performed by "party who creates the output"), but Contract monad machinery and PAB doing it for you automatically.

Answer 2

It seems like the example you mention uses the plutus-apps stack, which is doing exactly what you suspect:

It includes the datum in the producing transaction and the PAB does keep track of this to provide it as enhanced TxOutTx values.