Distributed Ledger Technology (DLT) in the enterprise space has seen a number of new players in recent years, providing greater variety for businesses to select an appropriate technology for their needs. Often, these choices are not made on the basis of the merits of the technology alone, but rather on existing business relationships and, sometimes, hype.
The most well-known DLT technologies available for enterprise solutions today include Hyperledger Besu (an Ethereum client, previously Pantheon), R3’s Corda, Digital Asset’s DAML and Hyperledger Fabric. In each part of the Block8 Rates series, we will attempt to provide a direct comparison between two players in the scene against several key metrics.
In particular, we’ll be taking a look at writing smart contracts in R3’s Corda compared to Digital Asset’s DAML.
Other parts in this series:
What can it do? This is likely the most important question any software Tech Lead may wish to know, as you’ll want the language you choose to be able to model exactly what you want, no matter how complex, with a minimum of frustrating boilerplate or workarounds, but with an appropriate level of visibility of what’s going on under the hood.
Corda has the ability to model essentially any state (provided you can write custom serializers for more complex states). Corda contracts are also Turing-complete. DAML also has the ability to model most states, at least in the financial domain, for which it was created. We did not find any state we were not able to model. Some desired state mutations will require intermediary states, especially when collecting signatures. There is also a false presumption that DAML is not Turing-complete, due to a 2016 DAML blog post. Earlier versions of DAML were not turing complete, but DAML has since added general recursion and more. The developers have confirmed that DAML is indeed turing-complete, the only issues you may face are at the intersection of very complex privacy and modelling requirements.
Corda comes with the ability to add attachments in transactions. Attachments are .zip or .jar files referenced from transaction by hash, but not included in the transaction itself. This may be useful for some applications, however, it was not something we explored. This is not something which DAML currently supports.
Corda also has support for Oracles, which are network services that, upon request, provide commands that encapsulate a specific fact (e.g. an exchange rate at a given point in time) and list the oracle as a required signer. In DAML, you can also add information from oracles by modifying the data structure slightly and adding a method that is only executable by the oracle which would inject data into the structure. Both participants require the trusted Oracle to be a participant in the ledger by hosting a node or having a trusted middleman.
In Corda, verifying uniqueness of a transaction is done by a notary. Every transaction requires a notary to attest that, for a given transaction, it has not already signed other transactions that consumes any of the proposed transaction’s input states. This is done to prevent double-spends. The notary service can use a pluggable consensus algorithm such as RAFT or BFT depending on business requirements. DAML’s consensus is based on the ledger which it is used with. DAML’s privacy guarantees are only as strong as the ledger that DAML runs on. If the underlying ledger supports privacy then DAML supports it, if it does not then DAML does not. Privacy on the Corda Ledger has some issues, in particular, if you interact with a particular state, your machine gets access to the entire history of the state. R3, the creators of Corda, have explored solutions including obfuscation, truncating the history of the state and more recently using Intel SGX enclaves to make areas of the machine’s memory inaccessible to the owner of the machine.
Corda has built-in automation, whereby if all nodes are online and a transaction satisfies all validation logic from all parties involved, it should complete without further input required from the transaction initiator. This is because the acceptance criteria for any user is in the format of response flows (essentially codified acceptance criteria), whereby if the codified acceptance criteria for a user is satisfied, the user would not require any input. This is very different to DAML, where there is no built-in automation. This is because every single method execution requires external input to execute. Introducing automation requires external automation through libraries or the like. This is not necessarily a bad thing as many B2C applications may prefer no automation, especially because users generally prefer that any form of transaction be initiated by them. It also means that users do not need to write their own acceptance criteria for automation. Instead, they can just execute simple methods such as accept or decline. This is possible in Corda by using intermediary states, but in that case you would be fighting the purpose of the language by trying to remove automation. The DAML team is working on automation with the introduction of features such as DAML Triggers, which are basically database triggers written in DAML, which can bridge the gap for use-cases which require minimal user input. To summarise, Corda has built-in automation, whereas DAML has added support for automation for applications which require it.
Corda uses proprietary RPC to interact with the ledger and DAML uses gRPC with Node.js/Java/JSON bindings supported. gRPC is an open standard, as opposed to the proprietary RPC used by Corda which provides only a JVM client. Both of these allow you to expose an API which can be called to execute commands and workflows. However, open standards have better longevity and flexibility compared to proprietary protocols.
Both DAML and Corda have been developed with support for a variety of use cases in mind. For some use cases, which are automation centric, Corda smart contracts may prove more suitable due to its inherent automation, as opposed to DAML’s optional automation, requiring automation code be written separately. Not every use case benefits from automation, in which case DAML may prove a better option with its better integration with open standards. However, the choice is dependent on the nuances of each business’s use case and trust context.
About the Authors:
Rao Zoraiz Mahmood
Software Engineer, Block8
Zoraiz Mahmood is a Software Engineer at Block8, working on emerging technology.
His current research and development interest focuses on protocol development for distributed systems (blockchain), and is currently writing a paper on the Performance Comparison of Blockchain Data Storage Models.
Zoraiz regularly creates blockchain technical and related content, having written multiple technical articles, hosted podcasts and produced YouTube videos.
When not generating value, Zoraiz can be found out and about exploring the Australian landscape.
Samuel Brooks is an expert in connecting next-gen technology with current-gen business problems, with particular specialisation in the development of distributed ledger systems, having designed many DLT-based solutions and authored and contributed to multiple public submissions from both industry and government.
He is also an active member of the Australian blockchain community, including regularly speaking at technology conferences, meetups and podcasts, and contributing to industry and International Standards committees. Samuel holds a degree in Electrical Engineering from UNSW and has been working hands-on with blockchains since 2014.