by Levente Barczy
July 29, 2020
As smart contracts become increasingly mainstream, we wanted to discuss how Python and Daml can be used together to develop multi-party and private, yet distributed applications of the future.
We will cover briefly the background of both languages, put them in the context of the smart contracts driven distributed ledger (DLT) paradigm, and then present symbiotic usage scenarios. Despite the title, this is not a Python vs Daml post. But it shows where both languages specifically shine and how you can use them to create enterprise applications.
What are smart contracts?
Smart contracts are digitally executable agreements that encapsulate, express, and respect the privacy, rights, and obligations of their stakeholders. They can be composed into business workflows, allowing all participating parties a shared, verifiable version of the truth. The term was originally coined by Nick Szabo in 1997. Daml is such a language, which can run on distributed ledgers and databases alike. It is in current use by both leading enterprises and startups to create complete, end-to-end applications that bridge data- and process-silos.
A background of Python and Daml
Python is an interpreted, object-oriented, high-level programming language suited for Rapid Application Development. We can consider Python a general purpose language with a wide variety of libraries and modules to accomplish a myriad of tasks. Most recently, Python has become popular for AI and machine learning due to the abundance of ready-made modules that make a data scientist's job easier.
Daml on the other hand is not a general purpose language. Rather, it is a strongly typed language purpose-built for smart contracts and end-to-end business workflows. Daml includes native constructs to express authorization and disclosure. Thus every entity in the workflow is guaranteed to see only data that they’re authorized to see, while at the same time being assured that their view of the world is consistent and coherent with everybody else’s.
This segregation of data is enforced at the level of the persistence layer. In cases of relatively low trust, such as between potentially competing enterprises with no trusted intermediary, when combined with a ledger that supports privacy Daml will enforce privacy via its ledger model. On the other hand, when the trust is relatively high, such as between different desks or departments within an enterprise which are supported by a single trusted operator, then a database can sufficiently enforce differentiated disclosure.
Where do Daml and Python fit in?
A few weeks ago, Harvey West from Everis published a blog post evaluating Daml and Kotlin. We’ll use that as base and build on it as we review Python and Daml. You may also want to review this comprehensive blog post by Manish Tomer comparing Daml and Solidity, both smart contract languages.
Most enterprise-grade business applications use a 3-tier architecture to support an end-to-end business process. We observe that, typically:
- A business process that spans multiple business units means that no one unit completely knows the state of the business flow. This requires reconciliation between each business unit. (aka “data silos”.)
- Such a business process is governed jointly by multiple applications, and as such, there is not one single codified expression of the entire business process; really, it is just an emergent behavior of the system. At best, the whole process is described in supplementary documents in prose, of unknown fidelity to the actual process. (aka the “business process management problem”).
As a smart contracts language, Daml is well suited to solving these two problems by 1. Providing a coherent state for the workflow that respects the privacy requirements of the different business units, and 2. Explicitly defining the business process by precisely enumerating all of the legal state-changes that make up the workflow.
Python, on the other hand, is known to be good at expressing business and computational logic from the point of view of a single actor or process, making it a perfect compliment to a Daml ledger.
In other words, write the rules, constraints, protocols, rights, and obligations of the business process in Daml, and use Python to write applications that make decisions and take actions within that workflow.
Can Python be used to write smart contracts?
I.e. why not use Python in place of smart contracts?
Firstly, we must concede that since Python is a general-purpose language with a comprehensive set of libraries, in principle it could do all of the things that a smart-contract language can do. But is it really suited to the job?
Let’s take an example of a mortgage Contract between a Borrower, an Issuer, and a Lender. In this simplified example, the Issuer is responsible for verifying the borrower and his creditworthiness and underwriting the contract; the borrower received the money and is responsible for paying it back; and the lender has the right to collect:
This short snippet of Daml accomplishes all of the following functions:
- Require the explicit consent of the borrower and the issuer;
- Restrict visibility to only the three parties listed on the deal;
- Grant the right to the lender (and only the lender!) to collect; and allows the borrower to make a payment
Additionally, it can do all of this, as written, on a number of blockchains and databases, while serving an API to applications.
As we conceded above, yes, it would be possible to write a Python module that accomplished all this (save, perhaps, for platform independence). But let us speculate on what such a Python module would look like. Its first notable feature would be that it would need to duck-tape together multiple libraries and paradigms, to
- Manage the persistence layer, e.g. using SQL or a blockchain protocol
- Authorize and identify parties
- Ensure and prove that consent was granted by signatories
- Ensure that only authorized parties can change the state
- Ensure that mutually contradictory attempts to change the state fail elegantly (e.g. prevent double-spends)
- Serve an API to an application.
...in other words, it would take a lot of lines and would likely work only on a single persistence layer.
A second consequence of this is that the developer would spend the majority of his time not writing business logic but rather writing non-differentiating systems code.
What’s Python good for, then?
Daml is good at defining and enforcing the rules of a business process, as above. But it was deliberately designed to not be an actor in such a process. For example, in the snippet above, Daml does not describe how a mortgage should be created, or when, or why, only that it needs to be signed by the parties specified. And it certainly does not specify what the user interface for entering a mortgage is, nor the integration with e.g. the underwriting system.
Luckily, the Daml runtime serves an API based on the business logic defined via Daml (called the “Ledger API”). In the example above, the Ledger API will:
- Notify the lender, borrower, and issuer (and only them!) whenever a Mortgage Contract is created;
- Notify these stakeholders in case the contract is archived;
- Allow the lender (and only the lender!) the ability to collect.
Python is an ideal language to use this API, and to connect to other upstream and downstream systems that offer their own connectors. Python features a wide range of transformation and serialization tools that could be used to translate into and out of Daml contracts, which makes Python very appealing for writing integrations to other systems within an enterprise.
For example, the following automation will:
- Listen for the creation of contracts of type ’DamlTemplateName’ to which the bot is a stakeholder;
- Issue a REST request;
- And exercise a choice called ‘DamlContractChoice’ on that contract based on the REST response.
So Daml and Python work hand in hand to execute a complete business process while ensuring that the complete state of the business process is in a single smart contract store.
In addition, event driven architectures as outlined in this blog by Eric Saraniecki are well supported by Python for Daml.
Some important properties of Daml not addressed by Python
The communities behind Daml and Python support different objectives that are relevant to the paradigm they are intended for.
The Daml community focuses on ensuring that Daml can run without changes across any persistence layer, including distributed ledgers or databases. That’s called Daml portability, and ensures that developers looking to write smart contracts need not worry about which ledger or database their distributed applications will use to create a single version of the truth across parties. Portability is enabled by the Daml runtime that abstracts the underlying data storage layer from the smart contracts layer.
The Daml community also focuses on ensuring that Daml applications can work across ledgers. So an application deployed on Hyperledger Fabric may transact atomically with a Daml application that is hosted on a database such as PostgreSQL. This is called Daml interoperability.
In contrast, the Python community focuses on making sure Python provides a comprehensive array of libraries that allow it to be used for almost any application purpose from data science to desktop GUIs.
Conclusion
As should hopefully be evident now, Python and Daml complement each other well.
Daml is a language for writing the smart contract layer, while Python is well suited for applications which need to enact changes of state on the ledger, including integrations or analytics. Daml provides important built-in constructs for privacy, rights and obligations, ledger portability, and also ledger interoperability, all of which ensure that those changes of state are coherent and safe. Daml has also a new learn section where you can begin to code online:
