<p>Having the script not attached to the UTxO outputs but to the spending transaction reduces the memory consumption of the nodes because UTxOs are stored in memory. Transactions can be pushed to the storage and erased from the cache once the transaction is confirmed and the slot added to the blockchain. Also (though I don't know if Cardano does this optimisation) you could reduce transaction sizes by having each script attached only once to the transaction when multiple UTxOs of the transaction need the same script.</p>

CC BY-SA 4.0
2021-09-16T11:30:19.327Z
Is the script attached to the block and counts towards blocksize? If it is then we would trade tps for lower memory consumption, correct?
Xiaofei
CC BY-SA 4.0
2021-09-16T20:22:36.690Z
The script is part of the transaction and adds to the block size (it is also counted when evaluating the max transaction size). As a transaction needs to contain all the information needed for nodes to validate it, it must include all scripts in an executable format (hence not as hash). There is no way around it. The only thing the blockchain can do, is decide where to attach the scripts, and having them attached to the transaction instead of the individual output UTxO seems to be the smarter way.
Jey
CC BY-SA 4.0
2021-09-14T16:47:43.753Z
2021-09-14T16:47:43.753Z
Jey
<p>An update on one part of the question that hasn't been addressable till now</p>
<blockquote>
<p>If the script was stored separately on the address, then a spending
transaction would only need to point to that script instead of
spamming the blockchain with duplicate data. What am I missing here?</p>
</blockquote>
<p>Well, this is exactly what a new Cardano Improvement Proposals called CIP-33 (Reference scripts) seems to be rooting for.</p>
<p>From the <a href="https://cips.cardano.org/cips/cip33" rel="nofollow noreferrer">CIP-33 proposal</a></p>
<blockquote>
<p>We propose to allow scripts (&quot;reference scripts&quot;) to be attached to
outputs, and to allow reference scripts to be used to satisfy script
requirements during validation, rather than requiring the spending
transaction to do so. This will allow transactions using common
scripts to be much smaller.</p>
</blockquote>
<p>at the end it summarizes as below:</p>
<blockquote>
<p>The key idea of this proposal is stop sending frequently-used scripts
to the chain every time they are used, but rather make them available
in a persistent way on-chain.</p>
</blockquote>
<p>So fingers crossed, if this makes it into some future release, we will have enormous reduction in size of transactions and a lot more transactions would fit in into a block.</p>
<p>UPDATE: The Vasil hard fork is happening on mainnet on 22 Sep 2022 (already available on testnet)</p>
<p>Other CIPs of interest :</p>
<ol>
<li><a href="https://github.com/cardano-foundation/CIPs/pull/160" rel="nofollow noreferrer">CIP32 - Inline Datums</a></li>
<li><a href="https://github.com/cardano-foundation/CIPs/pull/159" rel="nofollow noreferrer">CIP31 - Reference Inputs</a></li>
</ol>

CC BY-SA 4.0
2022-02-17T17:09:21.170Z
2022-09-06T12:40:51.210Z
2022-09-06T12:40:51.210Z
Bharat Mallapur
<blockquote>
<p>If the script was stored separately on the address, then a spending transaction would only need to point to that script instead of spamming the blockchain with duplicate data.</p>
</blockquote>
<p>It's true that you could minimalize the size of transactions gossiped around the network by storing the script on-chain, but there are other resources to consider. Storage on the blockchain is very expensive because everything on there is permanent. Once something is added, it will need to be included every time someone builds a node for all eternity (with the exception of pruned networks).</p>
<p>I think in a world where we stream Netflix at 4K, including the script in the transaction seems like a negligible cost to me. The payoff might not be there for the busiest dApps, but seems like a safer bet for a vast majority of junk on the chain.</p>

CC BY-SA 4.0
2021-09-13T23:03:32.913Z
But isn't the script that's attached to the transaction also stored on the chain? How else would a node be able to validate old transactions?
Xiaofei
CC BY-SA 4.0
2021-09-13T23:26:35.073Z
Ah. Very good point. Hmm... not sure then.
Mitchell Turner
CC BY-SA 4.0
2021-09-13T22:50:20.600Z
2021-09-13T22:50:20.600Z
Mitchell Turner
<p>Why does the Plutus script need be provided in the transaction?</p>
<p>My understanding is that a script address is just a hash of the script. In order to spend a UTxO from a script address the spending transaction needs to include the script. The validator will check if the attached script's hash matches the script address and then execute the script to check if the input is allowed to be spent.</p>
<p>So the script needs to be known to whoever wants to spend a UTxo from a script address. The actual script can be attached to the UTxO when it is created on the script address so you can know what script needs to be used to unlock the funds. However, you still need to provide the script in the spending transaction.</p>
<p>This means that any time a UTxO from a smart contract address is spent, the transaction needs to include the script. If the script was stored separately on the address, then a spending transaction would only need to <em>point</em> to that script instead of spamming the blockchain with duplicate data. What am I missing here?</p>

<plutus><script-addresses>
Why does the Plutus script need be provided in the transaction?
# Why does the Plutus script need be provided in the transaction?

(Asked by: username_0 on 2021-09-13)

Why does the Plutus script need be provided in the transaction?

My understanding is that a script address is just a hash of the script. In order to spend a UTxO from a script address the spending transaction needs to include the script. The validator will check if the attached script's hash matches the script address and then execute the script to check if the input is allowed to be spent.

So the script needs to be known to whoever wants to spend a UTxo from a script address. The actual script can be attached to the UTxO when it is created on the script address so you can know what script needs to be used to unlock the funds. However, you still need to provide the script in the spending transaction.

This means that any time a UTxO from a smart contract address is spent, the transaction needs to include the script. If the script was stored separately on the address, then a spending transaction would only need to *point* to that script instead of spamming the blockchain with duplicate data. What am I missing here?

**Tags:** plutus, script-addresses

---

## 3 answers

### Answer by username_1 on 2021-09-14. Score: 1 | Accepted answer

Having the script not attached to the UTxO outputs but to the spending transaction reduces the memory consumption of the nodes because UTxOs are stored in memory. Transactions can be pushed to the storage and erased from the cache once the transaction is confirmed and the slot added to the blockchain. Also (though I don't know if Cardano does this optimisation) you could reduce transaction sizes by having each script attached only once to the transaction when multiple UTxOs of the transaction need the same script.

> **Comments:**
> **username_0**: Is the script attached to the block and counts towards blocksize? If it is then we would trade tps for lower memory consumption, correct?  
> **username_1**: The script is part of the transaction and adds to the block size (it is also counted when evaluating the max transaction size). As a transaction needs to contain all the information needed for nodes to validate it, it must include all scripts in an executable format (hence not as hash). There is no way around it. The only thing the blockchain can do, is decide where to attach the scripts, and having them attached to the transaction instead of the individual output UTxO seems to be the smarter way.  

---

### Answer by username_2 on 2022-02-17. Score: 3

An update on one part of the question that hasn't been addressable till now

> If the script was stored separately on the address, then a spending
> transaction would only need to point to that script instead of
> spamming the blockchain with duplicate data. What am I missing here?

Well, this is exactly what a new Cardano Improvement Proposals called CIP-33 (Reference scripts) seems to be rooting for.

From the [CIP-33 proposal](https://cips.cardano.org/cips/cip33)

> We propose to allow scripts ("reference scripts") to be attached to
> outputs, and to allow reference scripts to be used to satisfy script
> requirements during validation, rather than requiring the spending
> transaction to do so. This will allow transactions using common
> scripts to be much smaller.

at the end it summarizes as below:

> The key idea of this proposal is stop sending frequently-used scripts
> to the chain every time they are used, but rather make them available
> in a persistent way on-chain.

So fingers crossed, if this makes it into some future release, we will have enormous reduction in size of transactions and a lot more transactions would fit in into a block.

UPDATE: The Vasil hard fork is happening on mainnet on 22 Sep 2022 (already available on testnet)

Other CIPs of interest :

1. [CIP32 - Inline Datums](https://github.com/cardano-foundation/CIPs/pull/160)
2. [CIP31 - Reference Inputs](https://github.com/cardano-foundation/CIPs/pull/159)


---

### Answer by username_3 on 2021-09-13. Score: 0

> If the script was stored separately on the address, then a spending transaction would only need to point to that script instead of spamming the blockchain with duplicate data.

It's true that you could minimalize the size of transactions gossiped around the network by storing the script on-chain, but there are other resources to consider. Storage on the blockchain is very expensive because everything on there is permanent. Once something is added, it will need to be included every time someone builds a node for all eternity (with the exception of pruned networks).

I think in a world where we stream Netflix at 4K, including the script in the transaction seems like a negligible cost to me. The payoff might not be there for the busiest dApps, but seems like a safer bet for a vast majority of junk on the chain.

> **Comments:**
> **username_0**: But isn't the script that's attached to the transaction also stored on the chain? How else would a node be able to validate old transactions?  
> **username_3**: Ah. Very good point. Hmm... not sure then.  

---

