DEV Community: Daml

Creating blockchain NFT-based customer experiences with Daml

Daml — Thu, 21 Apr 2022 08:10:09 +0000

The post was originally published on Daml Blog.

Blockchain non-fungible tokens (NFTs) have come a long way from their beginnings as proof-of-ownership of digital assets on the blockchain. As more and more creative digital assets are minted as NFTs on the blockchain using smart contracts, we have entered the next phase of evolution.

Now, the question many brands are asking is, How can we use blockchain NFTs to deliver differentiated experiences to customers who own our NFTs? This emerging trend of blockchain NFT experiences was also covered in a previous post: Top-five Enterprise Blockchain Priorities for 2022.

In this post, we will attempt to define an NFT blockchain platform, and discuss how to deliver blockchain NFT-based experiences. To illustrate this, we will be looking at Daml, a portable smart contracts language that allows for interoperability between public and enterprise blockchains, as well as traditional databases—whether on-cloud or on-premise.

Options for creating blockchain NFT experiences

Creating experiences based on NFTs can be accomplished in two ways:

By creating an NFT on a blockchain platform so that people can own it, and then by building a traditional software ecosystem around the NFT that checks ownership and provides various NFT experiences and privileges; or,

By making NFTs smarter, so that we can embed an extensible business logic directly into the NFT.

Using Daml, we’ll demonstrate how to create NFT-based experiences using the second option introduced above. The key benefit of option two here is that the entire process becomes much more transparent and accountable, as all of the actions can be tracked on the blockchain as smart contracts. We can still use the traditional format featuring a URL to a digital image along with transfer rights. Daml also allows the same blockchain NFT to reside on a permissioned enterprise blockchain, thus allowing brands tremendous flexibility in how they use the NFT to provide new experiences with this technology.

If you or your developer team haven’t yet installed Daml, you can install it here. Once installed, simply navigate to where you’d like to create the project, and create a new Daml smart contract project using the Daml assistant.

Creating our blockchain NFT-based experience

For our purposes, we will use the example of a rock band issuing an NFT that also serves as a ticket to their concert. We’ll then add additional programming (or rights and obligations) to the blockchain NFT so that new experiences can be created using the NFT in a transparent manner—directly on the blockchain.

In the new project we’ve created, we remove everything from main.daml except the line declaring the main modulem, and simply type in the following:

template RockBandNFT
  with
    uniqueNFTId: Text
    imageUrl: Text
    band    : Party
    fan     : Party
    -- benefits  : Benefits
    issuedDate: Date
  where
    signatory band, fan

This signifies a basic NFT contract. The Party datatype is what defines a unique party on the blockchain. The signatory keyword indicates that this token cannot be created without the consent of both the rock band and the fan. This is a unique advantage of Daml’s rights and obligations guarantee because it ensures that a token cannot be created without each of the signatories explicitly approving the transaction. These checks and balances are built into the platform, so developers don’t have to code any additional business logic. Since this smart contract has two signatories, it must be created only after approval from both parties. See this video on how to use this powerful feature of Daml.

Now that we have the core blockchain NFT or smart contract on the blockchain, we can start adding some rights and obligations to it. In our case, we’ll offer the fans an individually signed t-shirt (also an NFT) if they attend the next concert.

Now, let’s have the band create a new concert using the rights we have coded for them on the blockchain NFT. For that, Daml allows us to create a choice (a right) on the NFT smart contract. Here’s how that looks:

controller band can
      CreateConcert: ContractId Concert
        with
          concertDate: Date
          concertName: Text
        do create Concert with ..

Note that only the band can create a concert—enforced here by the controller keyword. So if any party other than the band tries to create a contract, the execution will fail. This is another example of the Daml rights and obligations model available out of the box to developers.

The new concert looks like the following (as you can see, it also provides the customer a right to buy a ticket):

template Concert
  with
    concertDate: Date
    concertName: Text
    fan: Party
    band: Party
  where
    signatory band

    controller fan can
      BuyConcertPass: ContractId ConcertPass
        with
          purchaseDate: Date
          amount: Decimal
        do
          create ConcertPass with ..

