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. Authors:
(1) Yilin Sai, CSIRO Data61 and The University of New South Wales, Sydney, Australia;
(2) Qin Wang, CSIRO Data61 and The University of New South Wales, Sydney, Australia;
(3) Guangsheng Yu, CSIRO Data61;
(4) H.M.N. Dilum Bandara, CSIRO Data61 and The University of New South Wales, Sydney, Australia;
(5) Shiping Chen, CSIRO Data61 and The University of New South Wales, Sydney, Australia. This paper is available on arxiv under CC BY 4.0 DEED license. [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 Table of Links Abstract and I. Introduction Abstract and I. Introduction II. Preliminaries II. Preliminaries III. Proposed Design: IBis III. Proposed Design: IBis IV. Detailed Construction IV. Detailed Construction V. Implementation on DAML V. Implementation on DAML VI. Evaluation VI. Evaluation VII. Conclusion and References 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. contract template 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. signatory • observer : A party that is guaranteed to see actions that create and archive the contract. observer • controller : A party that can exercise a particular choice (i.e., invoke a function) on the contract. controller • choice observer: A party that is guaranteed to see a particular choice being exercised on the contract. • choice observer: 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. Propose and Accept Pattern 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. Authors: (1) Yilin Sai, CSIRO Data61 and The University of New South Wales, Sydney, Australia; (2) Qin Wang, CSIRO Data61 and The University of New South Wales, Sydney, Australia; (3) Guangsheng Yu, CSIRO Data61; (4) H.M.N. Dilum Bandara, CSIRO Data61 and The University of New South Wales, Sydney, Australia; (5) Shiping Chen, CSIRO Data61 and The University of New South Wales, Sydney, Australia. Authors: Authors: (1) Yilin Sai, CSIRO Data61 and The University of New South Wales, Sydney, Australia; (2) Qin Wang, CSIRO Data61 and The University of New South Wales, Sydney, Australia; (3) Guangsheng Yu, CSIRO Data61; (4) H.M.N. Dilum Bandara, CSIRO Data61 and The University of New South Wales, Sydney, Australia; (5) Shiping Chen, CSIRO Data61 and The University of New South Wales, Sydney, Australia. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv available on arxiv [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

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

"AI algorithms can analyze large volumes of scientific publications & extract valuable information"

Win Big in the #decentralize-ai Writing Contest by ICP and HackerNoon

Why Is Decentralized AI a Key to a More Secure Digital World?

IBIS: A Blockchain Framework for Ethical AI Model Training and Copyright Compliance

How Blockchain Enhances Copyright Protection in AI Model Workflows

Integrating Blockchain in AI Model Training: License Management and Metadata Tracking

"AI algorithms can analyze large volumes of scientific publications & extract valuable information"

Win Big in the #decentralize-ai Writing Contest by ICP and HackerNoon

Why Is Decentralized AI a Key to a More Secure Digital World?

IBIS: A Blockchain Framework for Ethical AI Model Training and Copyright Compliance

How Blockchain Enhances Copyright Protection in AI Model Workflows

Integrating Blockchain in AI Model Training: License Management and Metadata Tracking

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps