The World of Smart Contracts using Daml & Solidity

Whether you consider Vitalik Buterin’s vision of a “World Computer” that gave rise to Ethereum, or Digital Asset’s vision of synchronizing business processes across organizational boundaries and who gave Linux Foundation’s Hyperledger project its name, there is no doubt that both of these worlds are converging having dealt with diverging priorities in the past.

In this blog, I will share my experiences with smart contracts from both these worlds. Having programmed in both Daml and Solidity, I found some interesting differences and similarities which I’ll try to bring out. I even show how an ERC20 token may be created and transacted in both Daml and Solidity so you can see clearly how these languages differ from each other. Thanks to Manish Grover from Digital Asset for his contributions and insights. 

I will share my experiences with smart contracts from both these worlds. Having programmed in both Daml and Solidity, I found some interesting differences and similarities which I’ll try to bring out.

Contrasting Worlds That Will Converge

As I had outlined in my 3 part LinkedIn series titled Smart Contracts: Benefits, Challenges, & Solutions, our primary purpose is to facilitate trust between independent parties so that they all have access to a common, golden source of truth without having to maintain their own silos. The implications to how we conduct business are immense. Not only can we dramatically improve operational process efficiencies, but can also provide incredible levels of decentralization that drives innovation. For example, Daml is being used to modernize the entire equities processing platform at the Australian Securities Exchange – every participant bank has access to real time information on trades, while maintaining full privacy between them. In contrast, consider the way surplus energy from individually owned solar panels is being transacted on a public blockchain platform such as Ethereum so that anyone, everywhere can participate and benefit in this free market.

Over time, there is no doubt of a need to bring both the permissioned and permissionless worlds together so they can work with each other while still preserving trust and security boundaries. 

At this time, you may also be wondering why I am not mentioning other languages being used to create multi-party, blockchain applications, viz. Java, Go, Kotlin etc. The reason is that those are general purpose languages with broader use, while Solidity and Daml are both purpose built languages for creating smart contracts.

The advantages of being a fit for purpose language are obvious – you maintain a single minded focus on the business process rather than all the plumbing that goes around it. And when your smart contracts need to talk to the outside world you can build the scaffolding necessary with other general purpose languages.

Trying to use a general purpose language to create smart contracts leads to complexity that you don’t need and the amount of code you have to write is at least 5-10 times more to achieve the same impact. To be clear, I am addressing only the smart contracts layer at this time, so I am comparing Daml and Solidity, not the other general purpose languages.

How They Stack Up 

I’ll use the following parameters to stay focused on the smart contract domain, and not the underlying blockchain characteristics like consensus etc.

What is a Contract

What causes a lot of confusion when a Solidity developer tries to pick up Daml (and vice versa) is that the concept of a contract is inherently different. Daml operates with a UTXO model –  when an action is taken on a contract, that contract is archived, and a new contract is created in its place with the new properties and holdings. 

Solidity on the other hand has an Account based model, where operations on a Contract result in properties and holdings of the underlying accounts being changed, while the contract itself remains alive. A Solidity contracts houses the Accounts. 

So a workflow in Daml is a series of contracts that get archived and created, while a workflow in Solidity are Account properties and holdings being changed. 

As you can imagine, the Solidity contract holds all the holdings of each account. In contrast, the original Daml contract holds the initial holdings, and then each new contract that gets created from a transaction (e.g. tokens being transferred from issuer to owner) becomes a child of the parent contract. This also gives rise to the unique granular privacy controls of Daml that I will describe below. You can of course model a Daml contract to mirror the Solidity way of holding accounts, but that would lead to you not being able to utilize other privacy and workflow benefits that Daml allows.  Both languages are different, and the business purpose will define how you use them.

No Obligation Without Consent

This is something that is unique to Daml. A contract cannot be created without informed consent of its signatory. 

For example, if we were to require that an owner of the token must consent to (in other words be a signatory) of the token they have, the Daml contract below cannot be instantiated if both the issuer and owner do not agree. 

While this is accomplished and enforced using a single keyword in Daml (the signatory), you would have to code for this in Solidity using the multi-sig pattern. Not a lot of code, but it leads to Daml being a lot simpler than Solidity in this respect because the validations are built in. 

How would you create such a Daml contract that requires consent from both parties who are signatories? You would follow a propose-accept pattern ensuring that both parties agree to be signatories on the contract above. A proposal contract is created first, and upon acceptance by the owner, the actual contract is created which has both signatures on it.

Granular Privacy by Default

I mentioned granular privacy. To understand this, think of the Solidity contract from earlier. A single contract holds the various account holdings, and actions will change the holdings of each account. That means that holdings are visible to everyone. That’s because Solidity was initially written for public Ethereum which meant that every transaction must be validated and confirmed by the network. When Solidity runs on a permissioned platform such as Quorum, specific constructs are needed as per the platform to enforce the updated privacy model.

In contrast, in Daml, the privacy model is uniform for any application. That model then gets mapped down to the underlying ledger. Different ledgers may support the privacy model to different extents. More information on the Daml ledger model is here. In brief, an action to change the holdings results in a new contract being created and the current contract being archived (UTXO). These contracts are only visible to those parties who have been defined as signatories, observers and controllers of choices (actions on the contract). You only have access to the contracts that you are a “party” to. This is a powerful construct in Daml that leads to subtransaction privacy – for example new owners of a token do not need to know how many tokens the previous owner had, and they don’t. So Daml makes for a simpler and more consistent developer experience at the language level. 

At the code level, you can see how this works through a proposal – acceptance pattern which also shows how the new owner can never be given tokens without their consent. 

Ease of writing & Intuitiveness

Both Daml and Solidity are very easy to write with and understand. Solidity is similar to javascript so the initial learning curve required to understand the syntax is very low. Daml on the other hand is a functional language and while very simple, it does take a few days and several sample programs to get used to the basic syntax and other common constructs like maps, folds, creating functions, data types, passing parameters etc. However, past this initial syntactical hurdle, both languages then need the developers to get up to speed with the way multi-party and decentralized applications behave. 

However, Daml has also been designed to be incredibly intuitive and closer to the business flow. It feels and reads like English, so productivity is very high. In fact, a developer and a business analyst can sit down side by side and hammer out an entire business process of reasonable complexity within a few hours. These Daml models can then be run immediately using the Navigator tool within the SDK so that the end to end process and disclosure requirements can be validated immediately. A default UI is derived automatically and entirely from the code. A new cloud based environment is also available for Daml. 

So in my opinion, when it comes to developer experience and speed, the Daml SDK takes the cake. In fact, the Navigator is good enough to use for customer and stakeholder demos as well. The SDK spins up a sandbox with an in-memory ledger to accomplish this. You can create, test and impressively demo your application in just a few hours! The integration with VSCode also has a built in test harness (scenario testing) that makes debugging the business process painless.

Development in Solidity on the other hand, while being slightly more complex, is actually supported by the power of a large open ecosystem. You would use something like Remix, which is very comprehensive, but also more complex to use for business users. The obvious downside of a large open community is that the tooling must be installed and integrated, and often is not as rapid to use and deploy as with the Daml SDK. However, the tools in the Solidity ecosystem let you interact with the testnet, and actually test your processes on a live public testnet, something that the Daml SDK cannot yet do. In addition, the Solidity community is very large, so chances are that someone somewhere has already solved the problem you are facing when it comes to getting support for your development. Although the Daml community is very responsive too so it is unlikely you have to wait for more than a few hours before someone steps in to help.

Portability & Interoperability

Portability means that your smart contracts can run as is on multiple ledgers. Interoperability means that your smart contracts can transact across multiple ledgers. 

On the portability front, both Daml and Solidity work on similar principles, in that both EVM and the Daml Runtime engine can be integrated to run on multiple ledgers. The primary difference is that while the Daml community has made it a specific objective to integrate the Daml runtime with a variety of ledgers, the support for EVM on multiple ledgers is up to the ledger developers. As of last count, Daml already runs on most popular ledgers including Corda, VMware, Hyperledger Fabric, Sawtooth, and now Besu (an Ethereum client). See here for the latest list of Daml enabled ledgers

One of the key differentiators in Daml portability is for enterprise use cases that do not need the use of a distributed ledger or blockchain – the Daml run time has been integrated to run on SQL databases as well (PostgreSQL, AWS Aurora, etc.). This development brings the promise of the “World Computer” to an enterprise where multiple applications can be integrated using Daml. Currently this is not possible with Solidity.  

Finally, Daml has already accomplished the objective of executing transactions atomically across multiple ledgers. Check out this interoperability demo. As we move towards the holy grail of a World Computer, this capability will be critical in connecting both permissioned and public networks.

So when it comes to portability of your applications and interoperability between applications on different ledgers, Daml has a clear upper hand in my view.

Conclusion

As you can see, I found that there is a place for both Solidity and Daml. Both are simple to use and purpose-built for smart contracts. For anyone writing smart contract based applications, either Daml or Solidity should be the choice by default. 

Overall, I found that Daml scores higher when it comes to intuitiveness of your applications and overall team productivity. Any business application needs all kinds of stakeholders to come together – technical and non-technical – and Daml makes it much easier to do so. In addition, proactive cross-ledger support, applicability within the enterprise  and finally the promise of interoperability make Daml the preferred choice in my view, especially for permissioned use cases.  

These are my personal thoughts and point of views. I am not representing my current or previous employers through these posts.

Daml has also a new learn section where you can begin to code online:

Learn Daml online

If you want to master Daml smart contracts, you should also read:

Behind DABL’s one-button authentication

Editor’s note: This post is the second in our series “How to Make the Most of the Daml Application Framework.” Part 1 introduced the fundamentals of Daml/DABL architecture; now Part 2 explains how that architecture simplifies the challenges of user authentication. 

Face it: Unless you’re a hard-core fan of identity and access management, user authentication is a hassle. 

When deploying a new application, there’s a thicket of credential validation and logic you need to chop through for current and new users on the system. 

Even if you’re the person who set up the application in the first place, you don’t have all the permission to manipulate and view that data. And validating user-supplied passwords securely is an unpleasant process, in light of security liability, complexity of the hash store, denial of service concerns and more. 

If you’re creating an SaaS application, is there a faster, more graceful way to onboard users?

After putting a lot of sweat equity into the challenge, we’ve provided Daml developers “the button,” an embeddable widget that lets you implement the whole process seamlessly when deploying to project:DABL. 

A code sample showing the process of log-in with project DABL

This feature was created to address the demands of Digital Asset’s own engineering team: We needed the ability to authenticate to DABL as parties of Daml applications, then we thought about how we could make it available to the other developers as well. 

The secret to seamless authentication is the way Daml architecture distinguishes between on- and off-ledger operations. 

A Daml application already requires templates to describe a role-based administrator as well as individual users. All that is left is to do is add some credential validation to get a complete auth story. 

DABL auth makes it easy for you to onboard users to your application while offering them a guarantee that they are the only parties who can manipulate their data. 

This increases the cool factor of authentication, since you now have a bird’s-eye view of who is using your application without compromising security and privacy. 

If you want to get your hands on the button, go to Daml.com, download the SDK, and use projectdabl.com today. Daml is open source and always free to use, and DABL is free to start. You can find a generic React UI with the login widget implemented in this open source repo that is deployable in DABL today.

Please join us virtually on March 26th to discuss how Daml & DABL can help you launch the next great idea. We will show you how you can build and deploy a complete application in the time it takes to host a meetup!