As before, in our example, only the customer can buy a ticket—again enforced by the controller keyword in Daml. And when they do, they receive a concert pass. Since the concert pass is also a smart contract, once customers have a concert pass, then the band—also a controller on that smart contract—can now issue them a blockchain NFT for a T-shirt. The NFT for the T-shirt is, of course, also a smart contract allowing for future extensibility.

template ConcertPass
  with
    concertDate: Date
    concertName: Text
    purchaseDate: Date
    amount: Decimal
    fan: Party
    band: Party
  where
    signatory fan
    observer band  

    controller band can
      IssueTShirtNFT: ContractId ConcertTShirtNFT
        with
          digitalURL: Text
        do
          create ConcertTShirtNFT with ..

template ConcertTShirtNFT
  with
    concertDate: Date
    concertName: Text
    digitalURL: Text
    fan: Party
    band: Party
  where
    signatory band, fan

The t-shirt NFT takes the URL for the digital image.

So, now we have two NFTs on the blockchain—one to represent the ticket and one to represent the t-shirt. What we can do to build on the NFT experiences is limited only by our imagination. For example, this t-shirt NFT can be redeemed or further gifted.

Why Daml for blockchain NFT experiences?
As of the writing of this blog, multiple layer one blockchains such as Solana, Avalanche, and Cardon have surfaced in addition to Ethereum, indicating a maturing of this space. So, when we create blockchain NFTs, we should keep portability of our smart contracts in mind; you shouldn’t have to tackle additional, complex technical initiatives in addition to running a blockchain NFT customer experience program. Second, the future of the DeFi and blockchain space hinges on interoperability. Daml allows blockchain NFT smart contracts to interoperate with each other when deployed on multiple blockchains. This is a huge advantage. Finally, Daml also runs on databases, so you could create an intra-enterprise NFT without having to work with a blockchain layer, all while keeping your smart contracts interoperable with an external blockchain network.

Finally, as you see in the code above, Daml focuses entirely on the business logic. All the underlying plumbing and idiosyncrasies of the underlying ledger platform are abstracted away and hidden from the developers, making for extremely rapid business deployment and validation.

The power of blockchain NFTs is beginning to emerge as a key tool for customer experiences. As ownership gives way to the need for providing experiences, it will be important to make the technical plumbing transparent to both users and developers in the enterprise. Interoperability and the flexibility of deploying NFTs on multiple blockchains is emerging as a critical success factor. Take a look at this article on tokenization and this one on asset tokenization that explore how blockchain NFTs will connect the world.

Damlprovides an excellent foundation from which brands can build on what they need to do to grow their eminence: Creating the immersive, NFT-based customer experiences of the future.

Ethereum versus Daml, an analysis of Enterprise Blockchain

Daml — Mon, 11 Apr 2022 15:31:24 +0000

This post was originally created on Daml Blog by Shaul Kfir.

As developers identify the blockchain infrastructure and application development platform to support their applications, many community members seek to understand the differences between Daml and Ethereum. Both Daml and Ethereum are used as blockchain open source to create applications that solve industry-level problems; however, there are several differences between the two platforms with Ethereum being a public blockchain network and Daml on the other hand supporting permissioned multi-party projects.

When to use Ethereum over Daml

You need a public mainnet and do not need privacy - No public mainnet supports Daml, yet. So it makes sense to use Daml if you’re a company starting a network or joining an existing network, but not if you’re an independent developer who wants to deploy something to an existing ecosystem. You also benefit from the amount of innovation happening on public blockchain, which is inevitably faster due to more participation.
You need a trustless DAO - Daml does not support DAOs natively, yet. However, you can build them (though it is hard). Every contract in Daml has a set of owners (called “signatories” in Daml) who can upgrade the contract. An Ethereum DAO can never be changed, so it’s fully trustless once deployed (but it can also have bugs that you can’t fix).

When to use Daml over Ethereum:

