How does it make sense to say that a system is both a blockchain and not a blockchain at the same time? Is enterprise blockchain (also called DLT) censorship resistant? What are the main challenges of implementing enterprise blockchain in real life, and how can Daml (Digital Asset’s open source smart contract language and platform) help tackle the challenges? We’ll look at those questions and others in this post.

Why is the meaning of “blockchain” ambiguous?

You’ve likely noticed that the meaning of the word “blockchain” depends on the context. Why do different blockchain mental models exist, and how can we clarify the concept? The main reason is that there are two kinds of transfers working in the economy, which led to different generalizations of the original concept, embodied by Bitcoin. 

On the demand side of the economy, the consumer trends are shaped by a phenomenon called “expectation transfer.” As the trend research company TrendWatching puts it: Innovations, on top of serving basic needs in a new way in a specific market, also set new customer expectations, which spread across markets, industries, and demographics.

The creator(s) of Bitcoin wanted to create (as the Bitcoin White Paper puts it) “a peer-to-peer electronic cash system which allows online payments to be sent directly from one party to another without going through a financial institution.” One meaning of “blockchain” is the generalization of this expectation beyond the financial sector. It can be summed up by the following phrase: “A multi-party transaction system with real-time reconciliation and strong trust properties.”

As you can see, this formulation says nothing about the technical implementation and doesn’t refer to any specific “blocks” or a “chain.” There is another meaning of “blockchain” though, which does refer to both concepts. It comes from another transfer in the economy, working from the supply side: Technology transfer, notably the transfer of Bitcoin’s working mechanism to non-public transaction networks and cybersecurity. In this sense, “blockchain” means a verifiable data structure consisting of a chain of data blocks, hashed together so that the hash of the topmost block identifies the whole chain. Bitcoin, and some of its successors additionally implement the proof-of-work mechanism (like the original version of Ethereum), while some others don’t (like Hyperledger Fabric) (more on the reason for this difference in the next section). 

The double mental model outlined above justifies statements like our original apparent contradiction: “Both a blockchain and not a blockchain” (see, Corda). Or, like saying that Digital Asset’s Canton platform performs global synchronization beyond blockchain. Canton can perform synchronization between blockchain (and database) domains, and it is “blockchain” in the “multi-party transaction system” sense, but its technical implementation is based on a two-phase commit protocol, instead of a chain of data blocks or proof-of-work.

The main division: Censorship resistance

In the context of this post, let’s focus on the “multi-party transaction system” meaning of blockchain, without implying any “blocks” or a “chain” in the technical implementation. Let’s take a closer look at what we mean by “enterprise blockchain.”

The main division within the blockchain world is the requirement of “censorship resistance.” On one hand, Bitcoin, Etherem, and other public networks are censorship-resistant, meaning nobody can stop a transfer from being executed if the sender knows the recipient’s address and has enough funds. (The price tag for censorship resistance, implemented by proof-of-work, is high, in terms of energy consumption and low throughput). On the other hand, a blockchain serving a business consortium, doesn’t need — and indeed doesn’t want — to be censorship-resistant, because it works embedded into a legal and contractual context. 

This distinction helps us formulate the concept of enterprise blockchain: It refers to multi-party transaction systems with real-time reconciliation and strong trust properties, without the requirement of censorship resistance. 

Enterprise blockchain in the real world

The advantages of creating enterprise blockchain applications are numerous. Some examples include how Digital Asset takes part in the joint efforts by financial institutions for implementing central bank digital currency (CBDC), and for tackling inefficiencies in the syndicated loans market. The Daml platform helps clients solve problems caused by issues around dispersed and inaccessible data, complex operations, and unclear workflows that span multiple types of organizations.

Besides the advantages, implementing an enterprise blockchain system in the context of a real-world enterprise also has its own challenges. Some of these challenges, as seen in recent Daml-based projects, include:

Legacy integration. A Daml system usually doesn’t exist in a vacuum, but rather needs to communicate with existing systems. Daml helps in two ways: It offers 1) different API options for communicating with client systems, including an HTTP JSON API for REST and streaming communication; Java bindings with generated code implementing the Java equivalents of Daml types; a React library for building UIs; and the ledger API which can be used with any gRPC-supported language; and 2) different options for the underlying storage, including the Daml Hub cloud platform, the Canton synchronization platform, and integrations with various blockchains and databases.

IAM integration. A company most likely has an identification and access management system in place. Daml doesn’t interfere with that: It doesn’t care about authentication, just authorization. It requires signed access tokens, encoding the ledger ids on behalf of which real-world actors want to read from and write to the ledger, and supports JWKS for retrieving the signer’s certificates. 

Fast retrieval of the active contract set. Daml is a kind of DLT, where the “L” stands for “ledger” — not in the accounting sense of the word, but rather meaning a list of validated and committed transactions (which would be called a “journal” in accounting). We also say that Daml is an “event sourcing system,” meaning that the active contract set needs to be computed from the list of committed transactions. In order to make the query fast, the JSON API of Daml implements the Query Store feature, which caches the active contract set.

The “right to be forgotten” privacy requirement, required by GDPR, CCPA, and others. The Daml solution here is participant pruning, or the removal of archived contracts from the ledger (after transferring them into cold storage, if necessary, for example for reporting). This is possible because Daml doesn’t rely on archived contracts for validating transactions. The pruning feature is available if the underlying storage supports it.

If you’d like to learn more about utilizing the advantages of enterprise blockchain, check out our Daml learning resources.

About the author

György Balázsi is a certified Daml developer and an active community member on the Daml Forum. He is a holder of a community recognition reward and is a digital strategist and consultant working in the intersection of business and IT.

Follow György on Daml Forum and Twitter.