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.
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:
If you want to master Daml smart contracts, you should also read:
- Interoperability between different markets and how Daml fits,
- Programming Smart contracts - A look into Daml, Kotlin & Java
- How easy it is to learn Daml,
- Some of the reasons why Daml and not Java or Solidity,
- Daml brings a paradigm shift as a programming language,
- How privacy in Daml differs from the rest and why it’s better.