<p>By inspecting the current ledger <a href="https://github.com/input-output-hk/cardano-ledger-specs/blob/master/shelley-ma/shelley-ma-test/cddl-files/shelley-ma.cddl" rel="nofollow noreferrer">CDDL specifications</a>, you can see that each <code>block</code> contains a <code>transaction_witness_sets</code> field, where each <code>transaction_witness_set</code> is defined as:</p>
<pre><code>transaction_witness_set =
  { ? 0: [* vkeywitness ]
  , ? 1: [* native_script ]
  , ? 2: [* bootstrap_witness ]
  }
</code></pre>
<p>Here, <code>native_script</code>, if present, contains some rules that need to be respected in order for the transaction to be valid (for instance, some minting policy):</p>
<pre><code>native_script =
  [ script_pubkey
  // script_all
  // script_any
  // script_n_of_k
  // invalid_before
     ; Timelock validity intervals are half-open intervals [a, b).
     ; This field specifies the left (included) endpoint a.
  // invalid_hereafter
     ; Timelock validity intervals are half-open intervals [a, b).
     ; This field specifies the right (excluded) endpoint b.
  ]
</code></pre>
<p>So not only the script hash is included in the chain, but also the actual rules it contains.</p>

CC BY-SA 4.0
2021-04-28T08:54:58.220Z
2021-04-28T08:54:58.220Z
vaz
<p>A node initially executes a valid Plutus transaction and records it to the chain, it also adds an &quot;isValid&quot; tag to that transaction record.</p>
<p>When a new node starts syncing up and arrives at a Plutus transaction, it only looks out for the &quot;isValid&quot; tag and then adds that transaction to its chain if it does have the tag, this way new nodes don't have to re-execute the script but still have proof they belong on the chain.</p>

CC BY-SA 4.0
2022-12-22T09:01:54.500Z
hm sounds bad, when a validator can just set isValid=true and everybody beleves it
wutzebaer
CC BY-SA 4.0
2022-12-25T05:58:08.383Z
Cardano transactions are deterministic and compliant with the Ledger rules, a block producer cannot just slap an "isValid" tag on a transaction anyhow, it has to be validated by them and according to rules so if a block producer acts adversarially then other validators who do decide to do the heavy-lifting will notice and consensus rules take charge. Also an isValid tag doesn't mean a client will just speed run by default, they can still revalidate the Tx if they choose. Vas points to the data they need in their response.
Pizza Knight
CC BY-SA 4.0
2022-12-27T09:04:24.030Z
"Can" revalidate sounds vague, i think the other answer is more appropriate and the script is always attached to the transaction and all nodes re-evaluate that the condition were valid.
wutzebaer
CC BY-SA 4.0
2022-12-11T04:33:54.767Z
2022-12-11T04:33:54.767Z
Pizza Knight
<p>How can a node verify a transaction with a script address without the script?</p>
<p>I mean when i start a node months after the transaction has been minted into a block. How can my node verify that the script conditions were met since only the hash is persisted in the chain?</p>

<script-addresses>
How can a node verify a transaction with a script address without the script?
# How can a node verify a transaction with a script address without the script?

(Asked by: username_0 on 2021-04-27)

How can a node verify a transaction with a script address without the script?

I mean when i start a node months after the transaction has been minted into a block. How can my node verify that the script conditions were met since only the hash is persisted in the chain?

**Tags:** script-addresses

---

## 2 answers

### Answer by username_1 on 2021-04-28. Score: 4 | Accepted answer

By inspecting the current ledger CDDL specifications, you can see that each block contains a transaction_witness_sets field, where each transaction_witness_set is defined as:
transaction_witness_set =
  { ? 0: [* vkeywitness ]
  , ? 1: [* native_script ]
  , ? 2: [* bootstrap_witness ]
  }

Here, native_script, if present, contains some rules that need to be respected in order for the transaction to be valid (for instance, some minting policy):
native_script =
  [ script_pubkey
  // script_all
  // script_any
  // script_n_of_k
  // invalid_before
     ; Timelock validity intervals are half-open intervals [a, b).
     ; This field specifies the left (included) endpoint a.
  // invalid_hereafter
     ; Timelock validity intervals are half-open intervals [a, b).
     ; This field specifies the right (excluded) endpoint b.
  ]

So not only the script hash is included in the chain, but also the actual rules it contains.


---

### Answer by username_2 on 2022-12-11. Score: 0

A node initially executes a valid Plutus transaction and records it to the chain, it also adds an "isValid" tag to that transaction record.

When a new node starts syncing up and arrives at a Plutus transaction, it only looks out for the "isValid" tag and then adds that transaction to its chain if it does have the tag, this way new nodes don't have to re-execute the script but still have proof they belong on the chain.

> **Comments:**
> **username_0**: hm sounds bad, when a validator can just set isValid=true and everybody beleves it  
> **username_2**: Cardano transactions are deterministic and compliant with the Ledger rules, a block producer cannot just slap an "isValid" tag on a transaction anyhow, it has to be validated by them and according to rules so if a block producer acts adversarially then other validators who do decide to do the heavy-lifting will notice and consensus rules take charge. Also an isValid tag doesn't mean a client will just speed run by default, they can still revalidate the Tx if they choose. Vas points to the data they need in their response.  
> **username_0**: "Can" revalidate sounds vague, i think the other answer is more appropriate and the script is always attached to the transaction and all nodes re-evaluate that the condition were valid.  

---

