<p>One detail to add here:</p>
<hr />
<p>In short:</p>
<ol start="4">
<li>if another Tx generator wants to use the same script, but one or more blocks later, it will need the datum (previous state of the script), which must be exposed by the previous generator somehow.</li>
</ol>
<hr />
<p>Tx has an option to provide the full <code>Datum</code> in the UTXO and not just the hash so that's one way for the &quot;previous generator&quot; to provide the <code>Datum</code>.</p>

CC BY-SA 4.0
2022-01-27T13:23:01.610Z
ok, thx! Yeah, I didn't include that yet, but I will. I wasn't sure how to do it. That will make the scheme a bit more complex, but I guess it will still be readable. 
(If that's the biggest issue, I do get how things work :) ).
Thanks again!
Kurt Sys
CC BY-SA 4.0
2022-01-27T09:17:54.383Z
2022-01-27T15:03:16.433Z
2022-01-27T15:03:16.433Z
hsteamroller
<p>The blockchain does not only store hashes. It also stores the datum and the script of spent UTxOs. It would otherwise not be possible to validate the transaction in retrospect. So while you don't need to provide the script and the datum (though the latter is done by default in Plutus off-chain code) when generating the UTxO, they currently need to be included in the transaction that spends these UTxOs.</p>
<p>I say &quot;currently&quot; because there is an improvement proposal in the pipeline that allows reference scripts. With this improvement, it is not necessary to include the script in every transaction. It is enough if the script was include once in a past transaction and added to the blockchain. Future transactions then can reference this script.</p>
<p>Besides this, you got the process flow right.</p>

CC BY-SA 4.0
2022-01-27T20:41:16.180Z
Well, I have heard Lars (and others) say multiple times now that one always should provide the datum (and also the script) because the blockchain only stores hashes. For the datum it's clear you can do both, and when another 'Tx Generator' needs the datum, it has to be passed in some way (UTxO metadata, publish somewhere, pass to others in any other way).
For the script itself, I hear contradictory statements. I guess I'll need to ask it Lars in the next Q&A :).
Kurt Sys
CC BY-SA 4.0
2022-01-28T14:44:26.560Z
How could you implement referencing scripts if they were not put onto the blockchain ? You need to provide the script in your offline code, this is true. But then it makes it to the blockchain as part of the transaction. There is no contradiction here.
Jey
CC BY-SA 4.0
2022-01-28T16:00:08.243Z
You send the script together with your Tx. That's how I understand it, but I'm not 100% sure either. https://youtu.be/ABtffZPoUqU?list=PLNEK_Ejlx3x2zxcfoVGARFExzOHwXFCCL&t=1427 : the vesting script is added in the Tx, the blockchain checks if it's the right script by comparing the hash. Lars saying there: 'you have to provide the actual script'. 
(I hear contradictory statements: it's stored on the bockchain vs it is not stored on the blockchain. When send together with the Tx, it's not stored on it, only executed on it.)
Kurt Sys
CC BY-SA 4.0
2022-01-28T16:11:28.440Z
in my schema, the script is not stored on the blockchain. The script is send in the Tx together with datum and redeemer. But it is executed on the blockchain (or rather, on a blockchain-node). 
Reference script, right, that may be a different thing, but there's no mention in the course so far (lecture 3) of reference scripts, so I don't know about them yet :).
Kurt Sys
CC BY-SA 4.0
2022-01-27T17:52:45.660Z
2022-01-27T17:52:45.660Z
Jey
<p>To wrap my around what happens when I where, I tried to visualize it. In order to be able to show the interaction between two different systems generating transactions, I have a Generator A and Generator B.</p>
<p>In short:</p>
<ol>
<li>some dev writes and compiles a script (smart contract)</li>
<li>that smart contract must be deployed, I suppose this is done by transacting it to the blockchain</li>
<li>if a Tx generator (someone/something making and submitting transactions) wants to make a transaction, it needs the script, so it has to fetch it from a location the dev has put that script. The script (smart contract) itself is not on the blockchain. The generator also may need a redeemer and some context. The Tx can be tested locally before sending it to the network.</li>
<li>if another Tx generator wants to use the same script, but one or more blocks later, it will need the datum (previous state of the script), which must be exposed by the previous generator somehow.</li>
</ol>
<p>Inside the nodes:</p>
<ul>
<li>Txs are received and batched. The 'winning' node may validate all the Txs, reject the invalid ones and add the valid ones to a new block. If that's done, the whole block is broadcasted (and each node checks the validity of the block).</li>
<li>validation of a Tx means that for each spending (E)UTxO the according address must 'approve' that transaction. The node validates the approvals by:
<ul>
<li>normal address: the transaction is signed (by using the private key of the corresponding public address). Validation is done by checking the hash (generated with the private key) and validating the hash with the public key.</li>
<li>script address: validation is done be executing the script giving the context (UTxOs), redeemer (some additional data added by the generator) and the datum (previous state of the script).</li>
</ul>
</li>
</ul>
<p>The blockchain itself only stores hashes (of script, datum etc), but not actual data (except for amount of Ada or other tokens), although there seems to be an option to add metadata (which, for the sake of clarity, don't take into account)</p>
<p>Am I understanding it correctly, or do I miss something (or many things :) )?</p>
<p>Thanks!</p>
<p><a href="https://i.sstatic.net/1uaDC.png" rel="noreferrer"><img src="https://i.sstatic.net/1uaDC.png" alt="enter image description here" /></a></p>

