CIP-???? | On-chain Transaction Chaining

[michele-nuzzi]

Once in a while, I see people raising issues that could be solved with transaction chaining if there where the possibility to have some additional guarantees on it.

There is no strict need for this proposal at the current state but I think it might prevent something more complex in the future.

(see rendered proposal in branch)

[L-as]

Seems like this is basically batched transactions as described in IntersectMBO/cardano-ledger#768

[michele-nuzzi]

The goal/problem they try to solve is the same; however, I would say this is a different implementation if compared to do the description of the cited issue

[michaelpj]

This is too vague: you are suggesting we index backwards from a transaction in what? The mempool? The chain? Both of those are created non-deterministically, so that seems extremely unlikely to work.

[michele-nuzzi]

I'm not really sure where this should happen if you have any suggestions that would be great.

regarding both being not deterministic the pointer to the previous transaction only makes sense if there is a previous transaction pointing to the current one.

If none is present the transaction should be considered invalid (or at least wait to be processed until some other transaction includes the current as chained).

In this sense transactions are referencing chained ones forwards; UTxO is referencing backward.

[michaelpj]

Yes, this is quite different to the proposals there. I would like to see some analysis of the requirements and comparison with other solutions, since the various solutions all differ in terms of what they offer.

Some requirements questions:

1. What's the batch creation process?
   • Both this and the simple "signed batches" proposal in the linked issue require all the transactions to be constructed together
2. What's visible to scripts?
   • This proposal adds some information about other transactions in the batch to scripts
3. Other things?

[michaelpj]

It seems to me that the main difference between this and batch transactions is that this lets scripts "see" that other transactions will happen, which is a major power increase and I'm not sure what I think about it.

I think we could probably add that to batch transactions too, though: include a field like "otherTransactionsInBatch :: [TxIx]` to the script context. I don't think that gives us a hashing problem although it might make fee calculation annoying.

[michaelpj]

Please provide some actual usecases!

[KtorZ]

I concur with @michaelpj here, the motivation is a bit short. It's not clear to me "how is this a useful thing". Or more exactly, how is that different from chaining UTxO the way it's already possible?

[michaelpj]

It would really help to have some usecases to see how this is useful. I think I can guess, but please just explain!

[dcoutts]

Doesn't this imply that the chain of transactions must all be within one block? I can't see how to enforce the guarantee otherwise. And if so, doesn't this end up being much the same as batched transactions?

[michele-nuzzi]

Doesn't this imply that the chain of transactions must all be within one block? I can't see how to enforce the guarantee otherwise. And if so, doesn't this end up being much the same as batched transactions?

Not necessarily; transactions can still be included in multiple blocks; the only thing needed for a chain of transactions is the existence of an output of a previous one

[michaelpj]

Not necessarily; transactions can still be included in multiple blocks; the only thing needed for a chain of transactions is the existence of an output of a previous one

So this doesn't ensure that the following transaction is ever made? It's much less clear what the point is, then. I thought this would allow scripts to ensure that another transaction happens, but in this case it wouldn't.

[michele-nuzzi]

It seems to me that the main difference between this and batch transactions is that this lets scripts "see" that other transactions will happen, which is a major power increase and I'm not sure what I think about it.

That is the main idea of the proposal. The main use case (that I will add as soon as I edit the proposal) is the composability of transactions; keeping every transaction atomic on its own but under all aspects provides a way to be sure some other action took place (based on the output of the current).

In general this would give scripts the possibility to act like active entities.

This, as an example, allows for datum validation when creating a brand new UTxO in a script; where the first transaction creates the UTxO and the second spends that UTxO only to be sure that the datum is valid; if the second fails the first fails too, so the UTxO is never created.

Another use case, also based on the "acting like active entities" thing, is smart contract interaction; where a smart contract first performs an action (even expansive ones) and then forwards the validation to a script in a successive transaction that checks for the result of the previous and the presence of the target (external) contract; under all aspects emulating a contract call.

NOTE: thanks to the Acyclic structure of UTxOs there's no danger for reentrant calls

[michele-nuzzi]

Not necessarily; transactions can still be included in multiple blocks; the only thing needed for a chain of transactions is the existence of an output of a previous one

So this doesn't ensure that the following transaction is ever made? It's much less clear what the point is, then. I thought this would allow scripts to ensure that another transaction happens, but in this case it wouldn't.

In order to be included in a block all the chained transactions have to be submitted an all have to be validated; if any of the transactions fails none is included; if all succeed then can be included as a normal transaction.

If the above doesn't make sense then is likely I'm missing something so please let me know how can I improve there.

[KtorZ]

This last paragraph shall actually be part of the "Motivation" section IMO as it gives some clear justification for why is this CIP necessary.

[michele-nuzzi]