*You need privacy for anything more than tokens *- Daml has privacy as a built-in concept. That means that every node in Daml sees a subset of the smart contracts on the network. ZKP may be able to do this in the future, but there are no current ZKP frameworks that get anywhere near Daml’s expressivity. As opposed to public blockchains, private institutions like banks, insurance companies, and many supply chain industries realized that the concept of collective data storage and management by a distributed ledger (DLT) could be very useful as an industry collaboration tool. Indeed, private networks can maintain transaction confidentiality of participants, terms, and data at scale.
You need flexibility - Daml runs on many different blockchains (Hyperledger Fabric, Besu, Corda, VMware, and Daml Hub). From the Smart Contract structure perspective, users of a Daml-based solution can engage with the solution provider either through traditional means (standard messaging protocols, for example) or by operating their own participant node in a DLT network.
You need interoperability - Unlike Ethereum, which usually displays a single, unified view of their network’s stored ledger, Daml implementations are multi-channels. Daml smart contracts can compose over multiple networks simultaneously, so your smart contract can call out to Daml smart contracts on other networks, and help increase data coordination across shared ledgers.
You are writing complex logic - Daml’s developer productivity is much higher than Solidity. You declare the high-level logic of your contract, and the compiler and runtime take care of the rest. There is less room to make security mistakes in Daml and much better tooling. Learn more about Daml ledger basics.

Next let's take a closer look at how privacy is guaranteed in Daml:

Daml Fine-grained privacy

Daml pushes the state-of-the-art in privacy preservation to a whole new level by also being able to determine the need to know at a very fine-grained level. With Daml, transactions can be broken up into sub-transactions, and these sub-transactions then selectively revealed to participants. Returning to our DvP example, when written in Daml, the DA Platform would reveal the entire transaction only to Alice and Bob. The bank and the CSD would be notified that the cash and shares, respectively, got transferred, and they can verify that the transfers were correct. But they would not learn anything about why the transfers happened. We can visualize this below, where each box shows to whom the part of the transaction is shown:

To conclude, both Daml and Ethereum are helpful blockchain open source to solve unique problems experienced by individuals and businesses. However, if your project demands a higher level of security, flexibility and interoperability, Daml offers the facility to maintain the privacy of an organization’s information and improves the effectiveness of deployment. It is unclear how the technology will pan out in the medium-to-long run, but it seems inevitable that the smart contracts technology will revolutionize the financial system, replace legacy systems, and make the industry more efficient.

Watch Daml Training Videos Here.

Parties and users in Daml 2.0

Daml — Mon, 11 Apr 2022 12:11:55 +0000

The post was originally published on Daml Blog.
By Moritz Kiefer.

With the introduction of Canton in Daml 2.0, party ids look and behave differently in both the local Sandbox during development and in production ledgers like the Daml Driver for PostgreSQL 2.0. This post provides an overview of the changes, as well as practical guidance on how to handle the new party in your own applications.

Parties in Daml 1.18
First, let's recap how parties worked in SDK 1.18 in Sandbox, the Daml Driver for PostgreSQL 1.0, and the VMware Blockchain. Parties can be fully user controlled via the party id hint, which can be specified on party allocation, e.g., via Daml Script’s allocatePartyWithHint. The call allocatePartyWithHint “Alice” (PartyIdHint “alice”) allocates a party with display name Alice and the party id alice. If a party with the id alice already exists, the allocation fails. This has a few implications:

You can allocate the same party id even if you restart your ledger.

Party ids are human-readable (provided you choose human-readable party id hints). For example, following the user Bob in create-daml-app is easy, because their party id is also Bob.

In addition, Sandbox (but not the Daml Driver for SQL 1.x) implicitly allocates parties. This means that if you create a contract with Bob as an observer or signatory, a party with id Bob will be created implicitly even if it has not been allocated before.

Parties in Daml 2.0
With the introduction of Canton in Daml 2.0 and a Canton-based Sandbox, parties have changed significantly. When you try to allocate a party with a given hint Alice, you will now get back a party id like Alice::1220f2fe29866fd6a0009ecc8a64ccdc09f1958bd0f801166baaee469d1251b2eb72. The prefix before the double colon corresponds to the hint specified on party allocation. If the hint is not specified, it defaults to party-${randomUUID}. The suffix is the fingerprint of the public key that can authorize topology transactions for this party. Keys are generated randomly, so the suffix will look different locally and every time you restart Sandbox, you will get a different party id. This has a few implications:

