user6202: 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!

user5017: 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.

6202: <p>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:</p>
<blockquote>
<p>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).</p>
</blockquote>
<p>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:</p>
<p><code>x &lt;- oracleValue (txOutTxOut o) $ \dh -&gt; Map.lookup dh $ txData $ txOutTxTx o</code> (<a href="https://github.com/mlabs-haskell/plutus-pioneer-program/blob/b50b196d57dc35559b7526fe17b49dd2ba4790bc/code/week06/src/Week06/Oracle/Core.hs#L181" rel="noreferrer">source</a>)</p>
<p>Can someone please explain what is happening here? I assume it is the &quot;on-chain communication&quot; technique that the CIP mentions. Does the datum need to be explicitly handled in a particular way for this to be possible? What are <code>txOutTxOut</code> and <code>txOutTxTx</code>? Thanks!</p>
 5017: <p>Datums are stored on-chain. There is part of <code>PAB</code> called <code>chain-index</code> - it follows the node, pulls Datums and stores them in local database (see <a href="https://docs.cardano.org/plutus/Plutus-tools" rel="nofollow noreferrer">here</a> section <code>Plutus Application Backend</code>).</p>
<p>So for your example, you can see couple lines above</p>
<pre><code>utxos &lt;- Map.filter f &lt;$&gt; utxoAt (oracleAddress oracle)
</code></pre>
<p><code>utxoAt</code> performs call to <code>chain-index</code> co-located with <code>PAB</code>. This call will return transaction output(s) with Datum(s) which <code>chain-index</code> saved while following the node (to dig a bit deeper: the hash of the Datum is known from UTxO at script address, so <code>chain-index</code> can find Datum by hash in its database, and provide transaction output with the Datum itself).</p>
<p>One note, that for this to work Datum must be properly embedded to the body of locking transaction (i.e. transaction performed by &quot;party who creates the output&quot;), but <code>Contract</code> monad machinery and <code>PAB</code> doing it for you automatically.</p>
