Public Party and reference data

Questions
1

The concept of public party on DABL can make a contract visible to all parties on that ledger. Is there a similar concept on DAML level? Something that everyone on the ledger can lookup and fetch without been given permission explicitly. It can be a useful thing when one wants to store the reference data on the ledger but doesn’t want to go through the hassles to manage them when other party joins or quits. Things like a legend or a holiday calendar.

2 Likes
2

There’s no such feature in DAML the smart contract language. The problem is data availability:

Imagine a DAML ledger with full sub-transaction privacy. There is no central place where all data is stored. If Alice creates a contract visible to “all”, and later a new node joins the network, there is no place for that node to “pick up” that data.

We therefore decided to handle “public” data through parties. There’s a discussion on the solution in Query and Create Exercise as multiple parties. That feature should be rolled out in one of the releases early next year.

TL;DR: You’ll be able to use more than one party at a time during submission. So you can model public as a party and issue everyone tokens that allow them to read as that party. You still have the data availability problem, meaning the public party has to be hosted on every node where you want that data to be available. If you are on a multi-node network that means hosting the public party on all participants. If that’s not possible, the workaround is to have a public party per node, and then essentially make each node an observer on “public” contracts.

3 Likes
3

If you are on a multi-node network that means hosting the public party on all participants

@bernhard can you elaborate on how this can be achieved in a Canton multi-node setup? Assuming you create the public party on Node A, how do you ‘host’ it on Node B and ensure the identifier remains the same?

1 Like
4

You do this via the Canton Shell using the command topology.party_to_participant_mappings.authorize. You’ll need to run this on both the delegating and the receiving participants with opposing sides “From” and “To”. You can see that in action in this example.

def authorizePartyParticipant(partyId: PartyId, createdAt: ParticipantReference, to: ParticipantReference): Unit = {
  val createdAtP = createdAt.id
  val toP = to.id
  createdAt.topology.party_to_participant_mappings.authorize(TopologyChangeOp.Add, partyId, toP, RequestSide.From)
  to.topology.party_to_participant_mappings.authorize(TopologyChangeOp.Add, partyId, toP, RequestSide.To)
}

To make the delegation read-only, you need to add the parameter ParticipantPermission.Observation to the arguments of authorize.

1 Like