Centralized, distributed, decentralized, umm…what?

This is the first article in a series of posts covering everything from privacy, to smart contracts, to portability, and more concepts related to distributed systems.

When it comes to permissions, ownership, and authority there are roughly three different types of systems: centralized, distributed, and decentralized. Different business needs require different forms of ownership, authority, and permissions between the parties that are involved in any given workflow. In today’s world these workflows are often represented as applications that implement the underlying logic for a given business process.

The thing to think about here is what type of business workflow do I have that I will need to turn into an application and deploy on a system with one of these three properties. Keep this in mind as we work through these types of systems and then discuss applications that can run on them.

“If […] multiple entities/stakeholders need to know and enforce what is going on within the network then a distributed application may help you strike the right balance between collective decision making and adapting to changing needs. Daml does this.”

What is centralized, distributed, and decentralized? 

Centralized is simple, a single entity has final say on all rules within the system, they can enforce the rules, change them, and ignore them to the degree they see fit. Websites would generally fall into the centralized category.

Distributed means multiple entities by some sort of process have come to have final say on the rules of the system, the control and relationships between these entities may change over time but ultimately this collaboration is the one in control. An example of a distributed system would be DNS in that it’s controlled by a multistakeholder group called ICANN.

Decentralized, perhaps the most misunderstood, simply means that all entities can freely choose (ie. without the approval of other entities) to directly participate in the network have their own independent and final say on the rules of the network. When they agree they can interact, and when they don’t they can’t. A decentralized system would be a network like Bitcoin or Tor.

What are the pros and cons of these systems?

A well designed centralized system will be maximally nimble, by reducing its ownership overhead it is able to change its rules to meet the needs of a changing world. Whereas on the cons side such systems also have the easiest time implementing rules that are detrimental to the system, or to remove those that were beneficial.

Distributed systems remain similarly nimble to centralized systems when those participating in them can come to a collective agreement about a change. However when entities disagree the system won’t change as easily. This provides the benefit of avoiding detrimental rule changes but may also hinder or delay the implementation of beneficial rules. In general, however, slower changing systems break less, and in systems requiring high reliability a little bit of friction is a good thing.

Decentralized systems are not nimble, they are publicly accessible, open to anyone to join, and opt for a slow speed of rule change. In exchange they gain maximum resilience such that all members of the system must agree to change the system; as opposed to a limited set of privileged users. Due to the extreme trade-offs these systems make they have a narrow band of uses where they are highly desirable, but for most regular business cases a centralized or distributed model is much better.

The application layer

We’ve spoken a lot about systems but now we need to talk about applications. Every application can have some variant of the 3 types of system design within itself and that may vary. In fact, you can run completely centralized applications on top of less centralized architecture. An example here might be a Daml application that has you as the sole signatory for exercising choices on a contract (ie. telling the contract execution/application what to do). You can go ahead and deploy it on a distributed network with many peers enforcing that the application executes as designed. So the enforcement of network execution and state is distributed, but the rules of the application are controlled entirely by you.

Effectively every level of increasing authority at the application layer can run on top of a system that is equally or more permissive, but not less. This is illustrated below.

Here we see distributed or centralized applications can run on distributed and decentralized systems. Any application can run on a network either as or less permissioned than itself.

Communication goes the same way. Centralized applications and systems generally have no difficulty keeping consistency with distributed and decentralized systems. However the opposite is not true, a distributed system could not expect a centralized system to give it consistent data every day. In the example above our Daml application could be running on a distributed network and have a side effect where some state is then recorded on a decentralized network that it is talking to.

When do I use these systems?

You use these systems when you have an application or workflow that has a business need for them. In general you’ll use these systems depending on who you need to involve directly in the maintenance of them and enforcement of rules.

If your business is developing an internal tool or consumer-facing website/service that deals solely between your business and the consumer then centralized may give you the best flexibility for iterating and improving that application. Daml does this.

If you have a complex series of relationships where multiple entities/stakeholders need to know and enforce what is going on within the network then a distributed application may help you strike the right balance between collective decision making and adapting to changing needs. Daml does this too.

If you’re looking for a completely open network where the entire world has equal ability to participate and determine the rules and state of the system then you’ll want to create a decentralized system. Bitcoin and a few other non-blockchain systems like Tor effectively do this.

Hopefully this short primer on the nature of these types of systems has been useful. If you find yourself wanting to create a distributed (or centralized) application then you may want to check out Daml which provides a highly portable language that’s specifically geared towards managing business processes and permissions. There’s very little backend to worry about and it runs on top of everything from SQL to Hyperledger FabricSawtooth, and much more.

Also stay tuned for the next articles in this series where we’ll cover the theoretical basis of everything from privacy, to smart contracts, to portability and more.

How Daml and DABL Lower the Cost of Innovation

When it comes to funding a business built on a differentiated product line, the operating budget keeps the lights on — but innovation fuels growth (and even keeps products competitive with competitors). 

Too often, keeping costs down comes at the expense of innovation. Since at least some operational costs are essential to functioning at all, businesses may kick product innovation down the road, even if doing so incurs big opportunity costs. 

Companies often dismiss innovation because they assume the table stakes will be too high to accomplish anything without investing significant time and money. A proof-of-concept that costs six figures and months of work may be a significant hurdle to overcome! 

That’s one cool thing about building software in Daml and deploying it with project:DABL: The barrier to entry drops dramatically when companies can create and ship functioning software in days. 

Will this be the start of another technology boom?

This handy chart shows us the explosive growth in the fintech industry quickly after the global financial crisis. Similarly, We believe our current crisis will be the start of the next revolution. These unfortunate situations create tremendous opportunity to improve and drive change and the coming months and years will be no different than before.

Old-school development drains innovation dollars