<plutus-pioneer-program><transaction><datum><validation><redeemer>
What is where executed and when?
# What is where executed and when?

(Asked by: username_0 on 2022-01-26)

To wrap my around what happens when I where, I tried to visualize it. In order to be able to show the interaction between two different systems generating transactions, I have a Generator A and Generator B.

In short:

1. some dev writes and compiles a script (smart contract)
2. that smart contract must be deployed, I suppose this is done by transacting it to the blockchain
3. if a Tx generator (someone/something making and submitting transactions) wants to make a transaction, it needs the script, so it has to fetch it from a location the dev has put that script. The script (smart contract) itself is not on the blockchain. The generator also may need a redeemer and some context. The Tx can be tested locally before sending it to the network.
4. if another Tx generator wants to use the same script, but one or more blocks later, it will need the datum (previous state of the script), which must be exposed by the previous generator somehow.

Inside the nodes:

* Txs are received and batched. The 'winning' node may validate all the Txs, reject the invalid ones and add the valid ones to a new block. If that's done, the whole block is broadcasted (and each node checks the validity of the block).
* validation of a Tx means that for each spending (E)UTxO the according address must 'approve' that transaction. The node validates the approvals by:
  + normal address: the transaction is signed (by using the private key of the corresponding public address). Validation is done by checking the hash (generated with the private key) and validating the hash with the public key.
  + script address: validation is done be executing the script giving the context (UTxOs), redeemer (some additional data added by the generator) and the datum (previous state of the script).

The blockchain itself only stores hashes (of script, datum etc), but not actual data (except for amount of Ada or other tokens), although there seems to be an option to add metadata (which, for the sake of clarity, don't take into account)

Am I understanding it correctly, or do I miss something (or many things :) )?

Thanks!

[![enter image description here](https://i.sstatic.net/1uaDC.png)](https://i.sstatic.net/1uaDC.png)

**Tags:** plutus-pioneer-program, transaction, datum, validation, redeemer

---

## 2 answers

### Answer by username_1 on 2022-01-27. Score: 2

One detail to add here:

---

In short:

4. if another Tx generator wants to use the same script, but one or more blocks later, it will need the datum (previous state of the script), which must be exposed by the previous generator somehow.

---

Tx has an option to provide the full `Datum` in the UTXO and not just the hash so that's one way for the "previous generator" to provide the `Datum`.

> **Comments:**
> **username_0**: ok, thx! Yeah, I didn't include that yet, but I will. I wasn't sure how to do it. That will make the scheme a bit more complex, but I guess it will still be readable.  (If that's the biggest issue, I do get how things work :) ). Thanks again!  

---

### Answer by username_2 on 2022-01-27. Score: 1

The blockchain does not only store hashes. It also stores the datum and the script of spent UTxOs. It would otherwise not be possible to validate the transaction in retrospect. So while you don't need to provide the script and the datum (though the latter is done by default in Plutus off-chain code) when generating the UTxO, they currently need to be included in the transaction that spends these UTxOs.

I say "currently" because there is an improvement proposal in the pipeline that allows reference scripts. With this improvement, it is not necessary to include the script in every transaction. It is enough if the script was include once in a past transaction and added to the blockchain. Future transactions then can reference this script.

Besides this, you got the process flow right.

> **Comments:**
> **username_0**: Well, I have heard Lars (and others) say multiple times now that one always should provide the datum (and also the script) because the blockchain only stores hashes. For the datum it's clear you can do both, and when another 'Tx Generator' needs the datum, it has to be passed in some way (UTxO metadata, publish somewhere, pass to others in any other way). For the script itself, I hear contradictory statements. I guess I'll need to ask it Lars in the next Q&A :).  
> **username_2**: How could you implement referencing scripts if they were not put onto the blockchain ? You need to provide the script in your offline code, this is true. But then it makes it to the blockchain as part of the transaction. There is no contradiction here.  
> **username_0**: You send the script together with your Tx. That's how I understand it, but I'm not 100% sure either. https://youtu.be/ABtffZPoUqU?list=PLNEK_Ejlx3x2zxcfoVGARFExzOHwXFCCL&t=1427 : the vesting script is added in the Tx, the blockchain checks if it's the right script by comparing the hash. Lars saying there: 'you have to provide the actual script'.  (I hear contradictory statements: it's stored on the bockchain vs it is not stored on the blockchain. When send together with the Tx, it's not stored on it, only executed on it.)  
> **username_0**: in my schema, the script is not stored on the blockchain. The script is send in the Tx together with datum and redeemer. But it is executed on the blockchain (or rather, on a blockchain-node).  Reference script, right, that may be a different thing, but there's no mention in the course so far (lecture 3) of reference scripts, so I don't know about them yet :).  

---

