CIP-???? | Multi-arity UPLC lambda node

[michele-nuzzi]

This CIP proposes a new node for an uplc tree.

The node is intended to have the same effect of n consecutive lambda nodes for 1/n the cost. Improving contracts in all measurable metrics (size, cpu, memory)

(See rendered proposal in branch)

[michele-nuzzi]

expect typos

[michele-nuzzi]

@effectfully

[rphair]

#1043 (comment): expect typos

@michele-nuzzi does this mean that you are going to fix them, or that you are asking editors to fix them? 😅

Also please remove the template scaffolding when you submit CIPs... out of courtesy mainly to editors but also to reviewers who will be reading your Markdown, and so that your initial review & commit history isn't overwhelmed next time by trivial change requests.

[rphair]

Suggested change

	Title: multi-arity uplc lambda node
	Title: Multi-arity UPLC lambda node

All CIP titles, like all titles, are capitalised. (Since these titles can also be considered phrases or sentences, it's not necessary to capitalise every word... some authors do & some don't.)

[rphair]

Suggested change

	<!-- Existing categories:
	- Meta | For meta-CIPs which typically serves another category or group of categories.
	- Wallets | For standardisation across wallets (hardware, full-node or light).
	- Tokens | About tokens (fungible or non-fungible) and minting policies in general.
	- Metadata | For proposals around metadata (on-chain or off-chain).
	- Tools | A broad category for ecosystem tools not falling into any other category.
	- Plutus | Changes or additions to Plutus
	- Ledger | For proposals regarding the Cardano ledger (including Reward Sharing Schemes)
	- Catalyst | For proposals affecting Project Catalyst / the Jörmungandr project
	-->

(remove template scaffolding)

[rphair]

Suggested change

<!-- A short (\~200 word) description of the proposed solution and the technical issue being addressed. -->

(remove template scaffolding)

[rphair]

Suggested change

	This CIP proposes a new node for an uplc tree.
	This CIP proposes a new node for an UPLC tree.

If there's any context where lowercase makes sense, please let reviewers & editors know... e.g. if it's a symbol (in which case it would be uplc).

[rphair]

Suggested change

<!-- A clear explanation that introduces the reason for a proposal, its use cases and stakeholders. If the CIP changes an established design then it must outline design issues that motivate a rework. For complex proposals, authors must write a Cardano Problem Statement (CPS) as defined in CIP-9999 and link to it as the `Motivation`. -->

(remove template scaffolding)

[rphair]

Suggested change

	are increasingly common in uplc contracts.
	are increasingly common in UPLC contracts.

... et cetera, please, wherever this term is used...

[rphair]

Suggested change

<!-- The technical specification should describe the proposed improvement in sufficient technical detail. In particular, it should provide enough information that an implementation can be performed solely on the basis of the design in the CIP. This is necessary to facilitate multiple, interoperable implementations. This must include how the CIP should be versioned, if not covered under an optional Versioning main heading. If a proposal defines structure of on-chain data it must include a CDDL schema in its specification.-->

(remove template scaffolding)

[rphair]

Suggested change

	<!-- The rationale fleshes out the specification by describing what motivated the design and what led to particular design decisions. It should describe alternate designs considered and related work. The rationale should provide evidence of consensus within the community and discuss significant objections or concerns raised during the discussion.
	It must also explain how the proposal affects the backward compatibility of existing solutions when applicable. If the proposal responds to a CPS, the 'Rationale' section should explain how it addresses the CPS, and answer any questions that the CPS poses for potential solutions.
	-->

(remove template scaffolding)

[rphair]

Suggested change

	### Acceptance Criteria
	<!-- Describes what are the acceptance criteria whereby a proposal becomes 'Active' -->
	Included in Plutus V4.
	### Acceptance Criteria
	Included in Plutus V4.

(remove template scaffolding)

@michele-nuzzi a little more effort here would be appreciated about how this change will be considered by the community & currently responsible architects:

• Will anyone provide a proof of concept for this?
• Will you & your team do this, and/or have they done any other investigations about it?
• Do you have any implementations planned that would benefit from this feature being available in V4?

[rphair]

(remove template scaffolding AGAIN)

Suggested change

	### Implementation Plan
	<!-- A plan to meet those criteria or `N/A` if an implementation plan is not applicable. -->
	N/A
	<!-- OPTIONAL SECTIONS: see CIP-0001 > Document > Structure table -->
	## Copyright
	<!-- The CIP must be explicitly licensed under acceptable copyright terms. Uncomment the license you wish to use (delete the other one) and ensure it matches the License field in the header.
	If AI/LLMs were used in the creation of the copyright text, the author may choose to include a disclaimer to describe their application within the proposal.
	-->
	This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).
	<!-- This CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0). -->
	### Implementation Plan
	N/A
	## Copyright
	This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).

[Unisay]

after reading a few facts:

• such patterns are common;
• they are used for X, Y, Z...

I struggle to see how this answers the question "Why is this CIP necessary"?
What is the problem being fixed?

[Unisay]

Knowing that CIP is backwads compatible is useful,
but how are the CIP goals achieved? And what are the goals?

[rphair]

@michele-nuzzi the feedback from yesterday's CIP meeting is that the document "doesn't address the need for the proposal very well" - and also that we will need responses to the reviews above to keep this moving through the process. Marking this Unconfirmed for now & likely other editors will post details about the feedback above.

[Crypto2099]

There seems to be a lot missing here, not least of which is actual estimates of what sort of performance or cost benefits could be possible by taking the time and money necessary to implement this into the system. Of particular interest would be attempting to identify the average arity (?) in use by most functions in "modern" contracts that are being written today to at least get a napkin math estimate of our space savings if not estimates of CPU and memory optimization as well.

[effectfully]

Apologies that it took me forever to get to this CIP.

This is a reasonable proposal and we're going to investigate something along these lines. I do agree very much agree that introducing multi-lambdas would improve all of CPU, MEM and size. Particularly if paired with multi-applications.

There's a very non-trivial issue of costing however. It absolutely isn't going to be 1/n cost for asymptotically the same amount of work. We can make lambda applications faster by a constant, but we cannot make them faster asymptotically with what's proposed here on in general. So that leaves us with an awkward situation where a new AST node is supposed to consume the amount of budget proportional to its content, unlike all currently existing AST nodes.

So this isn't just a matter of adding a new AST node, we have to introduce non-trivial changes into how scripts are costed. Is it worth it? As a standalone optimization right now it isn't in my opinion, because we have more promising ways of optimizing scripts (BuiltinValue and faster processing of Data, for example). And in my experience n-ary binders are also a pain in the ass to deal with.

However at some point in future we are likely to introduce n-ary constructs into the AST anyway. I'm probably gonna need multi-lets for speeding up processing of Data for example. Should I just make those multi-applied multi-lambdas? Maybe, but I need overloading for them like we overloaded case work with both SOPs and values of built-in types -- and overloading multi-lambdas this way seems weird.

Anyway, I'll get to multi-lets soon and I'll make sure to keep multi-lambdas in mind.

Meanwhile, @SeungheonOh is gonna try adding multi-applications without multi-lambdas. Maybe that's how will sneak multi-lambdas in.

As for the content of the CIP itself, it's kinda on the shorter side. Which I'm personally perfectly fine with, so I'm approving the CIP, but I don't know what the "official position" on underspecified CIPs is. I believe we should allow those.

Thank you for the CIP and again sorry for taking so long to review it.

[rphair]

Thanks @effectfully & no worries since there wasn't any pressure to progress this CIP. The default position for underspecified CIPs is not to give them a number yet & ask the author (cc @michele-nuzzi) to elaborate: as @Crypto2099 already has in #1043 (comment) along with useful points for that elaboration. Your theoretically positive review will be of practical use if & when the writing moves forward & I'll mark this Waiting for Author in the meantime.