Enhancing Marlowe Runtime to execute arbitrary Plutus alongside Marlowe

[bwbush]

Enhancing Marlowe Runtime to execute arbitrary Plutus alongside Marlowe

The power of Marlowe can be significantly enhanced by executing carefully crafted Plutus scripts along side it in the same transaction. Example use cases include . . .

• Minting tokens in conjunction with a Marlowe contract.
• Allowing arbitrary addresses to join a Marlowe contract after it is already in progress. (See the "Open Roles" discussion.)
• Upgrading a Marlowe contract by continuing it to a new contract.

Typically, the Plutus script would inspect the Redeemer and/or Datum for the Marlowe contract's application of input or payout. The script's logic would validate its spending depending upon whether conditions on the MarloweData, MarloweTxInput , and/or ScriptContext were met.

Running Plutus alongside Marlowe in no manner invalidates the safety guarantees inherent in Marlowe. The Plutus validators that run alongside Marlowe would generally be quite small, and hence easier to audit.

Requirements for running Plutus with Marlowe

1. Another Plutus script may only run in transactions where the Marlowe contract does not make external payments to addresses or roles. See Constraint 20 of the Marlowe Cardano Specification, which prevents double-satisfaction attacks.
2. Plutus execution costs must be minimized because a Marlowe+Plutus transaction could easily exceed them. The only latitude that Marlowe Runtime has regarding this is parsimonious coin selection, since coin selection directly impacts the size of the ScriptContext and hence the Plutus cost of deserializing and accessing that for each validator that executes in the transaction.
3. Runtime should allow the specification of extra transaction-building constraints that the Plutus script requires. In general these are as follows:
   1. Specification of a spending or minting script.
   2. Inclusion of a particular UTxO as transaction input, with its Datum and Redeemer if that is a script input.
   3. Satisfaction of a value constraint on transaction inputs.
   4. Inclusion of a particular transaction output, with its address, value, and possibly its Datum.
   5. Minting of a specified value.
   6. Satisfaction of a particular POSIXTime validity range.
   7. Inclusion of signatures by particular public keys.
   8. Inclusion of a particular reference script UTxO as reference input.
4. Eventually, Marlowe metadata standards should support specifying which Plutus scripts will run in which parts of the Marlowe AST (abstract syntax tree) and what the corresponding constraints will be.
5. Ideally, the Marlowe Runtime safety checks should account for the presence of auxiliary Plutus scripts.
   1. All transaction should be tested to make sure they fall below the execution-cost limits.
   2. Transactions that run Plutus and Marlowe, where Marlowe makes external payments, should be flagged as invalid.

Only the first three items are essential for an initial implementation.

Expressiveness of the existing constraint specification

As of v0.0.3 of Marlowe Runtime, the transaction builder can handle the following constraints (see Language.Marlowe.Runtime.Transaction.Constraints):

-- | Describes a set of Marlowe-specific conditions that a transaction must satisfy.
data TxConstraints v = TxConstraints
  { marloweInputConstraints :: MarloweInputConstraints v
  , payoutInputConstraints :: Set (Core.PayoutDatum v)
  , roleTokenConstraints :: RoleTokenConstraints
  , payToAddresses :: Map Chain.Address Chain.Assets
  , payToRoles :: Map (Core.PayoutDatum v) Chain.Assets
  , marloweOutputConstraints :: MarloweOutputConstraints v
  , signatureConstraints :: Set Chain.PaymentKeyHash
  , metadataConstraints :: Core.MarloweTransactionMetadata
  }

Thus, it lacks the capability to express the following Plutus-related constraints:

• Specification of a spending or minting script.
• Inclusion of a particular UTxO as transaction input, with its Datum and Redeemer if that is a script input.
• Satisfaction of a value constraint on transaction inputs.
• Inclusion of a particular transaction output, with its address, value, and possibly its Datum.
• Minting of a specified value.
• Satisfaction of a particular POSIXTime validity range.
• Inclusion of a particular reference script UTxO as reference input.

Furthermore, the constraint framework is not exposed to clients via the marlowe-proxy service, thus making it impossible for marlowe-runtime-cli or marlowe-web-server to include Plutus in a Marlowe transaction.

Proposed design for running Plutus with Marlowe

Transaction constraints

There are at least five approaches to including extra transaction constraints in Marlowe Runtime:

1. Add more constraints directly to the TxConstraints type.
2. Append additional constraints in "extra" field of TxConstraints.
3. Create a generic constraint DSL for transaction building, and reformulate TxConstraints to use that directly or build upon it.
4. Enable clients to "perform surgery" (i.e., add arbitrary data directly) on the provisional TxBodyContent before coin selection and balancing occurs in Marlowe Runtime.
5. Refactor Marlowe Runtime's transaction building to use another transaction builder such as Adrestia.

We propose the second approach because it might be cleaner conceptually and more convenient to keep the extra constraints somewhat separate from the Marlowe-specific ones. For example, keeping them separate facilities having a client supply them as a Set ExtraConstraint without interfering with the existing TxConstraints being generated as the Marlowe constraints are built.

data TxConstraints v = TxConstraints
  { ..
  , extraConstraints :: Set ExtraConstraint  -- This could be a list, so as to avoid requiring an `Eq` instance for `ExtraConstraint`.
  }

data ExtraConstraint =
    SpendUtxo
    { input :: Chain.TransactionInput
    , witness :: Maybe Cardano.Api.ScriptWitness
    , reference :: Maybe Chain.TxOutRef }  -- Logically, a reference UTxO is meaningless unless a witness is also present.
  | SpendValue
    { value :: Chain.Assets
    , exactTokens :: Bool }  -- Perhaps the validator would reject the presence of extra native tokens (useful for coin selection).
  | Pay
    { output :: Chain.TransactionOutput
    , exact :: Bool }  -- Perhaps the validator would accept extra value in the output (useful for minimizing the number of outputs when balancing the transaction).
  | Mint
    { value :: Chain.Tokens
    , witness :: Map Chain.PolicyId Cardano.Api.ScriptWitness }
  | During { interval `Plutus.V2.Ledger.Api.POSIXTimeRange` }  -- Perhaps not needed, because the client can specify this otherwise.
  | Signature { pkh :: Plutus.V2.Ledger.Api.PubKeyHash }  -- Perhaps not needed, because it is redundant with `TxConstraints.signatureContraints`.
    deriving (Eq, Show, FromJSON, ToJSON)

Client API

The marlowe-web-server client's REST API would include optional constraints in the JSON payload for creating Marlowe contract, applying inputs to them, or withdrawing from them. Storing this information in the HTTP header is impractical because of size limits on headers.

The marlowe-runtime-cli client would include an optional flag --extra-constraints-file for a JSON file containing the serialized constraints, once again for Marlowe creation, input application, and withdrawal.

[jhbertra]

I'm on board with the basic idea of this. However, I'd reformulate the ExtraConstraints type to be a record of sets instead of a sum type (similar to TxConstraints) so that it can have a Monoid and Semigroup instance, allowing it to be used in a Writer monad directly. I'd also like to see a proposal for the overall rules of resolving the different parts of the tx body and how potential constraint conflicts would be handled.

[bwbush]

Yes, reformulation is fine. This proposal is mostly just to get us thinking concretely about this. We can follow up with a cleaner detailed design.