canton v2.8.0-rc1

Release candidates such as 2.8.0-rc1 don't come with release notes

canton v2.7.5

Release of Canton 2.7.5

Canton 2.7.5 has been released on November 1, 2023. You can download the Daml Open Source edition from the Daml Connect Github Release Section. The Enterprise edition is available on Artifactory.
Please also consult the full documentation of this release.

Summary

This is a maintenance release.

Bugfixes

(23-032, Critical): Replayed submissions make crash recovery fail

Issue Description

Canton cannot reconnect to a domain after a duplicated submission request.

Affected Deployments

Participant

Affected Versions

2.3 to 2.7.4

Impact

The participant is left in a failed state.

Symptom

Connecting to the domain fails with an internal error "IllegalStateException: Cannot find event for sequenced in-flight submission".

Workaround

No workaround by clients possible.

Likeliness

Needs a submission request being sequenced twice.
This should not happen under normal operations, but it did happen with the Besu driver.

Recommendation

Upgrade to 2.7.5

What’s New

Minor Improvements

• UX improvement on reporting of mediator’s component health states on the console.

Configuration Changes

Breaking: KMS wrapper-key configuration value now accepts a simple string

The expected KMS wrapper-key configuration value has changed from:

    crypto.private-key-store.encryption.wrapper-key-id = { str = "..."}

to a simple string:

    crypto.private-key-store.encryption.wrapper-key-id = "..."

Compatibility

The following Canton protocol and Ethereum sequencer contract versions are supported:

Dependency	Version
Canton protocol versions	3, 4, 5

Canton has been tested against the following versions of its dependencies:

Dependency	Version
Java Runtime	OpenJDK 64-Bit Server VM Zulu11.62+17-CA (build 11.0.18+10-LTS, mixed mode)
Postgres	postgres (PostgreSQL) 14.9 (Debian 14.9-1.pgdg120+1)
Oracle	19.18.0

canton v2.3.17

Release of Canton 2.3.17

Canton 2.3.17 has been released on October 23, 2023. You can download the Daml Open Source edition from the Daml Connect Github Release Section. The Enterprise edition is available on Artifactory.
Please also consult the full documentation of this release.

Summary

This is a maintenance release of Canton. We recommend users who uses Besu to upgrade to this version to ensure
that sequencer drivers properly report their Health Status that allows a HA environment to fail over.

Bugfixes

Fixed a bug in the health status of Besu sequencer driver

Description
: when a sequencer driver is connected to a Besu node, in case the Besu node is
unable to respond within 15s the sequencer is still considered healthy as long as a connection to the node can be made.

Affected deployments
: Besu deployments.

Affected versions
: All canton versions supporting Besu.

Impact
: The participant will be unable to change to a healthy sequencer (in a multi sequencer setup) and will be stuck until Besu problem is resolved.

Workaround
: Restarting the Besu node.

Likelihood of the bug
: The bug occurs very rarely and only when the Besu node is having unusual problems or under heavy load.

Compatibility

The following Canton protocol and Ethereum sequencer contract versions are supported:

Dependency	Version
Canton protocol versions	2.0.0, 3.0.0
Ethereum contract versions	1.0.0, 1.0.1

Canton has been tested against the following versions of its dependencies:

Dependency	Version
Java Runtime	OpenJDK 64-Bit Server VM 18.9 (build 11.0.16+8, mixed mode, sharing)
Postgres	postgres (PostgreSQL) 14.9 (Debian 14.9-1.pgdg120+1)
Oracle	19.15.0
Besu	besu/v21.10.9/linux-x86_64/openjdk-java-11
Fabric	2.2.2

canton v2.7.4

Release of Canton 2.7.4

Canton 2.7.4 has been released on October 09, 2023. You can download the Daml Open Source edition from the Daml Connect Github Release Section. The Enterprise edition is available on Artifactory.
Please also consult the full documentation of this release.

Summary

This release contains minor performance improvements related to the over-use of metrics in certain contexts as well as 2 bug fixes (one minor, one major).
Please see below for more information.

Minor Improvements

