I’ve been looking into the Daml documentation recently since coming across blog posts stating how Daml is a preferred smart contract language for enterprises. The deeper I have read into it, the more I see it as more of a smart contract app server that can integrate on top of other DLT/blockchains that Digital Asset has built drivers for.
Daml is a high level language (I considered it high level as it has explicit syntax for concepts such as for role based access control) used to build workflows for executing transactions that are verified against and added to a directed acyclic graph (dag) within a node or node network. The edges of this dag are what allow for the privacy of data viewing among parties of a node, and the vertices can be sequenced and included in a separate ledger, such as entries to an sql db or batched into a block on a blockchain.
The pros are that since Daml’s execution environment utilizes a dag, it can potentially allow for higher transaction throughput compared to submitting transactions directly to a blockchain-based node network. There is also the potential to ‘integrate’ with other dlt - these integrations are via the ‘drivers’ that Digital Asset builds out. Since the Daml node(s) can sit on top of another dlt, the Daml drivers are conceptually similar to layer 2 protocols’ mechanisms for writing to their respective layer 1 protocol.
I am hoping that those more familiar with Daml can clarify if my above description makes sense or if there are concepts I am misrepresenting or missing.
I work with DAML as a developer for 6-7 months already. One of the biggest advantages that I feel everyday working with it is a party/role management. I came from Python web development and it was a lot of headache to code projects that have multiple types of users like marketplaces have (admins, buyers, sellers…). Role management, endless privacy checks, etc. everything was on me. Now I have everything build in the language. Brilliant! No worries, less stress, everything is much more natural.
I’m not trying to completely answer your question, just wanted to add a comment from a developer’s point of view.
Welcome to the Daml community, it is great to have you join us.
It sounds like you have a good grasp of the causal graph that a Daml ledger uses to define consistency and validity of transactions. The concepts you are “missing” aren’t really missing as much as extensions to what you describe. For context, I am a DA engineer, with 5.5yrs full-time Daml experience, and here are a few things that I find amazing about programming in Daml:
The one thing that Daml does better than any other language out there is authorization. While Daml has evolved and improved remarkably since I started with it, Daml has always had the fundamental core of contracts, signatory, choice, and controller. The more you use Daml the more you appreciate just how incredibly powerful this combination of simple, elegant concepts really is.
While the DAG does define the relationship between transactions on the ledger, the real power of Daml’s privacy features comes from the internal structure of a Daml transaction. Each Daml transaction is a tree where every node is a sub-transaction, and is annotated with the witnesses of that sub-transaction. This means that the Daml privacy model is explicitly “need to know”. A party is guaranteed to see all data it needs to see and is guaranteed to see precisely and only that data it has a provable need to see. Moreover if a party is informed of a contract there is a persistent and verifiable provenance of that disclosure that includes a proof that was this valid and necessary. Needless to say this is an incredibly powerful privacy model to have available built in.
Finally the language itself is as you say, high-level; however, this high-level language is built on top of the most powerful general purpose system-programming language available to industry today. Granted that this language has had its access to the system removed, but what remains is still a language more powerful and better equipped to scale to programming in the large than anything else out there.
After 5.5yrs you can well imagine I have a small list of minor improvements I would like to see, but surprisingly they are all relatively minor. I have worked on both very small and very large projects with Daml. Out of the 15 or so different languages across ~6 paradigms that I have used professionally over my career, Daml easily remains my preferred programming language for any form of business logic.
Thanks @VictorShneer and @Andrae for the insights! And I agree that the built in privacy features are a great component.
I was also wondering what have been your experiences with running a system in production. And by this I mean is it common to just run a single participant node system or is a multi-participant node more common. My current understanding is that the more participant nodes, the lower potential throughput and more potential issues if nodes or parties are not configured correctly. And in your experience, what is normally the backend - like are the majority of projects spinning up with a blockchain node or more traditional databases?