Release of Daml 2.4.0

 Daml 2.4.0 has been released. You can install it using:

daml install 2.4.0

Summary

• Transaction latency has been reduced significantly (up to 5x for simple ping transactions).
• Improvements to the user experience and robustness of highly available Canton nodes.
• Canton Enterprise now has pre-configured resource limits by default.
• Daml interfaces are now in early access.
• Daml Finance is now in early access.

Impact and Migration

• (Enterprise only) If you had previously not set resource limits and your system processes high volumes, the new defaults may affect you. To mitigate, set your own limits.
• Some highly specialized Canton error codes have changed. If your application explicitly handles MEDIATOR_SAYS_INFORMEES_NOT_HOSTED_ON_ACTIVE_PARTICIPANTS and MEDIATOR_SAYS_INVALID_ROOT_HASH_MESSAGES, you’ll need to migrate to the new error code MEDIATOR_INVALID_MESSAGE.
• A typo was fixed in the error code PACKAGE_NOT_VETTED_BY_RECIPIENTS, which was previously PACKAGE_NO_VETTED_BY_RECIPIENTS. If you explicitly handle this error, please adapt the spelling.
• The minor improvements section points to a range of changes to Canton configuration parameters and console commands that have been tidied up. The changes are largely backwards compatible and should not affect common use. Should you run into errors about CryptoConfig when using remote participant administration, or your previously working Canton console commands produce compilation errors, please refer to the details below.

What’s new

Transaction Latency improvements

We have improved the latency of transaction processing in participant nodes. A Ledger API client will see a reduction in latency of ~50 milliseconds for end-to-end requests due to better buffering, caching and removal of the database polling step. The extent of the latency reduction depends on the transaction and deployment. For a simple participant.health.ping (which includes three consecutive transactions), the latency went down from ~ 350ms to 70ms as compared to the 2.2.0 release.

These optimizations significantly speed up integration testing during development and allow a better user-experience in production due to a quicker feedback in user interfaces.

Improvements to Canton High Availability (Enterprise only)

Background

Daml Enterprise allows most node types to be run with redundancy to achieve high availability of the system in the face of crashes and other outages. This release includes a range of improvements that aid the ease of use, safety, and usefulness of these features.

Specific Changes

• We have renamed connect_ha command to connect_multi to disambiguate the two.
  The overloading of the created UX issues. Therefore, please change your script accordingly.
• For storage that supports it - Oracle DB, PostgreSQL - replication support is now enabled by default for participant, sequencer and mediator nodes. Enabling this mode is necessary to avoid database corruption when multiple processes share the same database, and has no performance impact when running only a single process. Therefore, this change simply makes the use of HA features safer for the developer.
• Sequencer nodes now report their ability to connect to the underlying database or blockchain node as part of their health status. Other Canton nodes connecting to multiple sequencers monitor this health status and route requests to healthy sequencers only. The Fabric and Ethereum sequencers check and update their health periodically at an interval configured by canton.sequencers.<sequencer>.health.backend-check-period, which defaults to 5 seconds.
  
  This behavior improves the ability to deploy highly available networks that are resilient against outages at the database or blockchain layer.

Impact and Migration

These changes are entirely backwards compatible.

Default Resource Limits

Background

Participant command processing resource limits have been disabled by default until now. As a result, participants without explicitly set limits could get overloaded if an application submits commands at an excessive rate, and in turn overload the system. To avoid that, resource limits are now enabled by default.

Specific Changes

• If you have already configured command processing resource limits (i.e., using myParticipant.resources.set_resource_limits(...)), the configured limits remain in place.
• If you have not yet configured resource limits, the limits will change from "no limit" to a maximum rate of 200 commands per second and a maximum of 500 in-flight requests.

Impact and Migration

If you have not yet configured command processing resource limits, double-check whether the new defaults make sense for your system. See the documentation for further information on how to tune resource limits.

