CPS-0015? | Intents for Cardano

[michaelpj]

We describe a family of issues around “intents” on Cardano. We do some basic analysis on the problem space, and suggest some high-level areas for investigation.

---

Rendered on author's fork

[rphair]

@michaelpj @polinavino I've added this to introduce in the agenda of our CIP meeting in a week's time (https://hackmd.io/@cip-editors/84). Nearly our entire agenda is Plutus at this point so your attendance would be welcome for a number of reasons. 🙏

[vlasin]

Let me point out that implementating intents is already technically possible on Cardano without changes to the Ledger. It can be done with the help of a hypothetical smart contract wallet where all user UTxOs are locked by Plutus scripts.

1. A user can submit an intent to the intent-processing server. The message would also contain a signature on the hash of the user's intent.
2. The server can then construct, sign, and submit the transaction that satisfies the user's intent.
3. The wallet's script is used to validate that the transaction satisfies the user's intent and that the user's intent is signed by the user's private key.

The problem with the above approach, in my opinion, lies mostly in its practicality and efficiency. In particular, the wallet's script needs to run for each of the affected UTxOs even though it verifies the same exact statement. There are a number of other proposals that could deal with the efficiency problem if implemented:
https://github.com/cardano-foundation/CIPs/tree/master/CIP-0069
https://github.com/cardano-foundation/CIPs/blob/arbitrary-script/CIP-XXXX/README.md
https://github.com/fallen-icarus/CIPs/tree/maybe-datum/CIP-%3F%3F%3F%3F

[michaelpj]

@vlasin I tried to gesture in that direction in the CPS here: https://github.com/cardano-foundation/CIPs/pull/779/files#diff-5a0dba075d998658d72169818d839f4c63cf105e4d6c3fe81e46b20d5fd3dc8fR45

I should elaborate!

I agree that practical considerations dominate here. Fundamentally, any on-chain solution requires paying the costs necessary for the network to reach consensus on that state, which may be both unnecessary and too costly. We need consensus on the final change, it's not clear that we need consensus on the proposal. Transaction fees and overhead is what made the Stellar DEX not function at large trading volumes - I think this is ultimately unsurprising.

[rphair]

@michaelpj thanks for introducing this & related CIP #780 at the meeting today; both agreed all around as candidates (though expecting a long gestation period) so assigning numbers.

Since the scope might be clear at this point I hope we can confirm a category of Tools (#779 (comment)) or indicate that it might be narrower (to be determined) and therefore leave the category open... though it will be helpful for review it we can assign an initial category as usual.

Please update the directory name & the link to your proposal in the OP 🙏

[AndrewWestberg]

Linking to a previous discussion in a working group on this topic.

input-output-hk/Developer-Experience-working-group#47

[polinavino]

Here is an idea about how to introduce a new kind of intent that is fulfilled within a valid validation zone : the intent to spend a certain output. This would allow us to implement the following kind of protocol for Light Clients that has the service provider (SP) build the transaction for the (LC) rather than supply data for the LC to do it themselves. This comes with a way to ensure that the SP is compensated, but only if they build a valid transaction.

This requires us to build on top of the validation zones infrastructure (in-progress implementation specifically for the babel fees/swaps usecase here )

This also requires an intents-constructing API (an "intents language"), which can be as simple or fancy as we want. E.g. it can support requesting transactions that

• pay a value from key to key
• mint an NFT
• make an offer/trade on a DEX

Ledger changes :

• the transaction body has two new fields ( i) noRefInputs : Map Ix TxOut (which are the outputs corresponding to the inputs the transaction would be spending if it could look them up in the actual UTxO state) and ( ii) matchingRefs : Map TxIn TxIn , which specify the output references in the UTxO that the outputs have to match to, and are indexed by the transaction that is requesting to spend the no-input references

• the UTxO state is a pair of a UTxO and Intents : Map TxIn TxOut

• during the validation of a zone, the Intents map is populated with the noRefInputs of transactions in the zone (the TxIn index is constructed from the TxId of the transactions that is adding the entry, and the Ix of that entry)

• an entry in Intents is removed when another transaction provides the TxIn corresponding to the TxOut for the transaction ID and index specified in the entry key, and the full UTxO entry is verified to exist in the UTxO set. That entry is also then removed from the UTxO set.

• once the entire zone is applied, the Intents structure must be empty for a zone to be valid

Off-chain infrastructure :

• Intents language

• support for transaction dissemination

Protocol :

1. LC constructs an intent and sends it to SP

2. SP constructs a transaction tx that satisfies the intent sent to them, and includes in that transaction a payment made from LCs key to the SP

• must include at least 1 input from their own wallet (to satisfy the ledger requirement without revealing too much to the LC)

3. SP removes from tx any output references whose associated outputs contain scripts, or ones that belong to the LCs keys, and instead adds the output data associated to those references to noRefInputs

4. SP sends tx to LC to sign

• it must also send the resolved output for any “regular” inputs, and pre-image for script integrity hash

• this is needed for the LC to be able to check the scripts

5. LC checks the transaction to make sure it satisfies its intent, runs the scripts, signs it, and sends it back (if OK)

• note that LC cannot check validity, but in the UTxO model, an invalid transaction cannot be applied, so there is no danger of something bad happening on-chain, and the SP is incentivized to construct only valid transactions in order to get paid

• LC does need to check the scripts, and is able to do that just from the received data

7. SP constructs a transaction that resolves the “missing inputs” by constructing another transaction tx' which provides the required output references in the matchingRefs field

8. SP submits a validation zone with both transactions to the Cardano network

Possible issues

• possibility of a spam attack (but not on the Cardano network), i.e. LCs sending multiple unfillable requests to SPs off-chain

this is a problem for any type of request system

could have some sort of key registration system, and require LCs to sign their requests

• not compatible with current versions of Plutus, since TxInfo would be constructed differently (however, probably OK for versions written specifically for this)

• if an intent is submitted to multiple SPs, only the one whose response to the LC gets submitted first (alongside their own transaction fulfilling it) gets paid

we might even have to worry about another SP intercepting, dismantling, and re-constructing the transaction built by an SP, and changing the payment made to one that is to themselves

hopefully, that it’s about as expensive as constructing the transaction from scratch

[rphair]

@polinavino - would you the best person to advocate for & update this PR and #780?

1 - Whatever is in the "babel fees/swaps usecase here" is already in the Use Cases, but this mechanism for Light Clients is new... could you add a section for it at the appropriate level of detail for the CPS? Also if the Light Clients idea matches some other project under development, I imagine it would be filled out into a CIP at some point.

2 - Your earlier suggestion of an Intents language (#779 (comment)) was mainly why this CPS was classified as Tools (rather than Ledger) (#779 (comment)) but there's still no detail in the CPS about what would be expected from this language... would you be willing to contribute this?

Editorially I think this document and proposal #780 need an "owner" and I would be happy to hear that we can rely on you for current & future updates, at least until these are merged in whatever state is confirmed to be useful for further development.

[polinavino]

I will likely be the one to advocate for this, but I will have to work on the CPS and think about your other comments on this more next week!

[polinavino]

After some discussion with other folks working on light clients, we decided that we will instead attempt to use fancy cryptography to implement a similar protocol (co-constructing a transaction using 2PC) fully off-chain. So , for the time being I will not pursue this.

[rphair]

@Ryun1 @Crypto2099 - we have lost the push behind this with MPJ leaving, and I believe with @polinavino committing to a different approach this is effectively Deprecated & so I'm marking as such.

@lehins @fallen-icarus - as advocates of varying methods in this space, if you would have any other suggestion than deprecating please let us know. I would prefer to see this merged as-is... after giving it an explicit Inactive status (perhaps Inactive (lack of advocacy)) to avoid too much duplication of effort the next time the community manifests some other intent-like transaction paradigm.

If this would be OK all around I'll make the necessary cleanup to this PR and move it from Deprecated to Last check in time for some future meeting... an unusual workflow but more realistic than the current tag 'Waiting for Author`.

[rphair]

Effectively deprecated in favour of currently pursued alternatives already documented above.