You can no longer allocate a party with a fixed party id. While you have some control over the prefix, we recommend not to rely on that (more on this below).

Party ids are no longer easily understandable by humans. This means you might want to display something else in user interfaces.

Discovering the party id of other users might get tricky. For example, to follow the user Bob, I cannot assume that their party id is Bob.

The role of party id hints and display names
Party id hints and display names which existed in SDK 1.18.0 are still available in SDK 2.0.0. We recommend against relying on display names for new applications, but if you are migrating your existing application, they function exactly as before.

Party id hints, on the other hand, still serve a purpose. While we recommend against parsing party ids and extracting the hint, for debugging and during development it can be helpful to see the party id hint at the beginning. Bear in mind that different parties can be allocated to different participants with the same party id hint. The full party ids will be different due to the suffix, but the party id hint would be the same.

The second use for party id hints is to avoid duplicated party allocation. Consider sending a party allocation request that fails due to a network error. The client now has no way of knowing whether the party has been allocated. Because a party allocation will be rejected if a party with the given hint already exists, the client can safely send the same request with the same hint, which will either allocate a party if the previous request failed or fail itself. Note that while this works for Canton, including Sandbox as well as the VMWare blockchain, it is not part of the ledger API specifications, so other ledgers might behave differently.

Authorization and user management
Daml 2.0 also introduced user management. User management allows you to create users on a participant that are associated with a primary party and a dynamic set of actAs and readAs claims. Crucially, the user id can be fully controlled when creating a user – unlike party ids – and are unique on a single participant. You can also use the user id in authorization tokens instead of party tokens that have specific parties in actAs and readAs fields. This means your IAM, which can sometimes be limited in configurability, only has to work with fixed user ids.

However, users are purely local to a given participant. You cannot refer to users or parties associated with a given user on another participant via their user id. You also need admin claims to interact with the user management endpoint for users other than your own. This means that while you can have a user id in place of the primary party of your own user, you cannot generally replace party ids with user ids.

Working with parties
So how do you handle these unwieldy party ids? The primary rule is to treat them as opaque identifiers. In particular, don’t parse them, don’t make assumptions about their format, and don’t try to turn arbitrary strings into party ids. Instead, the only way to get a new party id is as the result of a party allocation. Applications should never hardcode specific parties. Instead either accept them as inputs or read them from contract or choice arguments.

To illustrate this, we’ll go over the tools in the SDK and how this affects them.

Daml script
In Daml script, allocateParty returns the party id that has been allocated. This party can then be used later, for example, in command submissions. When your script should refer to parties that have been allocated outside of the current script, accept those parties as arguments and pass them in via --input-file. Similarly, if your script allocates parties and you want to refer to them outside of the script, either in a later script or somewhere else, you can store them via --output-file. You can also query the party management and user management endpoints and get access to parties that way. Keep in mind though, this requires admin rights on a participant and there are no uniqueness guarantees for display names. That usually makes querying party and user management endpoints usually only an option for development, and we recommend passing parties as arguments where possible instead.

Daml triggers
To start a trigger via the trigger service, you still have to supply the party ids for the actAs and readAs claims for your trigger. This could, for example, come from a party allocation in a Daml script that you wrote to a file via Daml Script’s --output-file. Within your trigger, you get access to those parties via getActAs and getReadAs. To refer to other parties, for example when creating a contract, reference them from an existing contract. If there is no contract, consider creating a special configuration template that lists the parties your trigger should interact with outside of your trigger, and query for that template in your trigger to get access to the parties.

Navigator
Navigator presents you with the list of user ids on the participant as login options. Once logged in, you will interact with the ledger as the primary party of that user. Any field that expects a party provides autocompletion, so if you know the prefix (by having chosen the hint), you don’t have to remember the suffix. In addition, party ids have been shortened in the Navigator UI so that not all of the id is shown. Clicking on a party identifier will copy the full identifier to the system clipboard, making it easier to use elsewhere.

Java bindings
When writing an application using the Java bindings, we recommend that you pass parties as arguments. This can either be CLI arguments or JVM properties as used in the quickstart-java example.

