Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[engine] Engine support for Consortium Party Primitives

See original GitHub issue

Support for consortium party primitives in Daml, LF and the engine.

Here is the design document.


A consortium is represented by a Party in the Daml language. The essence of a consortium is that it acts with the combined authority of its members, which are also represented as Parties in Daml. A consortium party will have special rules for validation: say 2/3 of its member parties will be required to validate. Also, the membership of a consortium can change dynamically over time. But neither of these aspects are directly visible or represented at the Daml language level. More importantly, a consortium party is unable to submit to the ledger, because unlike other parties, a consortium party does not reside on any given participant. So without any new functionality it would be impossible to obtain an active-contract signed by a consortium party.

The proposed new functionality is for a Daml-LF builtin which dynamically obtains the authorization of a consortium party when executed in the context of the authorization of the consortium members. From the point of view of the Daml Engine, obtaining the authority of a consortium party requires delegating the question to the enclosing ledger, and recording the answer in the constructed transaction.


The new functionality will be exposed to the user via a new Daml primitive:

withAuthorityOf : [Party] -> Update a -> Update a

The behaviour of withAuthorityOf parties will attempt to place the set of authorizing parties to the given parties, based on the authority of the current authorization context . For more precise behavior, see summary below.


Here is a small example, slightly simplified from the one given in the design document, so that the Accept and Ratify stages are made explicit. It assumes a new primitive withAuthorityOf with the above type.

template HasConsortiumAutority
    consortiumParty: Party
    signatory consortiumParty

template ProposeConsortiumAuthority
    proposer: Party
    accepted: [Party]
    obs: [Party]
    consortiumParty: Party
    signatory proposer, accepted
    observer obs

    choice Accept : ContractId ProposeConsortiumAuthority
      with who: Party
      controller who
      do create this with accepted = who :: this.accepted

    choice Ratify : ContractId HasConsortiumAutority controller proposer
        withAuthorityOf accepted $ do
          withAuthorityOf [consortiumParty] $ do
            create HasConsortiumAutority with consortiumParty

Implementation checklist

  • New Daml primitive: actingAsConsortium
  • (Haskell) compilation in LFConversion.hs
  • (Haskell) type checker
  • (Haskell) .dar encode(decode)
  • extension of LF .proto format
  • (Scala) .dar decode(encode)
  • New LF update expression form UpdateActingAsConsortium in Ast.scala
  • Internal LF parser ExprParser.scala
  • Scala type checker Typing.scala
  • Scala utils: AstRewriter, ExprIterable etc
  • Compilation to speedy PhaseOne.scala
  • New speedy builtin: SBActingAsConsortium in SBuiltin.scala
  • Implementation of SBActingAsConsortium
  • New speedy result/callback in SResult.scala
  • New engine result/callback in engine/Result.scala
  • Support in PartialTransaction.scala and Transaction.scala
  • TX .proto changes

Issue Analytics

  • State:open
  • Created 9 months ago
  • Comments:14 (14 by maintainers)

github_iconTop GitHub Comments

nickchapman-dacommented, Dec 15, 2022

Thanks you everyone for your input. To summarise…

The new operator is not specific to consortium parties, and so should be named more generally. The consensus seems to be for withAuthorityOf.

Choices for: withAuthorityOf

  • A: extent of effect: (scoped vs unscoped) – SCOPED
  • B: on whose authority the request is made (implicit vs explicit) – IMPLICIT
  • C: authority granted (replace vs extend) – REPLACE
withAuthorityOf :: [Party] -> Action a -> Action a

with the semantics as described by Andreas above:

  • If the given parties P are not a subset of the current authorization context C, then Daml engine asks the ledger whether C suffices to authorize the parties in P - C. If the ledger responds no, then interpretation fails with an uncatchable exception.
  • Otherwise, or if the given parties P are a subset of the current authorization context, then the authorization context is set to P for the execution of the given Update.
  • Afterwards, the authorization context is restored to C.

Because the semantics are to replace and not extend the current authority context, the operator can also be used to restrict the current authority.

For validation, we wont need a new node type in the transaction tree to capture exactly where calls to withAuthorityOf are made. Instead we can just record (on the side; per exercise-node) the set of authority-requests made to the ledger during the construction of this node.

An authority-request of the ledger is of the form: C suffices for P-C.

Note specifically that in the case that authority is being restricted (P is a subset of C) then no request will be made to the ledger, and nothing will be recorded in the transaction.

nickchapman-dacommented, Dec 15, 2022

Issue description and example updated.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Tredisec Primitives
TREDISEC is a European collaborative Research and Innovation Action that leverages existing or novel cryptographic protocols and system security mechanisms, ...
Read more >
EigenLayer: A Restaking Primitive - ConsenSys
EigenLayer enables users to restake their ETH and extend cryptoeconomic security to additional applications on the network.
Read more >
WD-P3P-syntax-19981109 - W3C
To provide an example, an interoperability requirement requires all parties support the protocol primitives and their responses.
Read more >
The Best 7 Gaming Engines for 2022 - Incredibuild
The game market is booming. Here are the 7 best game engines to check out in 2022, including free game engines, and 2d...
Read more >
Omniverse Glossary of Terms
Curve primitives based on the UsdGeomBasisCurves API. ... “Compute graph” is a synonym for OmniGraph, an engine for programmatically manipulating scenes ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found