When you look at the cost of software innovation, most of it isn’t innovative at all. Most time on proof-of-concept projects is spent building the “scaffolding” to support features and functionality that set those applications apart. Market-testing the actual idea takes a backseat to building and deploying services end users will never interact with directly. 

What’s more, that construction work demands a broad set of skills. Few engineers are equipped to deploy and configure all the core infrastructure, manage all the security settings, and create all the necessary environments for the system — all before the first functional build. 

That means fewer resources for creating the innovative features you want and for learning how early adopters receive them. What’s more, it means key stakeholders in sales and marketing may wait months before they can see and respond to the way the product team has put the concept into action. 

The Daml and DABL Way focuses on differentiation

Daml, by contrast, handles this back-end block and tackling. The only code you ever write is business logic that describes the unique behavior of your application. 

That also means Daml applications are easily portable to any compatible blockchain or database. 

When you are ready to deploy to production, DABL provides a production environment with a “sandbox as a service” feel, where your development team can build and deploy new ideas quickly. 

The rapid pace of innovation lets stakeholders and early users interact with fully functional apps in days, not months. It also allows the team to try multiple approaches on an identical framework to identify the real differences among them. 

The result: Faster, more-educated decision making at a far lower cost. 

The next wave of innovation is already here

We invite those of you who wish to innovate under an economical, fast feedback regime to go to Daml.com, download the SDK, and use projectdabl.com today. Daml is open source and always free to use and DABL is free to start. Don’t let the uncertainty of the markets today and the cost of experimenting with traditional software slow your company down. After all, necessity is the mother of all invention.

Please join us virtually on March 26th to discuss how Daml & DABL can help you launch the next great idea. We will show you how you can build and deploy a complete application in the time it takes to host a meetup!

How Daml helps the Chief Customer Respect Officer — and other CxOs too

The views expressed in this blog post are mine. They do not represent the official view of either Digital Asset — developers of Daml — , or Blockchain Competence Center, where I am Chief Product Officer.

If management teams were structured around the needs of key stakeholder groups, they had a Chief Customer Love Officer (CCLO), a Chief Customer Respect Officer (CCRO), a Chief Partner Happiness Officer (CPHO; partners including employees as well as vendors), and of course a Chief Investor Happiness Officer (CIHO).

The domains of the CCLO and the CCRO, that is Customer Love and Customer Respect, align with the two dimensions of customer engagement, according to the Lovemarks model:

The inventor of the model, Kevin Roberts did a great job in separating these two dimensions, which require very different mindsets on the supply side of the business model, in spite of being hardly distinguishable in the eyes of the customers.

The Lovemarks model explains why it’s mission impossible to spark Customer Love with high technology: it comes only from high touch interactions, which stimulate Mystery, Sensuality, and Intimacy.

On the other hand, Customer Respect — which consists of reliable service, transparent pricing and fair dispute resolution among other things, and all these even in the case when contributions of different service providers/vendors are combined — is very much the domain of technology in general, and Smart contract/Trigger /(Maybe blockchain)* based Business Process Automation in particular.

*This is an insider joke for Daml /Haskell programmers, who know how to use the polymorphic Optional/Maybe type; if you want to join the club of the initiated, check out the Daml documentation.

By the latter, I mean more or less the same as what is called by the creators of Daml and its synchronization protocol, the interoperability solution being developed by Digital Asset to enable atomic transactions across Daml driven ledgers.

I use the following one-pager — hijacking the famous Business Model Canvas — to illustrate how such a shared synchronization/automation layer supports Customer Respect and to a certain degree Partner Happiness:

The drawing was inspired not only by Daml and its synchronization protocol. I also find very enlightening the articles of Corda CTO Richard Gendall Brown, from whom I borrowed the WISIWYS acronym. The “contract law” part refers to a crucial concept of the Daml smart contract language and execution platform: it follows the principles of contract law by implementing a hierarchically atomic transaction authorization mechanism (under the hood making good use of monads in Haskell, which underpins the Daml smart contract language).

I have highlighted the private bot function of the platform, which is a powerful complement to the enforcement of common rules by the smart contracts. (Private bots can be run on the client platforms communicating with the shared ledger, but also on the Daml platform itself through its new Triggers feature. A trigger is a bot, which listens to events on a set of contract templates and reacts to them.)

Being a one-pager, the slide is dense, so the Customer Respect benefits in the bubble might be difficult to read, so I repeat here the list, grouped related items:

  • One-Stop-Shop, personalized service, delegating authority
  • Fair charging, risk/reward balance, loyalty reward, consumer advocacy, guaranteed payment
  • Privacy / trade secret / IP protection
    Information symmetry, fair dispute resolution
  • Etc.

The fact that I have focused so far on how the shared synchronization/automation platform helps the CCRO by promoting Customer Respect, doesn’t mean that the domains of the other CxOs don’t benefit from it.

Partnership Happiness (again, partners include employees as well as vendors) is promoted by fostering a relationship that can be described by the Italian quip “patti chiari, amicizia lunga” — or in less melodic English translation “clear agreements, long friendship”. It also reduces three types of market friction, described by the IBM-sponsored Blockchain for dummies booklet: Information, Interaction, and Innovation friction.

A special kind of partnership, the collaboration between IT and business experts — by all accounts, one of the key success criteria of business-related IT projects — is supported nicely by Daml, which is very much a “Ubiquitous Language” not just supporting the right naming of objects but the hands-on demonstrating of the semantics of them by scenario testing and contract template package visualization.

I also use hand-written contract templates and poker chips in workshops. Analog tools that can be passed around inspire thinking immensely.

The Chief Customer Love Officer is an indirect beneficiary of high Customer Respect: she can rest assured that her hard work around Customer Love is not ruined by petty annoyances.

And lastly but certainly not least importantly: if all the other CxOs are performing well— and the platform costs remain within a reasonable budget, which is very much doable — the bottom line cannot suffer. Which also makes the Chief Investor Happiness Officer happier.

