user2335: I have an in-depth question that needs good knowledge of the ledger rules.
I was thinking about how to program efficiently and design apps such that they are parallelizable, a good practice for achieving this is building modular and piece wise. While thinking about certain contracts that could validate in parallel I wondered how such transactions are build and specified for validation. This is not a canonical task and can be ambiguous for a validator. So a natural conclusion is that to preserve determinism one has to fully specify a transaction, some question on this specification.
Consider a transaction that tries to consume n eUTxO's of contract instance A and m of the contract instance B. Then this transaction has to have n+m datums that match the inputs.
Question 1: Do you specify in your transaction which datum corresponds to which input or does the validator node matches them by hashing your suggested datum? Also, if certain datums match, can you save on transaction size by appending the datum once and specifying the datum to each input?
Question 2: Do you append the contracts A and B multiple time (n+m times to be exact) to the transaction or just once for each occurrence? Again, the latter would save on transaction size.
Now there is also another integral part of consuming eUTxO's, namely their redeemers. Since each eUTxO generally have a different redeemer one also has to specify which redeemer is associated to which input.
Question 3: How is this association between redeemer en input specified in a transaction? And moreover, can this specification again be non-injective. That is, a redeemer can be appended once to the transaction but be associated to multiple inputs? This would again save on transaction size.
And lastly we have the outputs where we give each one a possible new datum. These new datums, how are the specified and can they be assigned in a non-injective way to save on transaction size?

user6292: Datums are stored in a hash map per transaction, so if a transaction uses the same datum multiple times, the datum is stored once and only the hashes are stored multiple times. The same goes for redeemers.
(I don't understand all the questions, but this is at least a partial answer. Feel free to add to this answer.)

2335: <p>I have an in-depth question that needs good knowledge of the ledger rules.</p>
<p>I was thinking about how to program efficiently and design apps such that they are parallelizable, a good practice for achieving this is building modular and piece wise. While thinking about certain contracts that could validate in parallel I wondered how such transactions are build and specified for validation. This is not a canonical task and can be ambiguous for a validator. So a natural conclusion is that to preserve determinism one has to fully specify a transaction, some question on this specification.</p>
<p>Consider a transaction that tries to consume <code>n</code> eUTxO's of contract instance A and <code>m</code> of the contract instance B. Then this transaction has to have <code>n+m</code> datums that match the inputs.</p>
<p>Question 1: Do you specify in your transaction which datum corresponds to which input or does the validator node matches them by hashing your suggested datum? Also, if certain datums match, can you save on transaction size by appending the datum once and specifying the datum to each input?</p>
<p>Question 2: Do you append the contracts A and B multiple time (<code>n+m</code> times to be exact) to the transaction or just once for each occurrence? Again, the latter would save on transaction size.</p>
<p>Now there is also another integral part of consuming eUTxO's, namely their redeemers. Since each eUTxO generally have a different redeemer one also has to specify which redeemer is associated to which input.</p>
<p>Question 3: How is this association between redeemer en input specified in a transaction? And moreover, can this specification again be non-injective. That is, a redeemer can be appended once to the transaction but be associated to multiple inputs? This would again save on transaction size.</p>
<p>And lastly we have the outputs where we give each one a possible new datum. These new datums, how are the specified and can they be assigned in a non-injective way to save on transaction size?</p>
 6292: <p>Datums are stored in a hash map per transaction, so if a transaction uses the same datum multiple times, the datum is stored once and only the hashes are stored multiple times. The same goes for redeemers.</p>
<p>(I don't understand all the questions, but this is at least a partial answer. Feel free to add to this answer.)</p>
