Dynamic Participation Through a new EntryDeposit Action

[paluh]

I propose extending Marlowe language to include entry deposits which would introduce an Address value within the scope. The following is an initial sketch of this proposal.

Such an enhancement could effectively address the issue of dynamic address assignment and dynamic role token distribution simultaneously, with Marlowe handling the distribution of the role token to a dynamically assigned address variable.

The logical action to facilitate this assignment and enable users to engage with the Contract is a deposit. Not only does this appear to be a natural inclusion, but it also embodies a financial commitment. In contrast, allowing an anonymous party to join by making a IChoice or INotify in the Contract seems impractical (no commitment, any bad actor can choose anything).

The main changes would affect the types associated with the deposit action and input:

data Deposit
 = PartyDeposit AccountId Party Token Value
 | EntryDeposit AccountId AddressId Token Value

data IDeposit
  = IPartyDeposit AccountId Party Token BigInt
  | IEntryDeposit AccountId AddressId Ledger.Network Address Token BigInt

We also need to modify the Party structure slightly to reference address variables:

type AddressId = String

data Party
  = Address Network Ledger.Address
  | UseAddress AddressId
  | Role TokenName

We should add also a address scope to the state:

data State = State
  { accounts :: Accounts
  , addresses :: Map AddressId (Ledger.Network, Address) 
  ...

In addition, we must change the Action and InputContent type. Let's skip them for nwo.

The semantics of the EntryDeposit action can be summarized as follows:

• IEntryDeposit binds an AddressId variable to a specified value (Ledger.Network and Address) in the addresses state map.
• If we want to maintain the current no-failure evaluation strategy, as opposed to failure reporting with a finalization handler (which I'm in favor of), we could essentially turn all Pay and PartyDeposit operations into noops.

[paluh]

P.S.
A partial replacement for this proposal till it matures and is possibly included can be a tiny Plutus glue described here: input-output-hk/marlowe-cardano#639

[hrajchert]

As you hint in this message, the underlying feature request is "Anonymous participant" or "Role distribution strategies".

I do agree that of the three possible Actions, Deposit is the one that has the "strongest commitment", because anybody can do a Notify as long as the observation is true (so they are anonymous right now), and anybody could choose something. For both options you only need to pay the transaction fee. But be aware that you can also deposit native tokens which might not have an intrinsic value, so the same reasoning applies to the three Action types: the idea of assigning a Role to someone should be contract dependent. In short, I wouldn't necessarily restrict the "Anonymous participant" or "Role distribution strategies" to a Deposit action, instead offer some warnings, best practices or contract explanations that hint that anonymous roles should be handled with care.

With that introduction, I'm not sure if the Core Language needs to change to support this feature, or if it can be resolved with some instantiation parameters.

If we were to change the language, I think the main target could be the Party constructor

data Party 
 = Address Address
 | Role RoleName
 | DynamicRole RoleName -- We could potentially include a PolicyDSL to the roles. 
                                            -- Specially useful if we end up adding a Mint construct

Role and DynamicRole would be essentially the same for all aspects, except that the first Action that involves a DynamicRole as the source would mint and give the role. The main reason to distinguish both constructs is that you could offer some warnings if a DynamicRole is a target before it was assigned, and to set up expectations for the contract developer.

As part of the Runtime metadata when creating the contract or the PolicyDSL I mentioned in the data constructor, we could indicate that a DynamicRole also needs to deposit some minADA/minNativeToken (for other blockchains).

[paluh]

Thanks for quick response. I should emphasis more that the main point of this proposition is to implement a practical way to introduce dynamic participants into the contract. This requirement is driven by real life use cases (open swap offering, open auction with 100 rounds - with address variable shadowing these should be pretty simple Marlowe contracts implemented in a constant space).

Going back to the discussion.

In short, I wouldn't necessarily restrict the "Anonymous participant" or "Role distribution strategies" to a Deposit action, instead offer some warnings, best practices or contract explanations that hint that anonymous roles should be handled with care.

As you already noticed Deposit of 0 value is noop so we can easily implement strategies like:

• "anonymous participant on Notify" by Case (Notify ..) (AnonymousDeposit .. 0 ...)
• "anonymous participant on choice" by Case (AnonymousDeposit AccountId "new-participant" 0 ..) (Choice ".." (UseAddress "new-participant"))

I don't think that we have to implement these exotic cases in the language and warn but rather make them hard to achieve but still feasible.

With that introduction, I'm not sure if the Core Language needs to change to support this feature, or if it can be resolved with some instantiation parameters.

We are strictly trying to solve ad hoc joining to the contract without up front knowledge of the participant list here so any kind of generation or parametrization is specialized before reaching the block chain is not solving the same problem.

Role and DynamicRole would be essentially the same for all aspects (..)

I'm not sure what is the semantics of DynamicRole (could you please clarify?). Anyway, please note that with my proposed change dynamic role tokens can be implemented directly in Marlowe (relevant small request for the Runtime):

• We mint and output (some) role tokens to Marlowe. In other words Marlowe could store role tokens in it's existing account system.

• We use AnonymousDeposit so at some point we introduce a new address to the scope.

• We can use this address and pay to it role token.

I want to also emphasis that Role tokens come at a cost and significant usability price - payouts are not instant, withdrawals are extra steps, roles are extra primitives / tokens in wallets etc. That is why I thinik using addresses as a baseline is much more flexible solution.

As part of the Runtime metadata when creating the contract or the PolicyDSL I mentioned in the data constructor, we could indicate that a DynamicRole also needs to deposit some minADA/minNativeToken (for other blockchains).

I'm not sure if I follow - could you please provide more details what do you mean (sketch of the protocol?).

[hrajchert]

I wasn't talking about Deposit 0, I was talking about Deposit 1_000_000_000_000n xcoin, where xcoin could have no market value, so even if you deposit a billion of those, they would be worthless.

I'm not sure I follow the Deposit = PartyDeposit | AnonymousDeposit DSL... is that then going to be embedded inside the Action type, the Case type or the Contract type?

What I'm suggesting with the DynamicRole construct is to only modify the Party type, which as far I can tell, should not invalidate any of the current formalization. By adding a new construct we can distinguish that we should treat Role and DynamicRole a little bit different at the minting and initial transfer of the role token.

If possible (have to check) we could mint all tokens (normal and dynamic) at contract creation. The Role ones would be transferred/assigned on creation as currently, but the Dynamic ones would stay in the contract (if not possible we might want to defer the minting).

The Dynamic role would be assigned (or mint-assinged) when submitting an Input for an Action that has the source as a DynamicRole. That way we can have Anonymous/Dynamic participants.

In the previous example, the DynamicRole party1 differs from the normal Role party2 in which the first one is allowed by anybody that makes the deposit, while the second one is assigned at contract instantiation. The DynamicRole party3 can be claimed by anybody that makes the choice. Even if making a choice is a lower commitment than making a deposit (as long as you are depositing worthy tokens), having a dynamic role claimable via choice could be useful for contracts like air-drops.

The other thing that I said regarding warnings is that this should provide a warning because you are giving assets to a role that hasn't been defined in the execution path.

We should also add a warning if you have a Role and a DynamicRole with the same name