• By default the "canton-env-execution-context" metrics are no longer reported in order to conserve resources. Set the newly introduced canton.monitoring.metrics.report-execution-context-metrics configuration to true to enable these metrics.
• Added a config flag under canton.monitoring.metrics.enabled to allow disabling of metrics collection entirely.
• Changed default trace sampling from 100% to 1%. This means only 1% of request traces will be exported to trace by default going forward to save on CPU under high load scenarios. To revert to the old behavior, set the following config: canton.monitoring.tracing.tracer.sampler = always-on. See the tracing documentation for more information.

Bugfixes

Patch of the CommandService gRPC deadline logic

The CommandService now respects the grpc deadlines:
If a request reaches the command processing layer with an already-expired gRPC deadline, the command will not be sent for submission.
Instead, the request is rejected with a new self-service error code REQUEST_DEADLINE_EXCEEDED, which informs the client
that the command is guaranteed to not have been sent for execution to the ledger.

This change has been introduced with the bugfix 23-027 (see below).

(23-026, Minor) Non-graceful shutdown of the participant or the Ledger API

Participant may shutdown ungracefully if there there are still completing CommandService submissions or,
in extreme cases, the Ledger API can restart during normal operations.

Affected Deployments

The participant node

Impact

No significant operational impact.

Symptoms

• On shutdown, an exception including IllegalStateException("Promise already completed.") is logged.
• Pending CommandService submissions are not completed gracefully with SERVER_IS_SHUTTING_DOWN.
• In extreme cases, the issue can trigger a Ledger API restart during normal operation.

Workaround

Not applicable as the effect is mostly aesthetic.

Likelihood

This ungraceful shutdown is only likely under heavy usage of CommandService at the same time with the participant shutdown.
The likelihood of this bug triggering a Ledger API restart is very small as multiple conditions need to be met:

• Submissions with the same (submissionId, commandId, applicationId, submitters) change key are sent concurrently to both
  the CommandSubmissionService and the CommandService.
• The chosen deduplication duration for the submissions is small enough to allow them to succeed within a small timeframe
  (rather concurrently).

Recommendation

Upgrade when convenient.

(23-027, Major) Expired gRPC request deadlines crash requests in CommandService

The CommandService errors out when confronted with an expired gRPC request deadline.

Affected Deployments

The participant node

Impact

If encountered repeatedly (up to the maximum-in-flight configuration limit for the CommandService),
the CommandService can appear saturated and reject new commands.

Symptoms

When a command request is submitted via CommandService.submitAndWait and its variants with providing a gRPC request deadline,
the request can fail with an INTERNAL error reported to the client and a log message with ERROR level is logged on the participant.

Workaround

Restart the participant and use a higher gRPC request deadline.

Likelihood

This bug is likely to happen if the gRPC request deadline is small enough for it to expire upon arriving at the participant's Ledger API.

Recommendation

Upgrade when convenient.

Compatibility

The following Canton protocol and Ethereum sequencer contract versions are supported:

Dependency	Version
Canton protocol versions	3, 4, 5

Canton has been tested against the following versions of its dependencies:

Dependency	Version
Java Runtime	OpenJDK 64-Bit Server VM Zulu11.62+17-CA (build 11.0.18+10-LTS, mixed mode)
Postgres	postgres (PostgreSQL) 14.9 (Debian 14.9-1.pgdg120+1)
Oracle	19.18.0

canton v2.7.3

Release of Canton 2.7.3

Canton 2.7.3 has been released on September 27, 2023. You can download the Daml Open Source edition from the Daml Connect Github Release Section. The Enterprise edition is available on Artifactory.
Please also consult the full documentation of this release.

Summary

This is a maintenance release. Please check the list of bug-fixes and improvements below. Due to various improvements, we would recommend users to upgrade to it during their next maintenance window.
Please note, we've skipped 2.7.2.

Minor Changes

Usage of the applicationId in command submissions and completion subscriptions in the canton console

Previously, the canton console would use a hard-coded "CantonConsole" as an applicationId in the command submissions and the completion subscriptions performed against the ledger api.
Now, if an access token is provided to the console, it will extract the userId from that token and use it instead. A local console will use the adminToken provided in canton.participants.<participant>.ledger-api.admin-token, whereas a remote console will use the token from canton.remote-participants.<remoteParticipant>.token
This affects the following console commands:

• ledger_api.commands.submit
• ledger_api.commands.submit_flat
• ledger_api.commands.submit_async
• ledger_api.completions.list
• ledger_api.completions.list_with_checkpoint
• ledger_api.completions.subscribe
  Additionally, it is possible to override the applicationId by supplying it explicitly to the said commands.

keys.secret.rotate_node_key() console command

The console command keys.secret.rotate_node_key can now accept a name for the newly generated key.

owner_to_key_mappings.rotate_key command expects a node reference

The previous owner_to_key_mappings.rotate_key is deprecated and now expects a node reference (InstanceReferenceCommon)
to avoid any dangerous and/or unwanted key rotations.

Finalised response cache size is now configurable

The mediator keeps recent finalised responses cached in memory to avoid having to re-fetch late responses from the database.
The cache size is now configurable via

canton.mediators.mediator.caching.finalized-mediator-requests.maximum-size = 1000 // default

Improved Pruning Queries

The background pruning queries of the contract key journal for Postgres have been improved to reduce the load on the
database by making better use of the existing indexes. In addition, a pruning related query that checks the request
journal for how far it is safe to prune has also been improved for Postgres by choosing a more suitable index.

Improved KMS Audit Logs

The Canton trace id was added back to some KMS audit logs where it was missing.

Console Changes

Commands around ACS migration

Console commands for ACS migration can now be used with remote nodes.

Bug Fixes

(23-023, Critical): Crash recovery issue in command deduplication store

Description

On restart of a sync domain, the participant will replay pending transactions, updating the stores in case some writes were not persisted. Within the command deduplication store, existing records are compared with to be written records for internal consistency checking purposes. This comparison includes the trace context which differs on a restart and hence can cause the check to fail, aborting the startup with an IllegalArgumentException.

Affected Deployments

Participant

Impact

An affected participant can not reconnect to the given domain, which means that transaction processing is blocked.

Symptom

Upon restart, the participant refuses to reconnect to the domain, writing the following log message: ERROR c.d.c.p.s.d.DbCommandDeduplicationStore ... - An internal error has occurred.
java.lang.IllegalArgumentException: Cannot update command deduplication data for ChangeIdHash

Workaround

No workaround exists. You need to upgrade to a version not affected by this issue.

Likeliness

The error happens if a participant crashes with a particular state not yet written to the database. The bug has been present since end of Nov 21 and has never been observed before, not even during testing.

Recommendation

Upgrade during your next maintenance window to a patch version not affected by this issue.

(23-022, Major): - rotate_keys command is dangerous and does not work when there are multiple sequencers

We allow the replacement of key A with key B, but we cannot guarantee that the node using key A will actually have access to key B.
Furthermore, when attempting to rotate the keys of a sequencer using the rotate_node_keys(domainManagerRef) method,
it will fail if we have more than one sequencer in our environment.
This occurs because they share a unique identifier (UID), and as a result, this console command not only rotates the
keys of the sequencer it is called on but also affects the keys of the other sequencers.
Modified the process of finding keys for rotation in the rotate_node_keys(domainManagerRef)
function to prevent conflicts among multiple sequencers that share the same UID.
Additionally, we have updated the console command owner_to_key_mappings.rotate_key to
expect a node reference (InstanceReferenceCommon), thereby ensuring that both the current
and new keys are associated with the correct node.

Affected deployments

All nodes (but mostly sequencer)

Impact

A node can mistakenly rotate keys that do not pertain to it. Using rotate_node_keys(domainManagerRef) to rotate a sequencer's keys when other sequencers are present will also fail and break Canton.

Symptom

When trying to rotate a sequencers' keys it catastrophically fails with a java.lang.RuntimeException: KeyNotAvailable.

Workaround

For 'rotate_node_keys(domainManagerRef),' we have ensured that we filter the correct keys for rotation by checking both the authorized store and the local private key store.
Additionally, we have deprecated the existing 'owner_to_key_mappings.rotate_key' and introduced a new method that requires the user to provide the node instance for which they intend to apply the key rotation. We have also implemented a validation check within this function to ensure that the current and new keys are associated with this node.

Likelihood