Release of Daml SDK 0.13.55

Daml SDK 0.13.55 has been released on the 18th of March 2020. You can install it using

daml install latest

If you’re planning to upgrade your Daml SDK to take advantage of our newest features please note that some action may be required on your part. If you’re not planning to upgrade then no change is necessary.

Summary

  • Daml Script is officially supported
    • Action required by April 2020 if you use scenarios for Sandbox initialization
  • Daml Repl is available as an experimental feature
  • Daml-LF 1.8 adds support for cross-SDK DAR Dependencies and Contract Upgrades
    • Minor action required to mitigate an upcoming restriction to Daml type naming
  • Improved daml.yaml features
  • More consistent APIs regarding contract visibility
    • Potentially breaking change that is unlikely to affect any existing Daml applications
  • New command deduplication feature
    • Action required by April 2020 if you rely on maximum record time for command deduplication
  • Security improvement
    • Immediate action required to make SDK components continue to listen on external network interfaces

Detailed Release Notes

Daml Script – A better way to initialize and test your ledger

Background

Being able to script the interaction with a Daml ledger is useful for testing, application initialization, and even one-off operations in production use. Daml scenarios cover a subset of those uses: Realtime testing and feedback in the IDE and ledger initialization in the Sandbox in static time mode. The main drawback of scenarios is that outside of the IDE, they only work with the Sandbox in static time mode and only during ledger initialisation. We have, therefore, built Daml Script, which generalizes the concepts behind Scenarios to work for any Daml Ledger, at any time. Going forward, we will deprecate ledger initialization based on Scenarios, and we recommend users to start using Daml Script now.

Specific Changes

  • Daml Script is no longer experimental
  • daml.yaml now supports the specification of an initialization script via the init-script field, which is analogous to the scenario field.
  • Daml Script now works against ledgers with authentication with tokens passed in via the –access-token-file flag
  • Daml Sandbox now shows a deprecation warning if a scenario is used for initialization

Impact and Migration

Scenarios for Sandbox initialization will no longer be supported with the next SDK release in April 2020, but will continue to be supported for Daml model testing in the IDE and command line. If you are using a scenario to initialize the Sandbox today, we recommend migrating that to a Daml script. Daml Script has similar syntax to Scenarios, and the migration from scenarios to Daml script is documented.

 

Experimental: Daml Repl – Interactive Daml Script

Background

We are introducing an interactive read-eval-print-loop (REPL) for interacting with a Daml ledger. This feature is analogous to using an interactive shell session to examine and change the data in a relational database. It is based on Daml Script and allows accessing all functions from your Daml code. We encourage you to test this feature and provide feedback. It is still marked as experimental, so we can incorporate your feedback effectively and efficiently.

Specific Changes

  • Introduction of the daml repl cli command

Impact and Migration

Daml Repl is an entirely new feature, and no changes to existing projects are needed. Please refer to the docs for more information on this new functionality.

 

Daml-LF 1.8 brings cross-SDK upgrades and data dependencies

Background

One of Daml’s unique features is that the clear data ownership based on signatories allows for clean contract upgrades directly from within Daml. So far, this required SDK versions of the original and the new Daml contracts to be equal, a limitation that we obviously wanted to lift. This release lifts this restriction and adds support for contract migrations across SDK versions thanks to adding support for data-dependencies in daml.yaml.

dependencies and data-dependencies are source and binary dependencies respectively. dependencies should be used to include any libraries (e.g. the Daml Standard Library) that are always deployed together with the project, whereas data-dependencies should be used for any dependencies that are independently deployable, for example the Daml Finance Library, or applications already running on the target ledger.

Specific Changes

  • daml.yaml now supports a section for data-dependencies in addition to dependencies
  • The already deprecated daml migrate command has been removed
  • Data constructors for record types have to be the same as the type name.

Impact and Migration

To make use of this feature, Daml projects have to be compiled to Daml-LF 1.8. The current default is still 1.7, and so this has to be done by passing in the flag –target=1.8. Detailed information on the upgrading and dependency functionality can be found in the docs.

Data constructors that don’t match record type names have to be renamed. For example, if you had a record type data Foo = Bar with .., you need to change it to data Foo = Foo with ..

 

More functionality in daml.yaml

Background

The project file daml.yaml should tell the Daml Assistant CLI everything it needs to know to set up a test environment using daml start. However, until this release, there were certain Sandbox, Navigator, and HTTP JSON API settings that needed to be set through additional command line flags. These can now be set using sandbox-options, navigator-options and json-api-options sections in daml.yaml.

Specific changes

  • Items under the sandbox-options, navigator-options and json-api-options sections in daml.yaml are picked up by daml start and passed to the respective components.

Impact and Migration

Command line arguments like daml start –sandbox-option=”–wall-clock-time” will keep working as before, but you can now simplify your CLI usage moving them into daml.yaml.

 

Cleanup of some API services and components

Background

Privacy is one of Daml’s primary concerns, with visibility of data usually constrained to signatories and observers of contracts. However, there are two well-documented and controlled mechanisms through which non-observers can learn about contracts: Divulgence and Witnessing.

Whether events or contracts that are known due to those mechanisms are shown in APIs or tools used to be inconsistent and led to oddities such as the Navigator showing assets that had been transferred. This change addresses these inconsistencies and ensures divulged and witnessed contracts are only included in APIs returning transaction trees.

Specific Changes

  • The Flat Transaction Service and Active Contract Service no longer include divulged and witnessed contracts
  • The JSON API no longer includes divulged and witnessed contracts
  • The Extractor no longer stores divulged and witnessed contracts and the column contract.witness_parties has been renamed to contract.stakeholders

Impact and Migration

Applications are unlikely to be accidentally relying on the current behaviour so there is probably little to no impact on existing Daml applications.

