Identifying the Right Technology for Your Multiparty Business Processes

Blockchain Technology Partners offers infrastructure choices for distributed, multiparty workflows. In this guest blog, Csilla Zsigri, VP, Marketing and Strategy at Blockchain Technology Partners explains the suitability of the various technology options.

Identifying the right technology for digitizing processes that involve multiple parties within and across organizations, has plagued businesses for decades. Information technology and operations executives are looking for the right technology to use for business-critical applications involving both trusted and untrusted parties. 

To help companies select a suitable technology for their multiparty workflows and distributed applications, we have created a simple decision tree, with three key questions to consider:

  1. Do you know and trust the participants in your business network?
  2. Does your business network have or need a trusted operator? 
  3. Do you need an immutable audit trail for your business process?

Let’s go through these questions, one by one.

Do you know and trust the participants in your business network?


If the answer to this question is ‘No,’ and your company seeks to interact and transact more efficiently – by eliminating frictions – with multiple untrusted organizations; a permissionless blockchain implementation will enable you and the other members in your business network to share information and collaborate securely, without a central authority, and with none of the individual parties having the ability to one-sidedly enforce decisions, either accidentally or in bad faith. 

Blockchain Technology Partners’ infrastructure management offering supports Hyperledger Besu, a core ledger protocol that combines both permissionless and permissioned features. Hyperledger Besu is essentially an Ethereum client that supports various consensus mechanisms, and its permissioning schemes were designed to be used in consortium environments. 

If the answer to this question is ‘Yes,’ then you should move on to the second question in the decision tree.

Does your business network have or need a trusted operator?

If the answer to this question is ‘No,’ you may consider the implementation of a permissioned blockchain network for running your multiparty business process. Hyperledger Sawtooth, in particular, offers a flexible and modular architecture, and supports various consensus mechanisms and smart-contract languages. Blockchain Technology Partners has released a freely available, enterprise-grade distribution of Hyperledger Sawtooth – dubbed BTP Paralos – ideal for production and business-critical environments. 

If the answer to this question is ‘Yes,’ then you should move along to the third and final question in the decision tree. 

Do you need an immutable audit trail for your business process?

If the answer to this question is ‘Yes,’ you may consider using a blockchain-powered distributed database technology that provides data integrity alongside privacy. Amazon QLDB, in particular, was designed to support transaction immutability offered by blockchain technology, yet it provides a centralized model to ensure data privacy.

For use cases where immutability is not required, but the ability to automate multiparty workflows is desired, a relational database such as Amazon Aurora coupled with a smart-contract capability such as Daml at the application layer, may be a suitable choice. 

When we are done with the decision tree…what then?

Overcoming shortages in IT skills and resources is one of the key challenges associated with digital transformation overall, and distributed ledger technology is no exception. With Sextant, Blockchain Technology Partners offers to free organizations from all the infrastructure pain involved with setting up and running a blockchain network, to ultimately enable them to build distributed applications and multiparty systems with ease. Distributed ledgers currently supported by Sextant include Hyperledger Besu and Hyperledger Sawtooth.

BTP’s Sextant also supports Daml, an open-source smart-contract programming language created by Digital Asset. Smart contracts have become known to the world as transaction protocols running on a blockchain or distributed ledger, embodying the self-enforcing business logic of a multiparty application or business process. Daml was purpose-built for coding complex multiparty business processes, and designed to work with different blockchains, distributed ledgers, as well as databases.

Blockchain Technology Partners and Digital Asset have teamed up to launch ‘Sextant for Daml,’ a joint, commercial offering that enables organizations to build and deploy smart contracts with little effort and no special expertise, on a variety of persistence layers. Sextant for Daml supports Hyperledger Besu, Hyperledger Sawtooth, as well as Amazon QLDB, Amazon Aurora and PostgreSQL.

For more information on Sextant, click here. Get in touch: daml@blockchaintp.com.

For more information on Daml, click here. Get in touch: sales@digitalasset.com.

Release of Daml Connect 1.12.0

Daml Connect 1.12.0 has been released on Wednesday April 14th. You can install it using:

daml install latest

Want to know what’s happening more broadly among Daml developers? Check out the latest Daml Developer Monthly.

Summary

  • Daml projects can now depend on packages deployed to the target ledger.
  • The Daml StdLib contains a new module DA.List.BuiltinOrder, which provides higher-performance versions of several functions in DA.List by using a built-in order rather than user-defined ordering. We observed up to five-fold speedups in benchmarks.
  • The Daml assistant now supports the Daml Connect Enterprise Edition (DCEE), which comes with additional features:
    • The DCEE has an Alpha feature to validate and store signatures on command submissions. This provides non-repudiation in cases where the Ledger API is exposed as a service.
    • The DCEE contains a Profiler in Alpha which allows you to extract performance information for Daml interpretation.
Profiler output is easily visualized in tools like speedscope

Impact and Migration

Some of the minor changes and bugfixes may require small actions to migrate:

  • Daml Triggers now use DA.Map instead of DA.Next.Map in their API. 
  • If you were directly targeting .dalf packages using data-dependencies, you now need to add --package flags to make the package contents available.
  • The Scala bindings now depend on Scala 2.12.13 instead of 2.12.12
  • The compiler now produces Daml-LF 1.12 by default. If you want to stick to the old default, Daml-LF 1.11, please add the build-option --target=1.11.
  • Some gRPC status codes on rejected commands were changed from INVALID_ARGUMENT to ABORTED.

What’s New

Remote Dependencies

Background

The data-dependencies stanza in daml.yaml project files lists the binary dependencies which the project relies on. Until now, these dependencies were file-based, requiring developers to specify a path to .dar files. Quite often the dependencies are already running on a ledger, in which case this required the developer to first get hold of a .dar file from the original source or by calling daml ledger fetch-dar. This new feature removes that extra step, allowing a Daml project to depend directly on a package already running on a ledger.

Specific Changes

Package names and versions, as well as package ID’s are allowed in the data-dependencies list of daml.yaml. These packages are fetched from the project ledger. The auto-generated daml.lock file keeps track of the package name/version to the package ID’s resolution and should be checked into version control of the project. For example, to depend on the package foo-1.0.0 running on a ledger on localhost:6865, your daml.yaml should contain:

ledger:
  host: localhost
  port: 6865
dependencies:
- daml-prim
- daml-stdlib
data-dependencies:
- foo:1.0.0

Impact and Migration

This is a purely additive change.

High-Performance List Operations

Background

A number of functions in the standard library for lists, DA.List, rely on the elements of the list being orderable. They use orderings defined in Daml through Ord instances and thus need Daml interpretation for every comparison. Since Daml-LF 1.11, Daml has a canonical inbuilt ordering on all values, which is considerably more performant than comparison on Daml-defined orderings. This allows the implementation of higher-performance versions of all of ordering-based algorithms. The new, high performance implementations are contained in a new module DA.List.BuiltinOrder.

As long as all orderings are derived automatically using deriving Ord, the results of the old and new implementations will agree, but the new version is substantially faster. If any values have user-defined Ord instances, these will be ignored by the new versions, hence the name BultinOrder.

Specific Changes

The Daml Standard Library has a new module DA.List.BuiltinOrder containing more efficient implementations of the sort*, unique*, and dedup* functions based on the builtin order. We saw up to five-fold speedups in our benchmarks.

Impact and Migration

This is a purely additive change.

If you don’t care about the actual ordering of values, but only that values are orderable for algorithmic use, we recommend switching to the new versions of the algorithms for performance reasons. 

Daml Assistant support for the Daml Connect Enterprise Edition

Background

Daml Connect Enterprise Edition (DCEE) is a commercial distribution of Daml Connect containing additional features particularly useful in large or complex projects. DCEE components have been distributed via Artifactory for several releases now. With this release, the Daml Assistant also becomes aware of the Enterprise Edition and is able to manage additional developer tools and components not available in the Community Edition.

This release also contains two new features in Early Access for the DCEE, described in more detail below.

Specific Changes

