CIP-0031 Reference Inputs

[dorin100]

cardano-node related PR:
#3810

cardano-node bugs
4073 -> Improve build behaviour of build with invalid reference inputs #1343
4012 -> Improve message #1344

info
https://github.com/cardano-foundation/CIPs/tree/master/CIP-0031

AC1 Possible to reference a transaction input allowing looking at it without spending it

1. Reference an input, check that the input is not consumed
   • using build
   • using build-raw
2. Reference an output that is also a regular input of the same transaction (does cli option order affect the outcome) Important: Check if the cli option order affects the outcome and if meaningful error messages are returned
   • using build
   • using build-raw
3. Reference spent outputs - Expect Failure (with meaningfull error message) improves messages
   • using build
   • using build-raw
4. Reference an invalid input - Expect Failure (with meaningfull error message)
   • using build
   • using build-raw

AC2 Outputs can be referenced multiple times, so we have non-interference even under heavy usage of referencing.

1. Reference the same input multiple times for a single transaction (no duplicates should arise in TxInfo)
   • using build
   • using build-raw
2. 2 different transactions can fetch the same reference input in the same block (best effort as we don't have control in how the txs are included in blocks)
   • using build

AC3 Scripts with old versions cannot be spent in transactions that include reference inputs, attempting to do so will be a phase 1 transaction validation failure.

1. Spend an old version script in a transaction that includes a reference input - Expect Failure (with meaningful error message)
   • using build
   • using build-raw

AC4 A transaction must always spend at least one UTXO, and UTXOs can only be spent once.

1. Try to reference an input without spending any UTXO - Expect Failure (with meaningful error message)
   • using build
   • using build-raw

AC5 Spending conditions on referenced outputs are not checked

1. referencing a utxo that has datum hash attached and at script address without attaching the script
   • using build
   • using build-raw
2. referencing a utxo that is at a vkey address and the transaction is not signed by the associated skey
   • using build
   • using build-raw

AC6 Plutus can see everything available in an Alonzo tx: value, tokens, datum hash - Plutus script required

1. Reference an input and run a Plutus script validating that it has visibility of it (to prove that a utxo created pre-Vasil can be referenced and is useful to Plutus)
   Plutus v2 tests with dedicated plutus scripts #1261

AC7 the new cost model is respected

• check that the cost provided by the CLI for storing and TX fee is accurate (respects the cost model)

AC8 new CLI commands/parameters

• It shall be possible to review a reference input using the transaction view command

[catch-21]

We should also have a test that runs a plutus script validating that it has visbility of referenced outputs, see reference inputs

[vfrsilva]

@dorin100 for AC2 - can we also make sure that 2 different transactions can fetch the same reference input in the same block?

[vfrsilva]

@dorin100 can we please add an AC to create a reference input? Also, test the UTxO deposit and what happens with the native tokens - if all works as expected.

Also, please add another AC to check if the cost provided by the CLI for storing and TX fee is accurate.

And finally, a new AC to test if a user can destroy a reference input and recover the storage deposit back.

Thanks!

[vfrsilva]

@dorin100 how can we test the following? This ACs shall apply to all CIPs, shall we add to each one of is enough to add to one of the CIPs ACs? Thanks

1. CLI has JSON output available
2. CLI has the option to export output to file

[dorin100]

@dorin100 can we please add an AC to create a reference input?

I think any new input can be referenced so in that case this would be covered

[dorin100]

Also, test the UTxO deposit and what happens with the native tokens - if all works as expected.

this should be simple regression as here there will not be any new functionality; if that is the case, we already have automated tests for this

[vfrsilva]

@dorin100 can we please add an AC to create a reference input?

I think any new input can be referenced so in that case this would be covered

My understanding is that Reference Input is a special type of input. Can you please double-check?

From CDDL I can see:
transaction_body = { 0 : set<transaction_input> ; inputs ... , ? 16 : set<transaction_input> ; reference inputs }

[dorin100]

@dorin100 can we please add an AC to create a reference input?

I think any new input can be referenced so in that case this would be covered

My understanding is that Reference Input is a special type of input. Can you please double-check?

From CDDL I can see: transaction_body = { 0 : set<transaction_input> ; inputs ... , ? 16 : set<transaction_input> ; reference inputs }

good point;
@james-iohk, @Jimbo4350 do you have more details about this?

[dorin100]

a new AC to test if a user can destroy a reference input and recover the storage deposit back.

I feel I don't understand this; IMO an input can be consumed/spent and in that case, it will not be available anymore (to be referenced)

I am not aware of any new type of deposit --> do you have more details about this, maybe I missed something...?

[dorin100]

@dorin100 how can we test the following? This ACs shall apply to all CIPs, shall we add to each one of is enough to add to one of the CIPs ACs? Thanks

1. CLI has JSON output available
2. CLI has the option to export output to file

I will add this to any thicket as there will be different cli commands.

thank you

[vfrsilva]

a new AC to test if a user can destroy a reference input and recover the storage deposit back.

I feel I don't understand this; IMO an input can be consumed/spent and in that case, it will not be available anymore (to be referenced)

I am not aware of any new type of deposit --> do you have more details about this, maybe I missed something...?

Destroy is not the correct nomenclature. Basically, the AC is the following:

Given I am a dapp developer
When I no longer need to use a reference input
Then I should be able to consume the UTxO containing the reference script and get the storage deposit back.

Can you please add such an AC to all CIPs, please? Since all will share the same mechanism.

Thank you!

[dorin100]

a new AC to test if a user can destroy a reference input and recover the storage deposit back.

I feel I don't understand this; IMO an input can be consumed/spent and in that case, it will not be available anymore (to be referenced)
I am not aware of any new type of deposit --> do you have more details about this, maybe I missed something...?

Destroy is not the correct nomenclature. Basically, the AC is the following:

Given I am a dapp developer When I no longer need to use a reference input Then I should be able to consume the UTxO containing the reference script and get the storage deposit back.

Can you please add such an AC to all CIPs, please? Since all will share the same mechanism.

Thank you!

My understanding is that when you don't need the reference input anymore, you consume/spend it and that is all (I am not aware of any storage deposit and I don't remember reading about it anywhere). Based on what did you create this expectation?

LE: we discussed this online - it was about the minUtxoValue --> I added some checks to AC2 here - #995

[catch-21]

From CDDL I can see: transaction_body = { 0 : set<transaction_input> ; inputs ... , ? 16 : set<transaction_input> ; reference inputs }

This tells me that inputs and reference inputs are both the same type, a set of transaction ids and indices.
Afaik any utxo can be referenced regardless of how or when it was created. The executing script must be V2.

[vfrsilva]

@dorin100 can we add: It shall be possible to review a reference input using the transaction view command - please