In general, if you want to share data on a Daml ledger, we recommend using the observer mechanism or sharing it in dedicated sharing contracts as highlighted in the Broadcast Example.

 

New Command Deduplication Mechanism

Background

For certain applications, it is crucially important that commands will not be processed twice, even if application or ledger components crash or network links fail. The new command deduplication mechanism gives a way to achieve that.

The previous mechanism based on Maximum Record Time (MRT) and Checkpoints on the CompletionStream was difficult to use in practice and didn’t generalise to ledgers without a linearly ordered record time. The new mechanism is designed to replace the old one over the course of the next Daml SDK releases.

Specific Change

  • The Command and CommandSubmission services add a deduplication_time parameter to commands during which no second command with the commandId can be submitted.

Impact and Migration

The maximum record time based mechanism for command deduplication is now deprecated and will be removed with the next SDK release. We recommend switching from the MRT-based mechanism to deduplication_time based one. Detailed documentation here.

 

Minor Improvements

  • JSON API
    • The JSON API has a new /v1/create-and-exercise endpoint that allows the submission of commands creating a contract and then immediately exercising a choice on it.
    • The experimental websocket streaming version no longer sends a {“live”: true} marker to indicate live data is starting. Instead, live data is indicated by the presence of an offset.
    • The /v1/parties endpoint now allows POST requests, which expect a JSON array of party identifiers as input, and returns the corresponding party details.
  • Language
    • The pragma daml 1.2 is now optional. This is in preparation for Daml SDK 1.0 from which time on the language won’t be versioned independently from the SDK.
  • Ledgers
    • Rejected submissions are now logged at a lower “INFO” level to remove a source of warnings/errors without relation to server health.
    • The Sandbox can now produce random ContractIds consistent with other ledger implementations. This can be activated using the flags –contract-id-seeding=weak or –contract-id-seeding=strong. The weak version uses a less safe, non-blocking random number source.
  • Security
    • All services now bind to localhost (127.0.0.1) instead to all interfaces (0.0.0.0). This default can be overridden using command line flags
      • daml sandbox –address 0.0.0.0
      • daml navigator 0.0.0.0 6865
      • daml json-api –address 0.0.0.0

A new release cadence for the Daml SDK

It’s been nearly a year since Digital Asset open sourced Daml. Over that year, we have been working on a rapid release cadence to bring new features to our users as quickly as possible in order to provide the best development experience in the market for distributed applications. At the same time, we’ve seen major Daml projects move towards production and numerous Daml ledger integrations come to life. And as the Daml ecosystem is maturing, it is also time to stabilise the Daml SDK and associated developer experience. The first step in that process is to move to a slower release cadence.

From March 2020, the Daml SDK will be released on a monthly cadence. On the first or second Thursday of each month, we will announce a release candidate together with detailed release notes, and an outlook to the next release. The following Monday, we will host an open door Zoom conference for community members to ask questions about the upcoming release or provide feedback, and on the Wednesday of that week, the release candidate will be marked stable. At that point, the Daml SDK Assistant will start informing users that a new release is available.

For those that want to stay on the cutting edge, we will continue to make weekly snapshot releases that can be found on GitHub and downloaded using the Daml SDK Assistant.

Release Candidate for SDK 0.13.55

The preliminary release notes for Daml SDK 0.13.55. can be found here. The community open door session will be held Monday 16th March 2.30pm-3.30pm CET on Zoom.

Highlights of the upcoming release are

  • Daml Script is now stable
  • Daml Repl allows real time interaction with live Daml ledgers using Daml
  • Support for seamless Daml Contract Upgrades across SDK versions

A little Daml Repl teaser:

 

What’s Next

We are working towards the first stable Daml SDK release in April. The majority of work between now and then amounts to tidying up, cleaning up UX issues, reducing architectural debt, and removing deprecated features.

  • The Quickstart / Getting Started documentation will be overhauled
  • The Ledger Time model will be upgraded so ledger_effective_time no longer needs to be supplied as part of command submission
    • Record time will no longer be guaranteed to be linearly ordered to support even more distributed ledgers
    • Maximum Record Time will be removed from the API
    • Checkpoints will be removed from the Completion Service
  • The Daml Sandbox will have a new architecture much more closely aligned with other Daml Ledgers
    • Contract Ids will be hashes rather than sequence numbers
    • The default time mode will switch to wall clock
    • Ledger initialization via scenarios will be removed
    • Ledger Offsets will no longer be sequence numbers, but instead increasing integers
  • Maven artefacts will be versioned in line with the SDK
  • Daml will get a generic Map type to replace the current TextMap

‘That’s awesome, but how do I architect this?’

This is a question that I hear often when introducing companies and developers to Daml and project:DABL. The story is clear – achieve much more through focusing on your application – but where to begin is not always so straightforward. There are some differences in building applications using Daml that have great returns when done properly.

This post will present an overview of preparing to build a Daml application — and queue up future posts — by looking at major ways your application architecture will be much easier to develop from its predecessors, how you should set it up, and what you can do with it. 

It’s Part 1 of an ongoing series on Daml design best practices: “How to Make the Most of the Daml Application Framework.”

How Daml + DABL are different

Put simply, Daml + DABL does a lot for you.

2020.03.10_himss_dambl_illustration

In traditional application stacks, each layer requires a different skill set — and more importantly, a different focus. 

UX and application features are contained in the layers most visible to end users. The deeper a development team goes in developing back-end functionality, the more opaque the technology becomes to those users, and the knottier the problems are. 

Traditional programming requires a diverse engineering team to create a stack several layers deep. Daml and DABL reduce the number of layers you need to develop, handling much of the functionality itself; you only have to specify a UI at the front end and a Daml application at the back end. 

