user5602: 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:

some dev writes and compiles a script (smart contract)
that smart contract must be deployed, I suppose this is done by transacting it to the blockchain
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.
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!


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

user2477: One detail to add here:

In short:

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.

5602: <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.stack.imgur.com/1uaDC.png" rel="noreferrer"><img src="https://i.stack.imgur.com/1uaDC.png" alt="enter image description here" /></a></p>
 2537: <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>
 2477: <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>