Will do!

[KtorZ]

Little suggestion: I'd welcome some extra proof-reading on the document as there are many little typos 🤓

[rphair]

@KtorZ: ... proof-reading on the document as there are many little typos 🤓

@michele-nuzzi after you've given this your best effort let us know & I'll give it a good editing review. 😇

[michele-nuzzi]

Little suggestion: I'd welcome some extra proof-reading on the document as there are many little typos nerd_face

That is my signature; at least we are sure I wrote it.

Will go over it by tomorrow.

[rphair]

@michele-nuzzi marking Waiting for Author as per #518.

[fallen-icarus]

@michele-nuzzi Why can't you just use minting policies for this? That is what I have been using for my applications.

The main use case (that I will add as soon as I edit the proposal) is the composability of transactions; keeping every transaction atomic on its own but under all aspects provides a way to be sure some other action took place (based on the output of the current).

This, as an example, allows for datum validation when creating a brand new UTxO in a script; where the first transaction creates the UTxO and the second spends that UTxO only to be sure that the datum is valid; if the second fails the first fails too, so the UTxO is never created.

This is literally how I use the minting policy. For example, when a borrower creates a UTxO to ask for a loan, they must mint an Ask token and store it in the UTxO. This Ask token can only be minted if the datum in the UTxO is valid (among other things). A lender who then wants to offer a loan must create a UTxO with an Offer token. The Offer token can only be minted if the offer is valid (datum, value, etc must all be valid). To accept a loan, the borrower must match up an ask UTxO with an offer UTxO with the added requirement that they contain an Ask token and Offer token, respectively. The very fact that the tokens exist means the UTxOs are valid. To use the terminology here, the presence of the tokens is proof that a previous transaction occured. I have successfully been able to compose my applications using this approach. For example, you can safely compose my dex, options trading protocol, and secondary market in a single transaction. They either all succeed or the transaction fails.

In order to be included in a block all the chained transactions have to be submitted an all have to be validated; if any of the transactions fails none is included; if all succeed then can be included as a normal transaction.

The approach I mention above has this property already. Why is this approach not sufficient?

[michele-nuzzi]

@michele-nuzzi Why can't you just use minting policies for this? That is what I have been using for my applications.

The main use case (that I will add as soon as I edit the proposal) is the composability of transactions; keeping every transaction atomic on its own but under all aspects provides a way to be sure some other action took place (based on the output of the current).

This, as an example, allows for datum validation when creating a brand new UTxO in a script; where the first transaction creates the UTxO and the second spends that UTxO only to be sure that the datum is valid; if the second fails the first fails too, so the UTxO is never created.

This is literally how I use the minting policy. For example, when a borrower creates a UTxO to ask for a loan, they must mint an Ask token and store it in the UTxO. This Ask token can only be minted if the datum in the UTxO is valid (among other things). A lender who then wants to offer a loan must create a UTxO with an Offer token. The Offer token can only be minted if the offer is valid (datum, value, etc must all be valid). To accept a loan, the borrower must match up an ask UTxO with an offer UTxO with the added requirement that they contain an Ask token and Offer token, respectively. The very fact that the tokens exist means the UTxOs are valid. To use the terminology here, the presence of the tokens is proof that a previous transaction occured. I have successfully been able to compose my applications using this approach. For example, you can safely compose my dex, options trading protocol, and secondary market in a single transaction. They either all succeed or the transaction fails.

In order to be included in a block all the chained transactions have to be submitted an all have to be validated; if any of the transactions fails none is included; if all succeed then can be included as a normal transaction.

The approach I mention above has this property already. Why is this approach not sufficient?

yes that particular scenario is already possible without chaining transactions; as an example, I used a similar technique in this yield contract;

however, the contract tends to be more complicated because

in that particular case, I had a mutual dependency between the minting policy and the validator (policy checks for the asset to be sent to the validator and the validator checks for the policy to assert the validity of an utxo)

that implies "unsafe" type coercion and ad-hoc data design.

while the CIP won't remove the pattern (mutual dependencies are more common than I wish they were) it definitely makes the process much smoother and requires less mental gymnastic to achieve something like datum validation.

There are also many advantages in chaining transactions and having the guarantee that there is some transaction happening after yours.

In particular "batching" (but without third parties signing transactions)
where a bunch of different users would send a single witness transaction to some contract and then that contract would be a single witness to a chained transaction.

The above is also possible without third parties but that would imply having multiple users from all around the world having to sign the same exact transaction.

If that was easy we wouldn't have batchers at all today, but of course, that is not the case.

chaining transactions and having a guarantee of that on-chain allows contracts to act like active entities; without requiring an indefinite amount of users to sign the same exact transaction (they would sign theirs and then leave the contract to do its things)