Skip to content

canton v0.26.0
Compare
Choose a tag to compare
@canton-machine canton-machine released this 15 Jul 16:45
v0.26.0
a0a2430
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

Release of Canton 0.26.0

Canton 0.26.0 has been released on July 15, 2021. You can download the Community edition from our github release section. The Enterprise edition is available on Artifactory.
Please also consult the full documentation of this release.

Summary

We've added a few important features to keep a participant node happy. First, we've added backpressure which will now ensure that a participant can not easily be overloaded by sending too many commands at once.
Then, we've cleaned up how the config includes work, ensuring a consistent order of which config option comes into effect if something has been configured twice.
And many more small changes to improve the user experience and stability of the system.

Please note that this version does not yet support Daml-LF 1.14 (Daml Exceptions).

What’s New

Simple Backpressure Support

Background

Up to now, if a participant receives more requests than it can handle within the participant response time out, most or all commands will timeout and therefore not be committed to the ledger.
Previously, the participant would have consumed a high amount of resources without achieving anything useful. This is now prevented using backpressure.

Specific Changes

We've added a command <participant-name>.resources.set_resource_limits that allows for imposing a limit on the number of dirty requests and the maximum rate of commands.
While one of these limits is attained or exceeded, the participant will reject any submission with GRPC status ABORTED. Most importantly, a submission will be rejected before it consumes a significant amount of resources.

The number of dirty requests covers requests initiated by the same participant as well as requests initiated by other participants. Compared to the maximum rate, it does more accurately reflect the load on the participant.
However, the maximum number of dirty requests alone does not protect the system from "bursts":
If an application submits a huge number of commands at once, the maximum number of dirty requests will likely be exceeded.
To protect a participant against "bursts", you should also configure a maximum rate.

Resource limits can only be changed if the server runs Canton enterprise. In the community edition, the server has a fixed limit of 10 transactions per second that cannot be changed.

Impact and Migration

The change has no impact on existing Canton deployments.

Config File Precedence

Background

Currently, if a key is defined twice in the Canton config, there are different conventions on which definition is taken.
If you define:

field = 1
field = 2

then Canton will assume field = 2. So the last definition "wins".

The same behavior occurs, if you define field in two different included files:

c1.conf:
field = 1

c2.conf
field = 2

main.conf:
include("c1.conf")
include("c2.conf")

Again, if Canton is started with main.conf, Canton will assume field = 2.

In contrast, if Canton has been started with --config c1.conf --config c2.conf, a previous Canton release will assume field = 1.

Specific Changes

When Canton is started with several configuration files (i.e., --config c1.conf ... -config cn.conf), then later definitions will override earlier definitions with the same key.
Consequently, the latest definition now always has the highest precedence, independently of whether definitions occur in the same file, in different included files or in different files loaded as separate --config parameters.

Impact and Migration

If you start Canton with several configuration files (i.e., --config c1.conf ... -config cn.conf), you should reverse the order of the --config parameters.
No action is required if the keys loaded by your config files are pairwise different.

Health Commands

We have improved the health commands. The health.status command is now present on all node types, not only on participant and domain as before.
Additionally, we've replaced the command identity.initialized with a set of new commands:

  • health.running to indicate that the node has started (but might not yet be initialized)
  • health.initialized to indicate that the node has been successfully initialized
  • health.wait_for_running and health.wait_for_initialized to wait for one of the above conditions.

Minor Improvements

  • We've removed the console command participant.pruning.find_safe_timestamp in favor of new command participant.pruning.find_safe_offset
  • We've renamed the config parameter my-remote-node.my-api.tls.cert-chain-file to my-remote-node.my-api.tls.trust-collection-file.

Security and Bugfixes

  • We resolved an issue that prevented a participant to connect to a domain that has the same unique identifier as the participant.
  • We've improved the validation of values saved in the Canton backend: all relevant strings (identifiers, aliases, party names etc.) are now enforced to have an upper limit of characters. This validation happens mainly on the server side: after Canton receives Api calls through the Ledger Api server or the Admin Api. This change prevents truncation errors when storing these strings in a database.

Compatibility

Dependency Version
Java Runtime OpenJDK 64-Bit Server VM 18.9 (build 11.0.11+9, mixed mode, sharing)
DAML SDK 1.15.0
Postgres postgres (PostgreSQL) 11.12 (Debian 11.12-1.pgdg90+1)
CCF 0.14.2
Ethereum besu/v20.10.4/linux-x86_64/oracle_openjdk-java-11
Fabric 2.2.2

What's Coming

We are currently working on

  • Support for DAML exceptions
  • Oracle database support
  • Improving stability and long-running behaviour.
  • Increase negative test coverage and improve our ability to deal with other outages.
  • Supporting large number of participants and parties with privacy.
  • Better error codes and fault documentation.
  • Support for causality enforcement.
Assets 4
Loading