Release of Daml 2.1.0
Daml Connect 2.1.0 has been released. You can install it using:
daml install 2.1.0
Want to know what's happening in our developer community? Check out the latest update for this month.
Summary
- General Availability of the Ethereum Besu Driver
- General Availability of the Fabric Driver
- Key Usage and Key Management in Canton
Impact and Migration
- There are minor changes to the Canton Ethereum and Canton Fabric configuration and breaking changes to the
Sequencer.sol
smart contract andsequencer.go
chaincode smart contract. For details see the ‘Impact and Migration’ sections for the Ethereum Besu and Fabric driver sections.
What's New
General Availability of the Ethereum Besu Driver
Background
The Enterprise Ethereum Besu Driver has been promoted from Beta status and is now Generally Available (GA) and has full Enterprise support. Over the last few months we made some finishing touches, in particular to the documentation, adding more deployment helpers and improving the examples. This driver is available to our Enterprise customers.
To migrate your existing Canton-on-Ethereum setup to the new release, please refer to the Impact & Migration section below.
Specific Changes
-
The Ethereum Besu driver now offers an automatic-deployment option for the
Sequencer.sol
contract which is available when using a single sequencer. This option makes bootstrapping an Ethereum sequencer easier and helps to avoid common pitfalls around wrongly configured contract addresses or block heights. The Ethereum sequencer console commandethereum.deploy_sequencer_contract
has also been improved. Please see the documentation for details. -
Ethereum now offers a simple, white-list based authorization mechanism as an early-access feature. The authorization mechanism allows fine-grained control of the Ethereum accounts that are allowed to interact with the
Sequencer.sol
smart contract. Please see the documentation for the full details. -
The demo has been reworked into simple and advanced scenarios. The simple scenario showcases the new automatic deployment feature for a single sequencer, while the advanced scenario showcases using the improved
ethereum.deploy_sequencer_contract
for multi-sequencer deployment, and the early access authorization feature. Please see the documentation for the full details. -
Configuration Changes - Minor changes to existing Canton Ethereum configuration files and deployment scripts are needed to use them with this release:
-
The Ethereum sequencer console command
ethereum.deploy_sequencer_contract
expects new optional arguments. Therefore, you now need to add parentheses to its invocation. For example, instead ofethereum_sequencer1.ethereum.deploy_sequencer_contract
, callethereum_sequencer1.ethereum.deploy_sequencer_contract()
-
In your Besu node configuration, the RPC HTTP API `TXPOOL` now needs to be enabled ("----rpc-http-api=TXPOOL,...").
-
In the Canton configuration, you now also need to specify whether authorization should be enabled and whether the contract uses `type` 'already-deployed' (only option possible before) or 'automatic-deployment'.
-
sequencer {
type = "ethereum"
config {
client-conf {
client-host="besu-1"
client-port=8550
}
contract {
address="0x0ffd23af8eebc60b3cfdeed6f814988757237314",
block-to-read-from=1
}
}
}
It should now look as follows:
sequencer {
type = "ethereum"
config {
client-conf {
client-host="besu-1"
client-port=8550
}
authorization-enabled=false
contract {
type="already-deployed"
address="0x0ffd23af8eebc60b3cfdeed6f814988757237314",
block-to-read-from=1
}
}
}
Impact and Migration
There are minor changes to the Canton Ethereum configuration and breaking changes to the Sequencer.sol
smart contract. If you want to use an Ethereum domain with this release, you will need to redeploy the Sequencer.sol
contract. Please note that with the improved configuration option, it is now easier to redeploy Sequencer.sol
without resetting your Ethereum network.
General Availability of Fabric Driver
Background
The Enterprise Fabric Driver has also been promoted from Beta status and is now Generally Available (GA) and has full Enterprise support. This driver is available to our Enterprise customers. As with the Ethereum Enterprise Besu driver we made some finishing touches, in particular to the documentation, adding additional deployment helpers and example improvements.
To migrate your existing Canton-on-Fabric setup to the new release, please refer to the Impact & Migration section below.
Specific Changes
-
The demo setup has been greatly simplified and the documentation improved. Please see the documentation.
-
Fabric Sequencer pruning capabilities using Fabric's private data collections are available as a preview feature by setting
sequencer.config.use-private-data-collections=true
. -
Configuration Changes - Minor changes to existing Canton Fabric configuration files and deployment scripts are needed to use them with this release.
For example, the following configuration was previously valid and used for the Fabric demo:
sequencer {
type = "fabric"
config {
context-organization-name="org1.example.com"
organizations=[
{
name="org1.example.com"
admin-user = {
msp-id=Org1MSP
hlf-client-user=User1
msp="<path>/msp"
}
hlf-tls-cert-file="<path>/tls/ca.crt"
It should now look as follows:
sequencer {
type = "fabric"
config {
user = {
msp-id=Org1MSP
organization-name="org1.example.com"
client-user=User1
private-key-file="<path>/msp/keystore/priv_sk"
signed-cert-file="<path>/msp/signcerts/User1@org1.example.com-cert.pem"
}
organizations=[
{
name="org1.example.com"
tls-cert-file="<path>/tls/ca.crt"
Impact and Migration
There are minor changes to the Canton Fabric configuration and breaking changes to the sequencer.go
chaincode smart contract. If you want to use a Fabric domain with this release, you will need to redeploy the sequencer.go
contract.
Key Usage and Key Management in Canton
Canton's security is tied to the secure usage of the cryptographic keys involved. While the system operates securely by default, we've added a new section to our manual that explains in detail how we use cryptographic keys to secure our protocol. In addition, we've added new console macros such as node.topology.owner_to_key_mappings.rotate_key
. A macro
combines a series of console commands. In this particular case, it can be used to rotate keys. We've described it all in our new section on cryptographic key management.
Minor Improvements
-
The Daml compiler now allows projects to have dependencies which in turn have data dependencies.
-
Improved robustness and performance of the Daml Engine.
-
The start-up time for the Daml Repl has been greatly reduced.
-
Ledger API Specification:
-
Streaming endpoints will use the error code 'SERVER_IS_SHUTTING_DOWN' when the server is being shut down, whereas before an exception without an error code was used. The gRPC status code in use remains as 'UNAVAILABLE'.
-
ParticipantPruningService.prune now signals more detailed errors when pruning was not performed. Previously, some of the error details were truncated.
-
Participant metering:
-
An HTTP endpoint providing metering reports has been added to the JSON API. More information can be found in the docs here.
-
Participant metering operating instructions have been added to the Daml documentation here.
-
Party allocations via the Ledger API will now result in the error
PARTY_ALLOCATION_WITHOUT_CONNECTED_DOMAIN
if the participant is not connected to a domain and party notification is set to via-domain. Previously the gRPC request would simply time out and the party became visible when the participant connected to a domain the next time. -
The developer logging switch
canton.monitoring.log-message-payloads
has been replaced by a new config section which allows a user to log much more details about internal data structures. In order to recover the previous logging functionality, please usecanton.monitoring.logging.api.message-payloads = true
instead, but be aware that this is an internal logging feature subject to change. -
Daml Enterprise Only:
-
An example Oracle storage configuration mixin has been added to the release bundles under 'examples/03-advanced-configuration/storage'
-
A new Oracle storage configuration check has been added to test whether the user is using different Oracle schemas for Ledger API and Canton sync service database. This has been added because we’ve seen users make the mistake of using the same Oracle schema for the two components.
-
Preview Features:
-
The Docker deployment example has been moved to the Enterprise release, as the Docker images of the JSON API and Trigger Service are only available to Enterprise customers.
-
Auto-transfer has been improved to complete outstanding transfers after a restart.
-
Basic DAR removal has been implemented, therefore Canton now supports, as a preview feature, the removal of DARs and Daml packages. However, the feature is not yet supported by the Ledger API server, and therefore remains a preview feature.
Bug / Security Fixes
-
In the Java bindings, the
UserManagementClient.getUser
methods have been changed to return a custom wrapper typeGetUserResponse
instead of aUser
directly. If you were already using these methods, you can make your code work as before by adding a call to thegetUser
method defined on theGetUserResponse
type you now get back. See the Git issue here for more information about this change. -
The HTTP JSON API now returns a 404 instead of a 500 error when information about a package is requested that doesn't exist on the ledger.
-
Daml Studio now shows trace messages in script views even when there are no transactions.
-
The logging configuration of the Trigger Service has been fixed so that it doesn't show debug level messages, and a warning about it is no longer shown at startup.
-
The logging configuration of the OAuth 2.0 Middleware has been fixed so that a warning is no longer shown on startup.
-
A race condition bug is fixed in the Ledger API mutable contract state cache. The bug allowed the cache to become corrupted with stale references when the Ledger API was subjected to concurrent submissions racing to update/fetch the same contract key. The stale references were causing the Ledger API to erroneously reject submissions in certain corner-cases.
-
A workaround for a bug in the Java JDK (https://bugs.openjdk.java.net/browse/JDK-7092821) has been implemented. This issue previously caused performance degradations in the Ledger API Server and the execution engine due to lock contention in MessageDigest.getInstance
-
The OpenTelemetry library has been upgraded to 1.12.0. This library was previously causing gRPC reflection to fail on the Ledger API Server.
-
A bug has been fixed where the limit argument in the participant.parties.list console command was not correctly honored in the case of disabled participants (leading to the list function returning fewer results than the given limit).
-
The open source release artifact now correctly extracts into a directory named "canton-open-source" rather than "canton-community", the previous name for the open-sourced version.