Implementing Secure and Private Smart Contracts with Daml on the Canton Blockchain

Table of Links

Abstract and I. Introduction

II. Preliminaries

III. Proposed Design: IBis

IV. Detailed Construction

V. Implementation on DAML

VI. Evaluation

VII. Conclusion and References

V. IMPLEMENTATION ON DAML

A. Blockchain Platform

We implemented the proof of concept framework using Daml (Digital Asset Modeling Language) [27] atop the Canton blockchain ledger protocol [28]. We used Daml version 2.8.3 with the corresponding Daml ledger model and Canton protocol.

The rationale for utilizing Daml in implementing our framework is twofold.

First, in Daml, a smart contract codifies the terms of the agreement between parties, including the rights and obligations of each party. A Daml contract template describes the data schema of the contract and rules for manipulating the data. In our implementation, these contract templates align closely with the data models outlined in Sec.IV-A.

Second, the Daml ledger model uses smart contracts as privacy-enabled data containers, enforcing data access controls as specified in the contract. The access control permissions of a party/user are explicitly stated in contract templates by assigning the party one of the following predefined roles:

• signatory: A party whose authority is required to create the contract or archive it. Every contract must have at least one signatory. Signatories are guaranteed to see actions on that contract.

• observer: A party that is guaranteed to see actions that create and archive the contract.

• controller: A party that can exercise a particular choice (i.e., invoke a function) on the contract.

• choice observer: A party that is guaranteed to see a particular choice being exercised on the contract.

While similar approaches can be implemented with other smart contract languages, the contract-level access control typically does not extend to the ledger itself. For example, although chaincodes in Hyperledger Fabric can enforce access control, all channel members still synchronize the entire ledger [50]. In contrast, the Canton blockchain ledger protocol extends the Daml ledger model to the ledger level, where a blockchain node synchronizes only the contract data relevant to its party permissions. Therefore, by adopting Daml and Canton, we facilitate the integration of many AOs and COs onto the same IBIS platform, while ensuring that commercially sensitive license agreements between an AO and COs, dataset metadata, and model metadata remain concealed from other parties, even at the ledger level. Table III lists the resources in IBIS along with their authorizations.

B. Smart Contract Implementation

Listing 1 illustrates the license smart contract template, constructed based on the data schema in Table I. The copyrightOwner and modelOwner are designated as signatories of the template (Line 10). This reflects the bilateral nature of the license agreement. Consequently, authorization from both parties is required to create a license contract. Subsequently, once the contract is created, both parties can access it, while no other party has access to this contract either onchain or on-ledger. Hence, this implementation closely aligns with the access control requirements specified in Table III. In addition, the identifier attribute of each license serves as the primary key (specified by Line 12-13), which can facilitate efficient queries during the graph traversal.

Similarly, dataset and model metadata are represented in smart contract templates according to their corresponding data models, except that only the modelOwner is designated as the signatory of the DatasetMeta and ModelMeta contracts. This setup enforces two access control rules:

• Only modelOwner has the authority to create and access these contracts.

• modelOwner is restricted to accessing DatasetMeta or ModelMeta contracts created by themselves.

Full implementation details are open sourced[3]. Fig.7 illustrates the class diagram of IBIS design.

C. Multi-party Signing

The generation of a bilaterally signed license contract adheres to Daml’s Propose and Accept Pattern[4]. In this pattern, one party initiates a proposal contract, which the counterparty can either accept or reject. The acceptance (or rejection) is implemented as a contract choice[5], allowing the counterparty to exercise their decision. Upon exercising the accept choice, a result contract is generated, symbolizing the agreement between the two parties.

In our implementation, the proposal contract takes the form of the draft license agreement, and it is depicted in Listing 2. LicenseAgreement shares the same data schema as License (see Listing 1), with the copyrightOwner designated as the signatory. This ensure only the copyrightOwner has the authority to create a contract. Alternatively, modelOwner, as the controller of the Accept choice in Line 16, has the authority to exercise the choice, resulting in the creation of a License contract. This setup ensures that only the modelOwner specified in a LicenseAgreement contract has the authority to exercise the Accept choice of that contract.

[3] Open released at https://github.com/yilin-sai/ai-copyright-framework.

[4] https://docs.daml.com/daml/patterns/initaccept.html# the-propose-and-accept-pattern.

[5] https://docs.daml.com/daml/intro/4 Transformations.html# choices-as-methods