Daml Interfaces and Daml-LF 1.15 in Alpha

Background

Daml has predictability and safety as two of its core design philosophies in the sense that we want to ensure that both during development and at the point a party signs a contract, all possible consequences of that contract can be predicted. This philosophy could be at odds with a typical business requirement to be able to easily extend functionality in the future. For example, I want to be able to agree on the rules for a marketplace today by signing the marketplace smart contracts. But I want to be able to later define entirely new asset classes that I cannot yet predict. Indeed, building Daml applications that were extensible in such a way has been tricky until now.

The above philosophy also led to a number of design decisions that made Daml code dependencies fairly static and closely coupled on-ledger types with the types downstream components like client applications consumed and processed. This close coupling between different Daml packages and on- and off-ledger types made it more difficult to evolve applications over time.

Daml Interfaces are our answer to extensibility and modularization of applications without breaking with predictability and safety. Daml Interfaces are currently in Alpha status, which means we are still expecting some changes. They are not supported in production and there will be no data continuity between the early access version and GA versions of Daml-LF 1.15 if you choose to use it.

Specific Changes

• Daml interfaces are now available in the Daml Smart Contract Language when targeting Daml-LF 1.15. This needs to be activated explicitly in both SDK and ledgers. Please refer to the documentation on interfaces on their use.
• The Daml Ledger API supports the submission of commands through interfaces, and streaming active contract sets and transactions with interface types.
• The JSON API supports the submission of commands through interfaces, and queries and stream queries for interface types.
• The Navigator supports the submission of commands through interfaces.
• The Java and TypeScript/JavaScript bindings expose the query and command submission capabilities of the APIs.

Impact and Migration

This is a purely additive change.

Daml Finance in Alpha

Background

Developer productivity is a core value driver of Daml. To further support users building applications on their journey to production we are releasing Daml Finance into Alpha. Daml Finance is a comprehensive library to support modeling financial use cases in Daml. It allows you to:

• Record the ownership of assets to represent registries and custodial hierarchies
• Model any financial contract from simple tokens to exotic derivatives
• Coordinate complex asset movements and settlement flows
• Manage the lifecycle and evolution of financial instruments

Specific Changes

• The Daml Assistant now comes with a Daml Finance Getting Started template, which can be installed with `daml new test --template=quickstart-finance`
• The Getting Started Guide can be found in the Daml Finance Documentation

Impact and Migration

This is a purely additive change.

Minor Improvements

• We removed crypto: CryptoConfig = CryptoConfig() from Canton’s RemoteParticipantConfig since it was not having any effect.
• Logging to stdout from all Canton processes will now include thread and datetime unless you are running the Canton console interactively. This will improve the logging experience with containers.
• We've discontinued the overly specific error codes MEDIATOR_SAYS_INFORMEES_NOT_HOSTED_ON_ACTIVE_PARTICIPANTS and MEDIATOR_SAYS_INVALID_ROOT_HASH_MESSAGES. Instead, MEDIATOR_INVALID_MESSAGE will be reported.
• There have been various improvements to the consistency and clarity of the Canton console commands. These changes affect non-standard arguments or testing functionality and due to the use of implicit conversion are mostly backwards compatible.
  
  Advanced users of the Canton console might have to adapt their scripts to the new commands.
  
  Please consult the detailed Canton release notes embedded in the released artifact for further information.

Security and Bug fixes

• A number of participant metrics were not exposed through the configured reporters. Among others, the metrics pertaining to the indexer such as daml_indexer_ledger_end_sequential_id were missing. This is now fixed.
• We have fixed the propagation of JDBC properties from the configuration file to support PostgreSQL SSL connections.
• Fixed a bug where a command sent through the admin console client fails if the result exceeds 4MB. The new limit is 2GB, which is also the maximum size of a GRPC message.
• We have fixed a typo in one of the error-ids: PACKAGE_NOT_VETTED_BY_RECIPIENTS was missing the "T" of NOT.