You and your team spends time defining the behavior of the application — never wasting a minute on something your user won’t see. What’s more, any developer can access the application through its APIs without worrying about access to the API layer differing from the services or UI.

The Daml + DABL advantage

So how do these differences empower applications created in Daml and deployed within project:DABL?

Daml

An application built using the strongly typed Daml framework frees developers from the countless hours of tedium wrought by endless boilerplate and the minutiae of gluing together a hodgepodge of disparate components. And it frees the business of the anxiety of supporting a frankenstack with the everpresent tune of ‘but muh tech debt!’ Nevermind the Sisyphean task of hiring more and more engineers of different skills and competencies. All you really wanted to do was build a straightforward CRUD app and deliver some value via the internet. 

Using Daml for your back-end code and DABL for your deployment environment allows you to focus on the features and business logic of your application — exclusively. Gone are the days of provisioning; maintaining; and accounting for huge, diverse software and infrastructure stacks.

project:DABL

DABL is a purpose-built cloud environment for Daml applications. When you load your Daml file, your application immediately goes live — ready to scale to your needs — without any complicated infrastructure configuration. That means no wrestling with servers; databases; load balancing; security; authorization; tokens; and many, many other functions your end users just expect to work. 

project:DABL simplifies building an application down to writing a set of Daml and React or Typescript files. 

Daml and DABL let businesses build lean engineering teams that are 100 percent focused on the value to their users.

Daml architecture in action

To round out this introduction, we’ll introduce four key differentiators that make Daml powerful and fast to build with: 

  1. Strongly typed front and back ends that work together seamlessly
  2. An asynchronous, event-driven system hidden in an approachable language
  3. You only define the business logic. That means no devops and no systems code
  4. Daml’s and DABL’s auto-generated architecture, which gives you automatic APIs, automatic authorization, access control, and improved security

The following section will describe the benefits of these four differentiators in greater depth. It’s aimed at readers with intermediate to high command of programming concepts. 

Seamless alignment of front and back ends. By leveraging a declarative paradigm for specification of business processes that champions the gains traditionally associated with referential transparency, an entire class of programming errors that are caused by incorrectly synchronized mutation of shared state is avoided, leading to enhanced productivity.

The rich development toolset (along with minimal boilerplate code) makes the development experience fun. It removes all the clutter and lets you dive right in to defining your data model and end-to-end workflow without losing focus. Then the rest of the development is simply glueing the UI with the auto-generated JSON APIs and making it look pretty. 

An asynchronous, event-driven system. Applications are decoupled into event sources (including actions initiated by the end user) and event sinks (which receive incoming events). Splitting up these tasks creates a drastically simplified and compartmentalized model for application design that allows more events to run simultaneously, making applications faster and more flexible.

No devops, no system code. By focusing on Daml and UI developers, startups eliminate the need for a wide spectrum of engineering skills, such as security and devops … You go from struggling to field a team to creating a functioning product and finding customers.

Auto-generated architecture. Because we’re defining everything that can change in the system, we’re ready for APIs. Daml’s codebase creates external-facing APIs for you. You don’t have to build a role layer or an API layer, and you don’t have to think about scaling the system.

By providing a scalable and first-class abstraction for data storage that incorporates its own authorization model, Daml uses a common language and system of record to keep track of who is allowed to do what. This eliminates tricky security vulnerabilities caused by inconsistent mapping between authenticated principals and service component data access on behalf of users.

Any non-trivial business-use case will require a number of data state transitions which (almost always) are orchestrated by an external program or service. This service may fail halfway through managing those transitions. Correct recovery is a major challenge, especially when dealing with mission-critical data (like financial transactions or any other transfer of value). Daml lets you take that business logic and orchestration and put all of it (or as much as you want) in the body of the actual Daml templates. This guarantees you atomic state transitions with rich business logic. Either everything happens properly or nothing happens at all, which removes all the hassle of ever ending up with a corrupt or intermediate state.

Access control is beautifully baked into the language and distilled into a single native type named “party” with a few keywords around it that grant it rights and enforce obligations. Although this steepens the learning curve at first, it quickly pays off: If modeled properly, it completely eliminates erroneous edge cases or the possibility of bad actors corrupting data and ultimately the app.

Conclusion: The Daml/DABL difference

This post introduced some fundamental concepts behind designing applications in Daml and deploying them via project:DABL. At a high level, it also explained how this architecture changes engineering requirements and the focus of product development within your team. 

Keep reading upcoming installments of “How to Make the Most of Daml Application Architecture” to dig deeper into the ways Daml and project:DABL revolutionize product design. 

Daml has also a new learn section where you can begin to code online:

Learn Daml online

If you want to master Daml smart contracts, you should also read:

What’s the Future for OpenWork?

  • We’re open sourcing OpenWork: 3 “radically transparent” productivity apps backed by smart contracts. BoardChat, and a vacation tracker (coming soon!)
  • The apps are currently live and in use at Digital Asset. We’re committed to keeping them maintained as part of our internal tooling but we’d love to see others contribute. There are new products we’ll be adding soon, but we’re really interested in seeing what the community would like
  • There are interesting future directions for the suite, including how to integrate them into other smart contract workflows such as those uploaded by users, and interacting with other smart contracts running on different ledgers
  • If you’re an organization that’s interested in running your collaboration tooling on top of portable data, including blockchains, you should try OpenWork today

This is the final post in our introduction to OpenWork, a collection of open source SaaS productivity and business tools built on top of smart contracts. Previous posts introduced the suite, and walked through the product features.

Missed the first in the series? Smart Contracts for… SaaS apps?!

OpenWork started as an experiment: to see if modern smart contract languages like Daml were convenient enough to use in non-currency use cases like productivity apps. The result was a resounding yes! While there is some overhead, the benefits you get out of the box massively outweigh the costs. We did learn some things about the pain points with our stack and that has helped us prioritize our backlog.

