In Daml finance app I see that the operator gets involved as signature in every service. I wonder if that design clashes with some recomendations stated in Canton docs related to scaling the network and performance. Scaling and Performance — Daml SDK 2.5.1 documentation
There are some anti-patterns that need to be avoided for the maximum scaling opportunity. For example, having almost all of the parties on a single participant is an anti-pattern to be avoided since that participant will be a bottleneck. Similarly, the design of the Daml model has a strong impact on the degree to which sharding is possible. For example, having a Daml application that introduces a synchronization party through which all transactions need to be validated introduces a bottleneck so it is also an anti-pattern to avoid.
Plan your topology such that your DAML parties can be partitioned into independent blocks. That means, most of your DAML commands involve parties of a single block only. It is ok if some commands involve parties of several (or all) blocks, as long as this happens only very rarely. In particular, avoid having a single master party that is involved in every command, because that party would become a bottleneck of the system.
operator is used in the Daml Finance App as a root of trust, signing the
Generally, a customer that is looking to enter into a
Service contract with a
provider either trusts the provider or requires some sort of credentials which signed by a trusted party.
Role contracts which are signed by the
operator act as the credential of the
You are right that this mechanism doesn’t scale very well when every other contract is signed by an
operator party. This is the reason why the contracts from the Daml Finance library (e.g. holding s or settlement instructions) are generally not signed by an
operator, but just by
In theory there is also not really a need for the
Service contracts to be signed by an operator, as each party involved can unilaterally choose to archive the service via the
To add to Matteo’s answer, there are two “operating models” for these service contracts:
(1) The centralized model: in this use case it is a requirement that a central party is in control over which parties can extend which services. This is done through the role contracts as mentioned, and only services with the operator’s signature would be considered valid by the app.
(2) The decentralized model: the usage of a central operator is entirely optional. There is nothing preventing a service provider to put themselves as the operator for a service. It’s up to the customer to accept the service under such conditions (they have to know and trust the service provider to be who they claim to be).
In many cases (1) is a requirement, but you are correct that (2) definitely scales better.