The assistant now supports an artifactory-api-key field in daml-config.yaml. If you have a license for DCEE you can specify this and the assistant will automatically fetch the DCEE which provides additional functionality. See the installation documentation for more detail.

Impact and Migration

If you are an Enterprise Edition user, we recommend adding the artifactory-api-key field to your daml-config.yaml to benefit from the new features. If you already have the Community Edition installed, run daml install –force VERSION after setting the API key to replace it with the Enterprise Edition instead.

[Enterprise Edition] Daml Profiler in Alpha

Background

For large and complex Daml solutions, the speed of Daml interpretation can have a significant impact on overall system performance. The Daml Profiler now provides a tool for the developers of Daml applications to extract the timing information of real-world workflows in the well-established Speedscope file format, and analyse the performance characteristics using standard tools.

Specific changes

The Daml Sandbox distributed as part of the Enterprise Edition of Daml Connect has a new command line flag --profile-dir. If set, the timings of the interpretation of every submitted command will be stored in a json file in the provided directory. These profiles are compatible with standard analysis tools like Speedscope.
Please refer to the documentation for a complete usage example.

Impact and MIgration

This is a purely additive change.

[Enterprise Edition] Non-Repudiation in Alpha

Background

There are many scenarios in which the Daml Ledger API is offered as a service, and Daml fully supports such deployment topologies through its multi-tenancy participant node design. With this new feature, the operator of a participant node that offers the Ledger API as a service to third parties gains additional security. The non-repudiation middleware captures, validates, and stores cryptographic signatures on command submissions, providing the operator with a strong audit trail to evidence that Ledger API clients did indeed submit commands matching the recorded transactions.

Specific Changes

Enterprise Edition users have access to a new runtime component on Artifactory. The component proxies the Daml Ledger API and validates and stores cryptographic signatures on any calls to the command submission services.

Please refer to the documentation for more details.

Impact and Migration

This is a purely additive change.

Minor Improvements

  • When running Daml Script on the command line you will now see a Daml stack trace on failures to interact with the ledger which makes it significantly easier to track down which of the call fails. By default, you will only get the callsite of functions like submit. To extend the stack trace, add HasCallStack constraints to functions and those will also be included.
  • The Daml Assistant now also allows the sandbox port to be configured via --sandbox-option=--port=12345 instead of --sandbox-port. Other tools like Navigator, the JSON API and Daml Script will pick up the modified port automatically.
  • The trigger library now uses DA.Map instead of the deprecated DA.Next.Map if the targeted Daml-LF version supports it. This is a breaking change: Code that interfaced with the triggers library using DA.Next.Map, e.g. with Daml.Trigger.getCommandsInFlight or Daml.Trigger.Assert.testRule, will need to be changed to use DA.Map instead.
  • The Scala 2.12 version of the Scala Ledger API Bindings now depends on Scala 2.12.13 instead of Scala 2.12.12.
  • The compiler produces Daml-LF 1.12 by default. LF 1.12 significantly reduces transaction size.

Bugfixes

  • gRPC status codes for inconsistency rejections and Daml-LF errors (ContractNotFound, ReplayMismatch) were brought in line with their intended meaning by changing them from INVALID_ARGUMENT to ABORTED.
  • DALFs in data-dependencies that are imported directly now require corresponding --package flags to make them visible. If you specify DALFs instead of DARs you also have to list all transitive dependencies, but typically you only want to expose your direct dependencies. Previously this was impossible. With this change, DALFs that are data-dependencies are no longer treated as main DALFs so you have more control over which packages get exposed.
  • The Scala Codegen now supports the generic Map type added in Daml-LF 1.11 properly. Previously there were some bugs around the variance of the key type parameter which resulted in Scala compile errors in some cases. See #8879.
  • A bug in the Daml compiler was fixed where passing --ghc-option=-Werror also produced errors for warnings produced by -Wmissing-signatures even if the user did not explicitly enable this.

Integration Kit

  • The implicit conversions between Raw types (and the conversions to and from ByteString) have been removed. You will need to explicitly convert if necessary. This should not be necessary for most use cases.
  • Added a test suite for race conditions to the ledger-api-test-tool