Everytime we use rotate_node_keys to rotate the keys of sequencer(s) in a multiple sequencer environment.

Recommendation

Upgrade the Canton console that you use to administrate the domain, in particular the sequencer and mediator,
to a Canton version with the bug fix.

(23-019, Minor): Fixed rotate_node_keys command when it is used to rotate keys of sequencer(s) and mediator(s)

Canton has a series of console commands to rotate keys, in particular, rotate_node_keys that is used
to rotate de keys of a node.
We allow the replacement of key A with key B, but we cannot guarantee that the node using key A
will actually have access to key B.
Furthermore, when attempting to rotate the keys of a sequencer using the
rotate_node_keys(domainManagerRef) method, it will fail if we have more than one sequencer in our environment.
This occurs because they share a unique identifier (UID), and as a result, this console command not only
rotates the keys of the sequencer it is called on but also affects the keys of the other sequencers.

Impact

A node can mistakenly rotate keys that do not pertain to it.
Using rotate_node_keys(domainManagerRef) to rotate a sequencer's keys when other
sequencers are present will also fail and break Canton.

Symptom

No visible symptom as the command just skips over the keys to rotate.

Workaround

For rotate_node_keys(domainManagerRef), we have ensured that we filter the correct keys for
rotation by checking both the authorized store and the local private key store.
Additionally, we have deprecated the existing owner_to_key_mappings.rotate_key and introduced a new
method that requires the user to provide the node instance for which they intend to apply the key rotation.
We have also implemented a validation check within this function to ensure that the current
and new keys are associated with this node.

Likelihood

Everytime we use rotate_node_keys to rotate the keys of sequencer(s) in a multiple sequencer environment.

Recommendation

Upgrade the Canton console that you use to administrate the domain, in particular the sequencer and mediator,
to a Canton version with the bug fix.

(23-021, Minor): Core contract input stakeholders bug

The Canton protocol includes in ViewParticipantData contracts that required to re-interpret command evaluation. These inputs are known as coreInputs. Included as part of this input contract data is contract metadata the includes details of signatories and stakeholders.
Where the evaluation of a command results in a contract key being resolved to a contract identifier but that identifier is not in turn resolved to a contract instance that distributed metadata associated with contract will incorrectly have the key maintainers as both the signatory and the stakeholders. A way to do this would be to execute a choice on a contract other than the keyed contract that only issues a lookupByKey on the keyed contract.

Affected protocol versions

Protocol version 3,4

Impact

As the signatory data associated with the affected contracts is not valid, any validation based on this will also be invalid, so the command will be rejected.

Symptom

This bug was discovered when the model conformance logic was extended to validate all input contract signatories. The presented signatory list being inconsistent with that expected caused a failure....

canton v2.3.16

Release of Canton 2.3.16

Canton 2.3.16 has been released on September 22, 2023. You can download the Daml Open Source edition from the Daml Connect Github Release Section. The Enterprise edition is available on Artifactory.
Please also consult the full documentation of this release.

Summary

Canton 2.3.16 has been released as part of Daml 2.3.16 with no additional change on Canton.

Compatibility

The following Canton protocol and Ethereum sequencer contract versions are supported:

Dependency	Version
Canton protocol versions	2.0.0, 3.0.0
Ethereum contract versions	1.0.0, 1.0.1

Canton has been tested against the following versions of its dependencies:

Dependency	Version
Java Runtime	OpenJDK 64-Bit Server VM 18.9 (build 11.0.16+8, mixed mode, sharing)
Postgres	postgres (PostgreSQL) 14.9 (Debian 14.9-1.pgdg120+1)
Oracle	19.15.0
Besu	besu/v21.10.9/linux-x86_64/openjdk-java-11
Fabric	2.2.2

canton v2.7.2-rc1

Release candidates such as 2.7.2-rc1 don't come with release notes

canton v2.7.1-rc2

Release candidates such as 2.7.1-rc2 don't come with release notes

canton v2.7.1

Update 2023-08-22.23 (#108)

Reference commit: 664f3341a2

Co-authored-by: Canton <canton@digitalasset.com>

canton v2.7.1-rc1

Release candidates such as 2.7.1-rc1 don't come with release notes