Unbounded tech stacks with Daml

When you create an application you can be reasonably assured that the program starts and stops at its runtime with fairly flexible interfaces for data persistence such as relational SQL, document stores, key value stores, time series dbs, etc. So it comes as quite a shock to people when they write smart contracts and find that they’re locked into a single language, in a single runtime, with a single database design. 

If composing an Ethereum smart contract you’re now stuck with Solidity and data from within the blockchain itself without any access to data from the outside world unless you choose to permanently store it within the blockchain. If writing for other platforms you may get locked into Java or another language of choice with libraries and fixtures specific to the platform. Still other stacks like Tendermint allow for any language/runtime, but restrict your ledger/database to a single application.

Each of these cases limit the portability of your application and keep you locked in to specific ledgers, databases, architectures, and backends. In early development phases where flexibility is needed you may find yourself rewriting the same application on several different platforms just to have a rough comparison between them.

Image courtesy of Andrey Matveev at pexels.com

If we want to solve these issues we need to have a language that can be used on any backend that we choose and where the concepts used to enforce permissions and access to data are consistent across platforms. Unfortunately this ideal is a bit unrealistic, every ledger has a different way of dealing with these confounding variables and no two ledgers are alike, if they were we wouldn’t care to choose between them.

However there is a better way, and it is the one Daml employs (surprising for a blog about Daml, I know). But in all seriousness the Daml approach does work and it’s somewhat akin to the Tendermint approach in that the ledger is used for data persistence. However it differs from Tendermint in that the runtime does not need to talk to a ledger in a specific way, nor does it restrict the ledger to a single application.

In Daml the runtime runs entirely outside of the ledger and when it needs to talk to a specific ledger for data persistence it does so through an adapter that allows it to translate its desired state to commands that the underlying ledger can understand. The programmer does not need to worry about how Fabric, Sawtooth, Corda, or any other ledger stores and retrieves its data, it all just happens through a common interface of Daml code and JSON APIs.

Ultimately this gives us a variety of benefits:

1. Developing an MVP and designing our application’s workflow is easier. Essentially business logic is defined in a single place, the Daml code, rather than being distributed between database logic and the UI. This may not seem like a portability gain, but it’s an indirect feature as without it we could not have portable code
2. We avoid vendor lock-in, and with it have unparalleled flexibility in the design and architecture of our programs
3. Portable code is composable code, distributed applications can more easily interact with each other
4. Interchangeable UIs, the complete decoupling of frontend and backend logic allow for more independent development of interfaces and faster iteration. Improving your UI has zero risk to your business logic

If you want to know more about Daml checkout our documentation, or come and join our lively forum. This article is the third of many in an ongoing series of distributed ledger concepts, if you enjoyed it then check out the first post where we breakdown the practical implications of centralized, distributed, and decentralized systems, and the second where we discuss the importance and improvement of smart contracts.