Canton Allocates Parties Automatically?

Hello everyone!

I run a container with Canton like this:

  ledger:
    image: digitalasset/canton-open-source:latest
    profiles: ["ledger"]
    volumes:
      - ./canton:/canton/csd
    command:
      daemon -c /canton/csd/csd.conf --bootstrap /canton/csd/csd.canton --log-profile=container

Here is my config:

# first, turn on non-standard configuration support
canton.parameters.non-standard-config = yes

canton {
    participants {
        custodian {
            storage.type = memory
            admin-api.port = 5012
            ledger-api.port = 5011
            ledger-api.address = 0.0.0.0
        }
        issuer {
            storage.type = memory
            admin-api.port = 5022
            ledger-api.port = 5021
            ledger-api.address = 0.0.0.0
        }
    }
    domains {
        mydomain {
            storage.type = memory
            public-api.port = 5018
            admin-api.port = 5019
        }
    }
  // enable ledger_api commands for our getting started guide
  features.enable-testing-commands = yes
}

And here is my bootstrap:

// start all local instances defined in the configuration file
nodes.local start

// Connect participant1 to mydomain using the connect macro.
// The connect macro will inspect the domain configuration to find the correct URL and Port.
// The macro is convenient for local testing, but obviously doesn't work in a distributed setup.
issuer.domains.connect_local(mydomain)
custodian.domains.connect_local(mydomain)

When I inspect running ledger with canton console or daml repl I see that I have two parties already allocated:

daml> listKnownParties
[PartyDetails {party = 'custodian::122075508618b031dfda8a50945b85f2d50686f4a9e52bc76fffeb62cdc4a30a4ac0', displayName = None, isLocal = True},PartyDetails {party = 'issuer::12208e237b0051d17850dbb7302d2737746965e856b24e0cf221da068e6c6d7f472d', displayName = None, isLocal = False}]

Canton console:

@ remoteParticipantIssuer.parties.list() 
res1: Seq[ListPartiesResult] = Vector(
  ListPartiesResult(
    party = issuer::1220c678a4ac...,
    participants = Vector(ParticipantDomains(participant = PAR::issuer::1220c678a4ac..., domains = Vector(DomainPermission(domain = mydomain::1220444ab3d8..., permission = Submission))))
  ),
  ListPartiesResult(
    party = custodian::1220d3d85506...,
    participants = Vector(ParticipantDomains(participant = PAR::custodian::1220d3d85506..., domains = Vector(DomainPermission(domain = mydomain::1220444ab3d8..., permission = Submission))))
  )
)

Why is it happening? Can I prevent auto allocation and start with a clean ledger? I want to allocate parties with a script. And when I do so I get errors:
Unable to allocate party custodian::1220da6729d2..., as it has the same name as the participant's admin party.

I don’t think you can disable that. Each participant gets one party allocated by default. You can change the prefix of the party id though by renaming your participant:

canton {
    participants {
        custodian_participant {
            storage.type = memory
            admin-api.port = 5012
            ledger-api.port = 5011
            ledger-api.address = 0.0.0.0
        }
        issuer_participant {
            storage.type = memory
            admin-api.port = 5022
            ledger-api.port = 5021
            ledger-api.address = 0.0.0.0
        }
    }
}

Thanks! Understood.
If I cannot disable that can I control it? I mean, can I set a display name or a party hint for them?

Every participant automatically gets an admin party. This isn’t a party you should be using for your workflows. Think of it being a bit like a “root” account in a unix system. It exists, but you normally don’t run applications on it, only the system does.

The party id used is the same identifier as used by the participant. So given that you control the name of the participant, you also control the id of its party.

And you can set a display name for that party too. However, beware that display names are participant local. They are not shared among the participants.

I hope this helps!

Think of it being a bit like a “root” account in a unix system.

@Ratko_Veprek Just to be clear, you’re saying that this party is like root in that it should not be generally used, not like root in terms of possessing elevated access rights?

The party does not possess elevated rights. However, it is tied to a participant itself. As such, you can’t really move it between participant nodes. Therefore, I would not use it in my applications.