This is a maintenance release that addresses several issues.
Following are detailed bug descriptions for the Beta features of Canton protocol version (PV) 6 and the Smart Contract Upgrade (SCU) feature. They can only occur if the steps to enable Beta features SCU and PV 6 have been taken; they cannot occur otherwise. They are in the process of being fixed for a future release.
When a transaction view contains a call to `fetch @I` targeting an interface I of an interface that is not used in an exercise anywhere in the same view, an error is thrown during re-interpretation as part of validation : “cannot resolve package <package-name>”
This breaks deterministic validation. In most circumstances this will lead to unexpected command failures with errors (`LOCAL_VERDICT_FAILED_MODEL_CONFORMANCE_CHECK`). However, should the affected node be in an observer role only, that error may not actually lead to a command rejection. In that case, the observing node will sound the alarm and fork from the submitting node(s).
When a transaction view contains a call to `fromInterface @T` targeting a template T of a version that does not match what the Interface value was created from (either manually built, or as from package-preference when using `fetch`) , then the call may erroneously return `None` instead of the expected `Optional (cid, args)` during re-interpretation as part of validation.
This breaks deterministic validation. In most circumstances this will lead to unexpected command failures with alarming errors (`LOCAL_VERDICT_FAILED_MODEL_CONFORMANCE_CHECK`). However, should the affected node be in an observer role only, that error may not actually lead to a command rejection. In that case, the observing node will sound the alarm and fork from the submitting node(s).
When a transaction contains an action on a contract created in version A, but a receiving node doesn’t have package version A, it will reject the transaction.
This breaks deterministic validation. In most circumstances this will lead to unexpected command failures with alarming errors (`LOCAL_VERDICT_FAILED_MODEL_CONFORMANCE_CHECK`). However, should the affected node be in an observer role only, that error may not actually lead to a command rejection. In that case, the observing node will sound the alarm and fork from the submitting node(s).
When uploading a DAR with both V1 and V2 of a package, the participant doesn't compare the two versions for upgrade compatibility. Consequently the participant may load and vet the packages even though they are not compatible. Behavior of the engine when presented with two versions of a package that are not actually compatible is unspecified. The system will most likely crash at runtime, but it might be possible that some unspecified behavior could even provoke a ledger fork or leak information.
This is a limitation more than a bug, but lifting the limitation requires a backwards breaking protocol upgrade. In 2.9.1, the type of a contract key cannot be changed, ever. If template Foo is defined in package A version 1, and the key type of Foo is defined in package B version 1, then the key type of the upgraded Foo in version 2 also has to depend on B version 1. So A version 2 has to depend on B versions 1 and 2 which is quite annoying to manage.
The Daml 2.9.4 SDK has been released. You can install it using the command: daml install 2.9.4.
The table below lists how you can download Daml Enterprise or individual components.
Daml Enterprise v2.9.4 |
||
Component |
File download |
Container Image |
SDK |
NA |
|
Canton for Daml Enterprise |
digitalasset-docker.jfrog.io/canton-enterprise:2.9.4 |
|
Daml Finance |
NA |
|
HTTP JSON API Service |
digitalasset-docker.jfrog.io/http-json:2.9.4 |
|
Trigger Service |
digitalasset-docker.jfrog.io/trigger-service:2.9.4 |
|
OAuth 2.0 middleware (Open-Source) |
digitalasset-docker.jfrog.io/oauth2-middleware:2.9.4 |
|
Participant Query Store |
digitalasset-docker.jfrog.io/participant-query-store:0.4.8 |
|
Daml Shell |
digitalasset-docker.jfrog.io/daml-shell:0.1.4 |
|
Trigger Runner |
digitalasset-docker.jfrog.io/trigger-runner:2.9.4 |
|
Daml Script |
digitalasset-docker.jfrog.io/daml-script:2.9.4 |
If you are using Oracle JVM and testing security provider signatures, note that the Canton JAR file embeds the Bouncy Castle provider as a dependency. To enable the JVM to verify the signature, put the bcprov JAR on the classpath before the Canton standalone JAR. For example:
java -cp bcprov-jdk15on-1.70.jar:canton-with-drivers-2.9.4-all.jar com.digitalasset.canton.CantonEnterpriseApp
Note: These Docker images are designed to be suitable for production use, with minimal size and attack surface. Minimal images can sometimes make debugging difficult (e.g. no shell in the containers). For convenience, we provide “debug” versions of each of the above images, which you can access by appending “-debug” to the image tag (e.g. digitalasset-docker.jfrog.io/http-json:2.9.4-debug).