Can I run a script on Daml Hub which will act as multiple parties?

Questions
, ,
1

G-d willing

Hello,
I would like to run a script on Daml-Hub which will create a contract as bob and then create another contract as Alice.
How can I do that since the access token file the daml script command accepts (as far as I know) only one JWT

2

Unfortunately Daml Hub does not currently have support for issuing tokens that authorize a bearer to communicate as multiple parties simultaneously.

There are some workarounds you can employ:

  • Run two scripts at the same time, one with each token. This more closely resembles how users will use your application, as under normal circumstances “Alice” and “Bob” couldn’t anyway be logged in using the same token.

  • Use a “setup” template. You could create a contract that exists solely to create a testing scenario, where you gather authorizations from various parties, and then exercise a choice with the authority of all parties.

Depending on the workflow you are trying to simulate, it may anyway be a better design to encode your multi-party workflow directly in Daml, and act as a single party. The process of splitting your logic out into two scripts might highlight issues in your app where you’re somehow reliant on tokens that wouldn’t be generated under real-world usage.

Thanks for using Daml Hub!

1 Like
3

Hi @dtanabe,
Thanks for your answer.
However, executing 2 separated scripts is not relevant since my script is using the submitMulti.
Basically, the only thing the script is doing is one submitMulti command.
Just for verification, I am doing submitMulti [bob] [alice], and I am providing the access token of bob.
The result is:

Exception in thread "main" com.daml.lf.engine.script.ScriptF$FailedCmd: Command submit failed: PERMISSION_DENIED: An error occurred. Please contact the operator and inquire about the request <no-correlation-id>

Is there a way to do it?

4

Unfortunately there isn’t a way to do that at the moment.

But do keep in mind that using submitMulti in this way simulates activity that couldn’t happen in the real world, since Ailce and Bob are separate people. If your flow relies on the authority of two distinct users without a propose-accept step somewhere, there may be a problem with your model.

5

G-d willing

Okay, thank you @dtanabe for that, so there is no solution the way I see it.
But, on another thought, let me describe my situation and let me know if you have a workaround for me.
Let’s say I have the following contract:

template A
  with
    sigParty : Party
    obsParty : Party
  where
    signatory sigParty
    observer obsParty

    choice ExecuteSubmitMulti : ContractId B
      with 
        thirdParty : Party
      controller thirdParty
        do
          create B with ..

template B
  with
    thirdParty : Party
    sigParty : Party
  where
    signatory thirdParty, sigParty

    choice TestChoice : ()
      controller thirdParty
      do
        return ()

Now let’s say I have 3 parties, Alice, Bob & Charlie and I do the following

aContractId <- submit Alice do create A with 
  sigParty = Alice
  obsParty = Bob

I have on Daml-Hub the instance of template A with Alice & Bob.
my task is to test the TestChoice on template B with Charlie’s authorization. So first, I need to create template B. Charlie must not be a party on contract A. So, the only way for me to create template B is to have a script that does the following: (“act as” Charlie and “read as” Bob)

  bContractId <- submitMulti [charlie] [bob] do 
    exerciseCmd aContractId ExecuteSubmitMulti with thirdParty=charlie

Then, I can do my testings on bContractId.
Is there a solution you can think of?

6

@dtanabe

We need to clarify that if an entity controls more than one Party on a Daml Hub ledger then this workflow is possible if you want to add readAs = [public] to any of your Party’s.

In particular, the damlhub-cli ledger multipartyToken command can do this.

1 Like