While experimental, we found the tools in the suite useful and have been using them internally. For certain types of user or communities who care about open source, data portability, or distributed infrastructure, the suite is a great fit.

But we’re not stopping there! There are a few ways we’d like to improve things:

  • Add new features to the existing products
  • Add complimentary products to the suite
  • Add the ability for different instances of the app to talk
  • Add the ability for the apps to talk to each other

If you’re looking to get started with smart contract development the first is a great option. Take a look at our backlog and see if there’s any low hanging fruit to pick up. If you’re a more experienced Daml developer have a think about the latter. A couple of our products started from open source apps which were written for other persistence layers — this can be a great way to get the ball rolling quickly!

For the 3rd point, we hope to make some initial progress by allowing UIs to talk to multiple instances of an app. If you have different apps or groups chats running on different infrastructure then the UI should show you a unified view onto those instances. Cross-ledger updates to ledgers are more interesting, for example, allowing users to move a board from once instance to another (assuming that all board signatories sign off, of course). If all these instances ran on the same ledger — such as a public blockchain — that would be easy. But our belief is that different infrastructure is suitable for different use cases and that it’s better to allow different ledgers, even those running different frameworks to interoperate. We have some very interesting technology coming soon to Daml to allow exactly that.

Once that piece is in place we unlock the real potential of radically transparent SaaS: an ecosystem of running services which can be freely remixed and extended, even by end-users. Smart contracts do not stand alone. They’re designed to act in concert as part of a transaction with other smart contracts. For example, a capital markets use case running on VMware Blockchain might need human sign-off for a particular exception case. That could trigger a new card to be created in Board running on DABL and assigned to a reviewer. When they mark the card as complete the process can continue on the original ledger. This level of seamless interoperability is really the great potential of smart contracts, and we can’t wait to see what it’ll mean for business tools.


This is the final post in this series on the OpenWork apps but we’ll be publishing more information as we improve the suite. In the meantime, take Board for a spintry out chat, and download the Daml SDK to start building your own radically transparent SaaS apps.

Deep-Six the PowerPoint

One of the cool things about working with DABL is that I get to work with companies of all sizes and cultures who are trying to convince their customers that they have a decent idea for something.

For example, I just got out of a three-day workshop between DA, a well-known $1 billion company, and an even better-known global consultancy. 

We were all there to develop an idea to transform another industry using DLT. The workshop included subject matter experts, project managers, business analysts, experts in design methodology, and the usual menagerie of tech peeps. We ordered lunch, put things on stickies and affixed them to flip charts. We talked value-prop, tech-stack, services, network-effect, and roadmap. 

Those three days and their prep cost hundreds of thousands in consulting dollars, but we managed to build consensus around the thing we wanted to build, to put in front of CEOs to get their buy-in. 

In contrast, the week before that, an entrepreneur came in with a concept for an international charitable microfinance platform. The idea was very much in its early stages — he said his developer was only available on weekends because “day job” — so we spent about an hour whiteboarding the workflows and discussing potential tech problems and solutions. 

Eventually, this entrepreneur will need buy-in from various different types of organizations who must participate in the endeavor, including financial institutions and NGOs in different regulatory regimes.

While the two endeavors are starting in very different places, they share an identical next step: Go out, pitch the idea, and win partner and user support. 

Both enterprises now have a choice of where they will spend their effort to make this pitch compelling. 

Obviously, the best way to show your client that you have something is … 

… To show that you have something. The best option — unshackled from material concerns like time and money — is to build the product, demo it, and revise it to meet your client where they’re at. 

Also obviously, people rarely do this. Instead — and this is the instinct of pretty much every consultancy, ever — is to burn hours building slideware. This’ll spell out in prose the goal of the software, the workflows (who doesn’t love UML?). Bonus points if you can add some clever phrasing about “disruption.” 

The time and dollar cost of slideware is well known. 

In the case of the first project I cited, the consultancy was very clear: The pitch deck would cost somewhere in the low five figures — and that was for a simple collection of words on slides, maybe with a diagram or two. (It’s not unusual for the cost of decks to rise to six figures for some swanky visuals and consultantese.) 

There is variance in the quality of slideware, and the best decks can compel a decision to invest. However, slideware is limited to abstract ideas. It demonstrates nothing concrete, which inevitably makes it harder to create an emotional connection with the prospective partner reviewing it. 

People understand slideware’s shortcomings, but they fear the cost of actually starting the development work, or committing to showing real artifacts to their potential partners. 

They think that the cost of a useful artifact that can be demoed is greater than the cost of building a pitch deck — both in terms of time and money. 

I disagree.

In both cases mentioned above, we proposed that a single engineer, in the company of somebody who knows the business case, could develop the salient part of their application within a week. And frankly, most of that week would be to learn Daml; an experienced Daml developer could design both projects’ happy paths in less than two days. 

They could then deploy this to project:DABL, which takes about five minutes, and have something to demo using DABL’s console.

They could also add a front end using a tool like React or Angular. (Note that there’s no intermediate layer to worry about between DABL and the front end, since DABL provides all the REST endpoints).

Anecdotally, working on other projects, building an entire back end using Daml deployed on DABL takes about half as long as writing a React front end. 

Altogether, we’ve found this less resource-intensive than developing slideware. 

The Daml Way has a lot in common with creating a functional prototype in Agile development, with one important difference.

Unlike a prototype, your first rev in Daml is already an elegant and functional steel thread for the solution you’ll ship. Instead of a “paper prototype” tediously created in PPT, your audience can see — and try out — the sapling of the real product.

If they suggest aspects of your idea are misguided or inadequate, you can revise and enhance the actual code instead of spending your time reworking a deck. 

To see an example of the design process, consider this whimsical application my colleague Anthony built upon joining our company. He spent about 20 hours learning Daml and about 20 minutes on the actual Daml code.