What’s Next

  • Despite the order of magnitude performance improvements we have already accomplished, this continues to be one of our top priorities. 
  • Improved exception handling in Daml is progressing well and expected to land in one of the next Daml-LF versions.
  • We are continuing work on several features for the Enterprise Edition of Daml Connect:
    • Working towards a stable release of the profiler for Daml. The profiler helps developers write highly performant Daml code.
    • Oracle DB support throughout the Daml Connect stack in addition to the current PostgreSQL support.
  • A new primitive data type in Daml that allows arbitrary precision arithmetic. This will make it much easier to perform accurate numeric tasks in Daml.

Daml Developer Monthly – April 2021

What’s New

The anniversary of Daml’s open sourcing (“Daml Day”) was just a few days ago so happy Daml Day to our programmers, users, engineers, and all the wonderful folk that make Daml great!

Every quarter we make sure to recognize those users who went above and beyond in making Daml great; and we’ve just wrapped up our 4th community recognition ceremony, check out the winners and their contributions here! 

Want to skip reading and instead listen to this and earlier editions? Check out Richard’s podcast here.

Jobs

We’re still hiring for many positions including Engineering, Client Experience, Business Development, and Sales. If you even has so much of an inkling that a job is for you then make sure to visit digitalasset.com/careers to apply and share with your network.

We spotted a new Daml programming job in the wild from Plexus.

What We’re Reading and Watching

Some of DA’s most successful women shared insights on the triumphs and challenges of their careers at our latest DA-Versity webinar.

Ed released two top-notch posts showing us how to manage certificate revocation and harden our PostgreSQL for Daml deployments.

Lakshmi Shastry, Principal Solutions Architect at Brillio walked us through how they are using Daml to optimize clinical trials.

Simon showed us that upgrading smart contracts need not be daunting. His latest blog post demonstrates the Accept-Then-Publish pattern as one solution to this problem.

I started giving “When Daml?” talks which are the spiritual follow-up to “Why Daml?” where I dive deeper into the pros and cons of using private smart contracts (as opposed to those running on public permissionless blockchains). Unfortunately we didn’t get a recording of this talk but keep an eye out for future “When Daml?” events.

As always Richard’s weekly privacy and security news posts are jam packed with interesting stories from the always interesting world of cyber security.

Community Feature and Bug Reports

György got us to add more useful error messages for duplicate record fields.

Quid Agis caught a bug in the CSS on our Daml Cheat Sheet (it was missing) so we added it back, hopefully it stays this time.

Amiracam spotted a deprecated method being used in our quickstart-java template.

Joel found that some of our intro templates weren’t compiling, and now they are 🙂

Daml Connect 1.12 is out!

  • Daml projects can now depend on packages deployed to the target ledger.
  • The Daml StdLib contains a new module DA.List.BuiltinOrder, which provides higher-performance versions of several functions in DA.List by using a built-in order rather than user-defined ordering. We observed up to five-fold speedups in benchmarks.
  • The Daml assistant now supports the Daml Connect Enterprise Edition (DCEE), which comes with additional features:
    • The DCEE has an Alpha feature to validate and store signatures on command submissions. This provides non-repudiation in cases where the Ledger API is exposed as a service.
    • The DCEE contains a Profiler in Alpha which allows you to extract performance information for Daml interpretation.

The full release notes and installation instructions for Daml Connect 1.12.0 RC can be found here.

What’s Next

  • Despite the order of magnitude performance improvements we have already accomplished, this continues to be one of our top priorities. 
  • Improved exception handling in Daml is progressing well and expected to land in one of the next Daml-LF versions.
  • We are continuing work on several features for the Enterprise Edition of Daml Connect:
    • Working towards a stable release of the profiler for Daml. The profiler helps developers write highly performant Daml code.
    • Oracle DB support throughout the Daml Connect stack in addition to the current PostgreSQL support.
  • A new primitive data type in Daml that allows arbitrary precision arithmetic. This will make it much easier to perform accurate numeric tasks in Daml.