create-daml-app and UIs
Create-daml-app and UIs in general are a bit more complex. First, they often need to interact with an IAM during the login. Second, it is often important to have human-readable names in a UI — to go back to an earlier example, a user wants to follow Bob without typing a very long party id.

Logging in is going to depend on your specific IAM, but there are a few common patterns. In create-daml-app, you log in by typing your user id directly and then interacting with the primary party of that user. In an authorized setup, users might use their email address and a password, and as a result, the IAM will provide them with a token for their user id. The approach to discovering party ids corresponding to human-readable uses can also vary depending on privacy requirements and other constraints. Create-daml-app addresses this by writing alias contracts on the ledger with associate human-readable names with the party id. These alias contracts are shared with everyone via a public party.

Conclusion
While the new party ids might seem daunting at first, the Daml SDK tooling is well set up to handle it. Sandbox now behaves more like your production environment, making it easier to move your applications from development to production, while the introduction of user management makes integration with IAMs easier than before. If you still encounter issues handling these party ids, don’t hesitate to reach out to us on the Daml forum.

Privacy: Even stronger protections with Daml 2.0

Daml — Fri, 08 Apr 2022 09:52:28 +0000

This post was originally created on Daml Blog by Shaul Kfir.

Privacy has been a core tenet of Digital Asset and is the foundation of Daml, the leading platform for building and running multi-party applications. With the launch of Daml 2.0 — the next generation of our core technology with industry-leading privacy and interoperability — we’re taking privacy even further. Daml 2.0 includes Canton, our privacy-enabled distributed ledger that provides secure synchronization between multiple parties. With it, we extend privacy to new arenas to help companies realize the total value of more interconnected systems and markets through the Global Economic Network.

A brief look back

The early days of public blockchain focused on creating a platform that could synchronize a set of tasks without any central operator. Blockchains achieved this synchronization by giving everyone visibility into data and transactions, but without the ability to associate them to real-world identities. With applications such as Bitcoin, which ran on its own network, pseudonymity was arguably sufficient. However, as new blockchains emerged and operators sought to tackle more complex tasks, the challenge of privacy became more apparent. With the state of the ledger and the data found in one place, the ability for all parties to see it means that eventually, someone can figure out how to tie the data to its real-world equivalent. And indeed, there are companies built precisely to deanonymize and deobfuscate blockchain data. Herein lies the blockchain privacy problem: For everyone to stay synchronized, blockchain users broadcast all data for everyone to see.

Public blockchains are trying to solve this by layering solutions, such as retrofitting the chain to shard data into different levels of visibility and limiting who can access what. However, while necessary, this is insufficient — particularly in complex financial transactions or payments with multiple parties.

What makes Daml’s privacy different?

With Daml, we took an entirely different approach. From the start, we designed and built Daml to specify who precisely can see what data. Data privacy is at the core: Developers start from the data and create smart contracts that define what data is visible to what parties and how these parties can use the data. As a result, only a subset of people shares any piece of data on a need-to-know basis.

While data minimization resolves the privacy issue, it becomes more challenging to maintain accurate, synchronized data. A traditional blockchain remains accurate because everyone can see and validate all of the data. However, if different parties see only the transactions they are entitled to view, how do you validate and maintain an accurate ledger? Canton solves this using a ledger computation model that always ensures every party on the network can see and validate their subset of the global ledger, and only that. This ledger model keeps each party’s shard (slice) of the ledger consistent with the global ledger and independently verifiable, which, in turn, assures its accuracy.

Canton further improves on other blockchains in that it provides for privacy by way of visibility restrictions even within transactions, with multiple parties who require different levels of visibility. Daml is the only platform that offers an infrastructure for writing applications in which developers specify who is permissioned to see what data on a need-to-know basis. Furthermore, permissions apply across the board, making privacy intrinsic to the code rather than being added as another layer at the end. This specification of data entitlements embeds privacy throughout and radically simplifies application development. Developers can focus on business logic without having to rewrite the permissions constantly.

Here's a short video highlighting key features of Canton, produced by our Developer Advocate Steve Seow.

