CIP-0118? | Nested Transactions

[polinavino]

We propose a set of changes that revolve around validation zones, a construct for allowing certain kinds of underspecified transactions. In particular, for the Babel-fees usecase we discuss here, we allow transactions that specify part of a swap request. A validation zone is a list of transactions such that earlier transactions in the list may be underspecified, while later transactions must complete all partial specifications. In the Babel-fees usecase, the completion of a specification is the fulfillment of a swap request. We discuss how validation zones for the Babel fees usecase can be generalized to a template for addressing a number of use cases from CPS-15.

---

📄 Rendered Proposal

[rphair]

thanks @polinavino ... really happy to see the continuation of this work. I'm marking the title with the obligatory ? because until merged the number (or its assignment at all) cannot be certain. Also I'm marking the prior version Likely Deprecated and will close as such with your confirmation:

• CIP-0118? | Validation zones #780

cc (for continuing review from the old proposal) @Quantumplation @fallen-icarus - p.s. cc (re: Rationale ["towards better design"]) @AndrewWestberg

[rphair]

I believe it is proper for this to be a separate PR from the first one, though that should be confirmed by other CIP editors today (https://hackmd.io/@cip-editors/93 - cc @Ryun1 @Crypto2099). Given the significance of the revision, the commit history in this case I think is more important than the discussion history & hopefully any prior discussion points will be summarised by previous reviewers here (@fallen-icarus @Quantumplation).

[rphair]

For consistency with other CIPs (mainly for review in parallel with 100+ others) this section needs to be broken into Acceptance and Implementation ... I guess since it refers to testing functionality then it would be on the Implementation path.

When done sifting material around in this section it will also help for these items to be GitHub formatted tickboxes (- [ ]) but I am not going to be pedantic about it especially at this stage.

[polinavino]

Sounds good, will do that later today!

[rphair]

(see #862 (comment))

[rphair]

(see current review: #862 (review))

[rphair]

@polinavino @lehins we didn't rush to merge this in Last Check at our CIP meeting today because @Ryun1 has still been looking forward to confirming it & said he hopes to in the near future.

In the meantime, @fallen-icarus pointed out that there's been a public statement about "how the older scripts
would be updated in the new era" before & after this change. From meeting discussion it sounded like something we should confirm is in the CIP itself — or add, if it isn't there — so could you please point this out or make whatever addition you think we need to make the document complete before merge?

[lehins]

@fallen-icarus pointed out that there's been a public statement about "how the older scripts
would be updated in the new era" before & after this change.

@rphair This is very recent development. It was just last Tuseday that I came up with this potential feature that Nested Transactions would let us do. We had a Ledger meeting yesterday where we discussed it and everyone seems to be very much ion favor. It would require minor change to the CIP, which I will try to submit tomorrow, at the latest beginning of next week.

In the nutshell, it could allow us something that we were never able to do before: it would allow us in a slightly limited form to use PlutusV1-V3 scripts in a transaction with newer features that are yet to be introduced in Dijkstra and beyond.

[lehins]

@rphair, @polinavino and @fallen-icarus
Here is a PR with promised changes that describe new cool use cases that Nested Transactions also bring to the table: polinavino#3

I am sure community will find many more use cases, which we can't think of at this moment. I am quite excited about this.

[rphair]

@lehins that's good to hear - we can merge this as soon as we have a chance to accommodate @Ryun1's feedback or, at the latest (and pending any strong objections), at the next CIP meeting in the 1st week of the New Year: https://hackmd.io/@cip-editors/125

[Ryun1]

There is a min-swap.png‎ included in the directory but I don't see it referenced via the README, perhaps it is not used?

[rphair]

min-swap.png‎ included in the directory but I don't see it referenced via the README, perhaps it is not used?

... it's one of the original illustrations; yes we should definitely expire that file before merging :) & wait for check-ins about the other items before any Last Check merge at the CIP meeting today (@lehins I guess this will depend on whether @polinavino is able to update the branch in time; otherwise maybe we can merge by online agreement after the meeting later in the week).

[perturbing]

I took the liberty to merge some of your suggestions, @Ryun1 (as well since @lehins gave 👍 on the import changes).

In case @polinavino is not in time, we can always change the target branch to an intermediate branch where we can then remove the image.

I would love to start the new CIP year with an empty Triage/Review and Last Check 🎉

[rphair]

@perturbing the GitHub UI let me "delete" the old file from @polinavino's branch (though not from this PR): so we are ready to merge at the meeting now.