Privacy 2.0

Users of Daml commonly deploy Daml applications on other blockchains. Previous iterations of Daml ensured privacy in the application context, but different blockchains have different privacy properties. For example, while VMware blockchain can support Daml’s full privacy model, others like Hyperledger Fabric and Besu cannot. Daml 2.0 creates and assures the next level of privacy with Canton, which can be deployed on complimentary blockchains, enabling Daml’s complete sub-transaction privacy on all blockchains without trading off consistency or visibility into data lineage. This consistency in enforcing privacy controls opens the doors to more seamlessly interconnected networks and faster innovation, as with previous versions of Daml.

Canton creates the ability to ship data around to different nodes, sending only necessary data that is encrypted. The data sits across various ledger providers, allowing for data distribution while protecting and enforcing privacy rules regardless of those ledgers' individual privacy properties profiles. At a high level, here’s how it works:

The node submitting a transaction breaks up the transaction into views that contain only the information for the involved counter-participants and encrypts each view.

The submitter sends the encrypted views to the underlying ledger provider for ordering and data distribution.

Each participant to the transaction decrypts the received view, validates it, and confirms or rejects the transaction. Confirmations and rejections are collected by a central commit coordinator running on the underlying ledger provider.

Based on the confirmations and rejections, the commit coordinator informs all participants whether the transaction should be committed or rolled back. Finally, each participant updates the local ledger state to keep the ledger in sync.

With Canton, the entirety of the ledger state lives only with the participants, without any central ledger that holds all data. Putting the participants in the center is the key to creating the future of interconnected networks across ledger providers. With privacy managed at a sub-transaction level, only parties in the transaction can see all the steps. Since a node sees only its part of the transaction, it only needs to validate this part of the transaction. From a workflow composition perspective, conventional blockchains show the entire transaction to all participants, even though some nodes involved in the workflow only know how to make sense of certain subtransactions. Thus, the developer of the validation logic must be careful not to make assumptions about the transaction structure as a whole, as this would hinder the composition of small transactions into larger transactions.

With Daml 2.0 and Canton, since every node sees only a subset of the smart contracts on the ledger, each node sees only part of the transaction when a transaction changes the state of multiple smart contracts. For example, when Party A and Party B agree on a stock transfer, both parties can see all steps and validate the data. However, their banks and custodians can only see the movement of funds and movement of stock, respectively — not the entire transaction. As a result, all participants can independently validate their part of the transaction, keeping the ledger accurate and in sync while minimizing data access.

So, what has changed? With Daml 2.0 and Canton, this example can expand to virtually any size and shape. Daml and Canton work in tandem to keep it all glued together, regardless of how complicated or big workflows get, without sacrificing privacy or degrading the ledger's integrity. Beyond the clear value of safeguarding privacy, this offers other significant benefits:

Simplification for developers.
**When creating new applications, they can rely on what’s already there. As they define new workflows, they also establish who can see what for each part of that workflow with reduced visibility of the ledger provider.
New frontiers of extensibility.
**Canton allows multiple participant nodes to connect to form a business network and for those networks to connect to each other. Each network retains its own rules, but workflows can span the networks. This allows, for example, a payments network and healthcare network to connect for more efficient billing, claims verification and processing, and payment — saving time and money while reducing operational complexity and risk.
Unlimited network capacity.
**Since Canton was designed for data minimization and every node need only validate a subset of the global ledger, each application on the ledger can use separate resources without limiting the ability to compose these applications into larger workflows and applications. As a result, Canton can scale without limit as resources are added to the network.

Daml 2.0 with Canton provides the secure and private data foundation to power innovation. You decide who can access your application or plug into your network and set the inviolable roles, rules, and permissions. Those authorized institutions can build on top of your infrastructure with the guarantee that the ledger’s integrity will be uncompromised. Daml 2.0 with Canton lets you improve your workflows and processes while creating the conditions for increased connectivity.

You can download the Daml 2.0 SDK here.

What is enterprise blockchain, and why should you care?

Daml — Fri, 08 Apr 2022 09:44:04 +0000

The post was originally published on Daml Blog.
By György Balázsi.

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.