# Is Your AI Truly Yours? Leveraging Blockchain for Copyrights, Provenance,
and Lineage

Yilin Sai1,2, Qin Wang1,2, Guangsheng Yu1, H.M.N. Dilum Bandara1,2, Shiping
Chen1,2 1CSIRO Data61 $|$ 2The University of New South Wales, Sydney,
Australia

###### Abstract

As Artificial Intelligence (AI) integrates into diverse areas, particularly in
content generation, ensuring rightful ownership and ethical use becomes
paramount. AI service providers are expected to prioritize responsibly
sourcing training data and obtaining licenses from data owners. However,
existing studies primarily center on safeguarding static copyrights, which
simply treats metadata/datasets as non-fungible items with
transferable/trading capabilities, neglecting the dynamic nature of training
procedures that can shape an ongoing trajectory.

In this paper, we present IBis, a blockchain-based framework tailored for AI
model training workflows. IBis integrates on-chain registries for datasets,
licenses and models, alongside off-chain signing services to facilitate
collaboration among multiple participants. Our framework addresses concerns
regarding data and model provenance and copyright compliance. IBis enables
iterative model retraining and fine-tuning, and offers flexible license checks
and renewals. Further, IBis provides APIs designed for seamless integration
with existing contract management software, minimizing disruptions to
established model training processes. We implement IBis using Daml on the
Canton blockchain. Evaluation results showcase the feasibility and scalability
of IBis across varying numbers of users, datasets, models, and licenses.

###### Index Terms:

AI, Blockchain, License, Provenance, Trust

##  I Introduction

The proliferation of Large Language Models (LLMs) based applications [1, 2]
represents a significant milestone in the integration of Artificial
Intelligence (AI) technologies into various facets of daily life, spanning
from information retrieval [3, 4] to content generation [5, 6]. Concurrently,
AI service providers have made strides in commercializing their services.
Nevertheless, as LLMs and other AI models rely on extensive datasets
aggregated from diverse sources for training [7, 8], apprehensions have
emerged regarding the potential infringement of copyrights [9, 10, 11] during
the data acquirement and model training process. To uphold responsible and
ethical AI practices [12, 13], comply with regulations, and reduce legal
liabilities, AI service providers must actively collaborate with data owners,
including content creators and media industry stakeholders. Establishing
licensing agreements [14, 15] and obtaining consent before utilizing data for
AI model training is a key element of this collaboration [16]. Hence, there is
a growing need for new frameworks addressing data provenance, lineage, and
copyright compliance in the AI industry, tailored to its distinct needs and
workflows.

However, addressing the concerns of AI data provenance and copyright
compliance can be a nontrivial task, particularly when the entire training
process occurs locally or within a black-box cloud service [17], limiting
transparency for users. To bridge this gap, we harness the properties of
blockchain technology, which offers a tamper-proof and trustworthy environment
[18] to establish authenticity, provenance, and lineage [19, 20]. Owing to its
inherent characteristics of immutability and transparency, blockchain has
garnered widespread recognition as a suitable technology for achieving
regulatory compliance [21, 22, 23]. For instance, data recorded on the
blockchain is digitally signed and inherently tamper-proof, thereby
constituting an authentic and persistent record that accurately reflects an
event(s) at a specific point in time. This makes blockchain a fitting
candidate to address concerns related to data provenance and copyright
compliance within the AI industry [24, 25, 26].

We have identified a series of functional challenges that must be addressed in
the development of a such blockchain-based compliance framework: (i) The
framework must be designed to seamlessly integrate with the existing workflow
of AI model training. (ii) The framework should support continuous model
retraining and fine-tuning with new datasets, allowing for the generation of
updated models while maintaining data provenance and lineage. (iii) The
framework should support mechanisms for license expiration and renewal,
accommodating diverse business models employed by data owners. (iv) The
ownership of datasets and models, along with all training actions, should be
accompanied by evidence to clarify their licensing scope and ensure
accountability for any subsequent actions. (v) The framework should facilitate
communication between AI service providers and data owners, enabling efficient
attainment and documentation of licensing agreements. (vi) The framework
should ensure the effective management and commercial sensitivity of licenses,
safeguarding them against unauthorized access by third parties.

In this paper, we design, implement, and evaluate IBis, a blockchain-based
framework for data and model copyright management, provenance, and lineage in
AI model training processes. IBis empowers model owners to establish the
provenance and lineage of their AI models and training datasets throughout
retraining and fine-tuning processes, efficiently obtaining copyright licenses
from the relevant copyright holders, and securely recording and renewing
bilaterally signed copyright licenses as evidence of legal compliance. Our
detailed contributions are as follows:

  * •

We propose a blockchain-integrated framework, IBis, to track data and model
copyright management, provenance, and lineage. IBis exhibits the following
characteristics:

    * $\diamond$

Seamless integration (addressing c-i): By supporting iterative model
retraining and fine-tuning, accommodating diverse copyright agreements through
flexible license checks and renewals, and providing a unified API that
integrates with existing contract lifecycle management software, the framework
ensures minimal disruption to established model training and copyright
management processes.

    * $\diamond$

Adaptability (addressing c-ii and iii): By establishing links between models
in the model metadata, and integrating periodic license renewal checks via
smart contracts, IBis supports ongoing model retraining and license renewal.
Moreover, the on-chain license registry leverages blockchain’s immutability
property, allowing model owners and copyright holders to retrieve their past
licenses to prove regulatory compliance and avoid any disputes.

    * $\diamond$

Traceable registry (addressing c-iv): By deploying three on-chain, immutable
registries for dataset metadata, licenses, and model metadata, the framework
maintains authentic records of dataset and model relationships, ownership, and
their copyright agreements. The bidirectional links between these records
enables two-way traceability throughout data and model copyright management,
provenance, and lineage processes.

    * $\diamond$

Blockchain-based multi-party signing (addressing c-v): By leveraging the
identity management and digital signature capabilities offered by private-
permissioned blockchains, IBis enables efficient and secure multi-party
signing workflows between AI model owners and copyright holders, ensuring the
establishment of legally compliant licensing agreements.

    * $\diamond$

Controllability (addressing c-vi): By implementing on-chain access control
mechanisms and adhering to strict permission rules, IBis ensures that only
authorized parties can access the information pertaining to training datasets,
models, and licenses. Consequently, IBis facilitates an ecosystem encompassing
many AI models, datasets, and licenses, enabling model and data owners to
leverage the network effect of a unified platform while safeguarding their
commercial sensitivity needs.

  * •

We implement a fully-functional prototype111Open released at
https://github.com/yilin-sai/ai-copyright-framework. based on the Daml smart
contract language [27] and Canton blockchain protocol [28]. We adopted Daml
and Canton’s renowned privacy-preserving capabilities and modular design to
implement a secure and commercial-sensitivity-preserving framework with six
modules dedicated to license registration, management, and updating.

  * •

We conduct a series of performance evaluations of IBis, especially its
performance under a parameterized real-world scenario. Evaluation results show
that a model owner can retrieve a model’s datasets and its licenses in
approximately 1.5 and 3 seconds, respectively. This is irrespective of the
number of model owners, datasets, and licenses hosted within the framework.
Additionally, retrieving authorized models for a license takes approximately
1.5 seconds, regardless of the number of training datasets per model, model
owners, and licenses within the framework. These results demonstrate
scalability under varying numbers of users, datasets, models, and licenses.

The rest of the paper is organized as follows: Sec.II provides background and
related work. Sec.III gives the system architecture and our design. The
construction details of our framework, including data models and functional
operations, are presented in Sec.IV. Sec.V and VI present our implementation
with performance evaluations. Sec.VII offers conclusions and suggests avenues
for future research.

##  II Preliminaries

###  II-A Background

AI model training. In general, the training process for AI models is
continuous and iterative, containing training, retraining, and fine-tuning
[29]. As seen in Fig.1, training begins with data collection, where initial
training datasets are gathered through data scraping. These datasets are then
fed into the model training step, where a preliminary model is trained. To
ensure the model remains effective and up-to-date, it undergoes periodic
retraining with newly collected data, allowing it to adapt to new information.
Additionally, a model may undergo a fine-tuning phase, where it is slightly
retrained to meet specific domain requirements, enhancing its accuracy and
relevance for targeted applications.

Figure 1: Typical AI model training process.

Copyrights. Copyright grants creators exclusive rights to their original
expressions such as literary, artistic, and musical works. This legal
framework safeguards creators’ rights, allowing them to control how their work
is used, reproduced, and distributed.

Copyright protection is automatic upon creation, but it is implicit, requiring
additional steps for proper protection. First, registering the work with the
copyright office offers authoritative legal evidence of ownership and
eligibility for statutory damages in case of infringement. Second, adding a
copyright notice (©) with the creator’s name and the year of creation informs
others of the copyright claim [30], akin to a signature on a picture.
Additionally, NFTs [31] offer a novel method for embedding ownership of
digital art via blockchain technology, with ownership automatically claimed
upon minting.

Licensing is the primary method for granting or transferring the rights to a
work. Creators can control the scope of rights by specifying terms and
conditions within the license agreement. Licenses may vary widely, from
granting broad permissions to restricting usage to specific purposes or
timeframes.

###  II-B Related Work

Protecting copyright/data in AI. Data and copyright protection in AI services
is a long-standing topic. Existing methods can classified in several aspects
[32]: Data-modifying approaches involve modifying or sanitizing user data to
unlink them from specific individuals (e.g., k-anonymity [33], differential
privacy [34], and watermarking [35]). This minimizes the risk of
reidentification by removing or concealing Personally Identifiable Information
(PII). Data-encrypting approaches encrypt user data to ensure integrity and
confidentiality during data sharing, leveraging techniques such as homomorphic
encryption [36] and secure Multi-Party Computation (MPC) [37, 38]. Data-
minimizing approaches aim to boost efficiency by reducing the volume of
personal data needed [39], often observed in general model training where PII
data are not required during training and minimally during inference. Data-
confining approaches involve AI methods that operate without sharing PII data
beyond user boundaries [40], ensuring data integrity and confidentiality while
enabling effective personalization through local access to personal data.

Blockchain-empowered copyright management. Liang et al. [41] employed smart
contracts to establish a homomorphic encryption mechanism aimed at
safeguarding circuit copyrights. Liu et al. [42] employed a blockchain-based
fraud-proof protocol to secure ownership rights over AIGC (artificial
intelligence-generated content). Numerous similar solutions are outlined in
studies such as [43, 44, 45]. It is worth noting that most existing
blockchain-based studies treat each copyright merely as a form of non-fungible
online property, akin to an NFT. However, this approach restricts its
practical utility in real-world scenarios that require varied operations like
registration, renewal, and termination – features that our framework offers in
contrast.

Leveraging blockchain in AI. Recent studies made efforts to empower AI and
foundational models with blockchain technology, aiming to build a more robust
and trustworthy AI in distributed environments. IronForge [46] proposes a
decentralized federated learning framework that integrates a distributed
ledger and a Directed Acyclic Graph (DAG)-based data structure to
asynchronously distribute training resources. Petals [47] is a distributed
deep learning system that can effectively operate and refine complex models.
It utilizes volunteer computing, outperforming traditional RAM offloading,
particularly in autoregressive inference tasks. BlockFUL [48] introduces a
decentralized federated unlearning framework that utilizes a redesigned
blockchain structure leveraging Chameleon Hash. It decreases the computational
and consensus costs associated with unlearning tasks. GradientCoin [49]
introduces a theoretical concept for a decentralized LLM that functions akin
to a Bitcoin-like system.

##  III Proposed Design: IBis

###  III-A Design Overview

Roles. We distinguish between two pivotal roles: AI Model Owners (AOs) and
Copyright Owners (COs). AOs act as representatives of the creators or
uploaders of AI models, who construct, train, maintain, and commercialize the
AI models. In our framework, their responsibilities include the categorization
of data, acquirement of licenses, and registration of dataset/model metadata
onto the blockchain. COs are the rightful copyright holders of training data
with the authority to license their data, encompassing content creators and
media companies among others. Their involvement extends to the drafting and
bilateral signing of license agreements, ensuring regulatory compliance, and
the protection of intellectual property rights. Likewise, a foundational model
owner is also a CO from the point of view of an extended AO. In this scenario,
datasets utilized in developing the foundational model are licensed by a
separate set of COs, encompassing the licensing of derivative works.
Distinguishing between these two CO roles is not imperative within IBis, as it
can effectively keep track of complex data and model relationships (see
Sec.IV-B).

Architecture. We envision an ecosystem that empowers both AOs and COs to
harness the network effect of a unified platform to train and use numerous AI
models and datasets. For example, an CO could license the same dataset to
multiple AOs and reap the benefits of a pay-as-you-go model for dataset usage
or derived work within the same platform. Therefore, our proposed framework,
IBis (cf. Fig.2), is designed to integrate a blockchain network hosted by a
subset of AOs and COs. While established and commercially significant AOs and
COs may operate blockchain nodes, others only require the capability to
connect to one of them via an agent.

At its core, the blockchain network serves as the backbone, facilitating
secure and transparent interactions between AOs and COs. The system is
architected to abstract the complexities of blockchain interaction through an
agent service, offering user interface, authentication, and request buffering.
The agent service acts as a bridge, connecting the AOs and COs with the
blockchain, thereby enabling efficient metadata registering and licensing
processes. Additionally, the system architecture includes dedicated components
for handling dataset metadata registration, bilateral license signing, and
model metadata management, each playing a crucial role in the overall workflow
of AI model training and copyright handling.

Figure 2: Architecture design.

Key modules. IBis has the following six main modules (marked by green in
Fig.2):

  * •

Dataset Metadata Registry (DMR) maintains an on-chain metadata record for each
dataset scraped by AOs. These records include details such as the dataset’s CO
and its source URL.

  * •

License Registry records copyright licenses that are bilaterally signed by the
corresponding CO and AO, serving as evidence of data use agreements. When a
dataset is licensed, a two-way linkage is established between the license
record and the DMR record of the dataset. A single license may cover multiple
datasets.

  * •

Model Metadata Registry (MMR) stores the metadata of a model once it has been
trained. This metadata includes the model’s identifier, as well as the
identifiers of training datasets and source models. It maintains a persistent
record of the datasets and source models utilized in models’ training, thereby
establishing data provenance.

  * •

Multi-party Signing Services (MSS) orchestrate communication between AOs and
COs. It handles tasks such as sending license request emails to COs and
returning license drafts to AOs. Most importantly, leveraging the identity
management and digital signature capabilities of the blockchain, MSS ensures
secure multi-party signing processes for establishing copyright licenses.

  * •

Contract Lifecycle Management (CLM) provides a unified API to interface with
various external CLM software solutions that manage licenses. This approach
ensures compatibility with a range of CLM software solutions, minimizing
disruption to COs’ existing workflows.

  * •

License Validity Check (LVC) employs smart contracts to verify the validity of
a license based on a set of environment variables, including the current date,
AO’s operating location, and any other variables that could potentially
contravene terms and conditions stipulated in the license. Our framework
allows the creation of custom LVC smart contracts targeting different license
types.

Stages. For the initial model training, the workflow of our framework can be
segmented into the following three stages:

S1. Dataset registering and license check: This involves dataset
categorization, metadata registration, and license checks via smart contracts
to ensure copyright compliance.

Specifically, the workflow begins with dataset categorization, where datasets
are organized into specific categories based on their content, source, and
usage. This categorization facilitates efficient retrieval and management of
datasets throughout the AI model development process. Following
categorization, metadata registration takes place via DMR, recording crucial
details such as data descriptions, authorship information, and usage rights
within a structured format. This step ensures that comprehensive information
about the datasets is readily accessible and referenced during their
lifecycle. Finally, license checks are conducted via LVC smart contracts,
utilizing automated processes to verify the authenticity and compliance of
licenses associated with the datasets. Smart contracts ensure that AI model
training and usage adhere to copyright agreements providing a streamlined and
compliant workflow for managing datasets and their associated licenses.

S2. License drafting and bilateral signing: In case of failed license checks,
this stage involves drafting and bilateral signing of licenses, facilitated by
the MSS and CLM.

Upon identifying any missing, expired, or reworked licenses during stage S1,
the process swiftly progresses to crafting bespoke license agreements tailored
to the unique datasets and their intended applications. Leveraging recent
advances in MSS technology, stakeholders embark on bilateral negotiations to
refine the terms of these agreements, culminating in their formal
agreement/contract through digital signatures. Finalization of agreements
occurs only upon the attainment of signatures from both parties. Subsequently,
CLM solutions seamlessly interface with current systems, streamlining contract
management duties including drafting, approval workflows, and compliance
oversight.

S3. Model metadata registering and copyright owner notification: In this
stage, post-training models are recorded in on-chain MMR, creating a
bidirectional linkage between models and training datasets. Notifications may
be dispatched to COs as stipulated by the licensing agreement.

###  III-B Details of Each Stage

The flowchart in Fig.3.a illustrats how IBis is integrated into existing AI
model training. Next, we discuss the main stages in detail, and Fig.4 depicts
interactions across IBis modules.

Figure 3: Integration with existing AI workflow. Figure 4: Functional design
across each module.

####  III-B1 Dataset metadata registering and license check

During or after the initial data scraping process, AOs categorize the data
into one or more datasets and register the metadata of each dataset on the
blockchain. The on-chain DMR maintains a metadata record for each dataset,
containing details such as its CO222The method for acquiring copyright owner’s
information during data scraping is out of the scope of this paper. and source
URL (refer to Sec.IV-A for detailed information on data model specifics).
Notably, IBis operates under the assumption that COs are uniquely
identifiable, and the AO organizes the data in such a manner that each dataset
is associated with only one copyright owner. A corner case arises when a
dataset originates from the public domain and therefore lacks a distinct
owner. In such instances, we stipulate the use of a designated copyright owner
identifier, “public-domain”, to account for public domain data.

Datasets registered in DMR are not automatically eligible to become training
data. To adhere to copyright laws, each dataset must undergo a vetting step,
involving a check for the existence and validity of its license. During this
step, AO extracts attributes of a dataset and queries the license registry on
the blockchain for a corresponding license. Sec.IV-B describes the license
registry search mechanism. Once a license is found, its validity is checked
using the LVC smart contract. Only a dataset that passes the license check is
deemed eligible for model training. Regarding the corner case of public domain
data, the license registry is preloaded with a public domain license that
always passes the LVC. Here, the mechanism of an LVC can vary depending on the
type of license. For instance, certain licenses may impose geographic
restrictions, while others may have time or number of use limits.
Consequently, our framework facilitates the creation of different LVC smart
contracts to accommodate such diverse and complex conditions. We define a
generic LVC interface contract to dynamically determine which specific LVC
contract to utilize based on the license being evaluated.

After the dataset successfully passes the license validity check, the
licenseId attribute in its metadata will be updated to reference the valid
license. Additionally, the dataset’s identifier will be added to the license’s
datasetList attribute. This establishes a bidirectional linkage between a
dataset and its corresponding license.

####  III-B2 License agreement drafting and bilateral signing

If the license existence or validity checks fail, AO must initiate a license
agreement drafting and signing stage to obtain a license from the CO. This
stage commences with AO sending a license request to the corresponding CO.
This request is routed through MSS, which then generates an email containing
the request details and along with a link for CO to take necessary actions.
One of the actions involves drafting a license agreement based on the request.
The CO executes this drafting action by invoking the API via CLM. Connectors
that interface with various external CLM software solutions implement this
API. This design is predicated on the understanding that COs often rely on
proprietary software to draft their licensing agreements and manage data
subscriptions. Thus, we leverage the CLM’s API and connectors to ensure
compatibility with a range of existing CLM software solutions, minimizing
disruption to the copyright owners’ existing workflow.

Figure 5: MSS workflow.

Once the CO drafts the license agreement using the CLM software, the agreement
is transmitted back to the framework via the CLM connector and API.
Subsequently, CO and AO engage with the MSS to generate a bilaterally signed
license agreement (cf. Fig.5). The signed license agreement is then recorded
in the license registry. The dataset’s DMR record is also updated to reference
the newly acquired license, thereby concluding the license agreement drafting
and signing stage. Here, MSS utilizes an email list comprising the email
addresses of AOs and COs. Email addresses can be added during user signup or
input by the counterparty.

####  III-B3 Model registration and CO notification

The previous two steps empower the AO to accumulate a pool of licensed
datasets that can be legitimately employed for AI model training. To establish
data and model provenance, it is imperative to maintain a reliable record of
the datasets and hyper-parameters utilized in each model’s training. This is
accomplished through the creation of MMR on the blockchain. Following the
training of a model, its metadata, comprising its identifier, hyper-
parameters, and the identifiers of the training datasets, are recorded on the
MMR.

Furthermore, for each training dataset, its DMR record is updated to include
the identifier of the new model. This establishes a bidirectional linkage
between a model and its training dataset. Finally, depending on the terms
outlined in the licensing agreement, the framework may dispatch notifications
to the respective copyright owners, informing them of the new model trained
using their data.

###  III-C AI Model Retraining and Fine-tuning

The system architecture outlined above not only supports initial model
training but also facilitates model retraining and fine-tuning, wherein newly
collected data are integrated into the model. As new data are scraped and
collected, DMR continues to expand, while new licenses are acquired and stored
in the license registry, ensuring the legitimacy of new datasets.
Consequently, during the AI model retraining and fine-tuning, the initial two
stages remain unchanged.

However, in retraining and fine-tuning scenarios, it is possible that the
original model may need a license renewal at the time of retraining or fine-
tuning, as one or more licenses of its training datasets might have become
invalid (e.g., expired). Therefore, before retraining or fine-tuning the
model, an additional stage is necessary to verify data eligibility by
determining if the model requires a license renewal. Fig.3(b) depicts the
flowchart of actions during model retraining or fine-tuning. Sec.IV-C1
presents the detailed mechanism used to conduct the license renewal check.

Moreover, compared to the stages in the initial training process, a divergence
arises in the final stage concerning the establishment of data provenance. The
new model is a culmination of the original model merged with new datasets.
Hence, when recording a new entry in MMR for the retrained/fine-tuned model,
in addition to recording the identifiers of the training datasets, the AO must
also record the identifier of the original model. This facilitates data
provenance and model lineage throughout the iterative model retraining or
fine-tuning process. Meanwhile, the metadata of the original model must be
updated to include a reference to the new model, thus establishing a
bidirectional linkage between the new model and its source model. Complete
information on model metadata specifics can be found in Sec.IV-A.

##  IV Detailed Construction

###  IV-A Data Models

The main attributes that IBis framework supports can be broadly grouped as
follows (see Table I):

  * •

Dataset attributes: A dataset is uniquely identified by a $\mathsf{datasetId}$
and sourced from a specific URL. It includes information on the copyright
owner, associated license, and models trained on it. Additionally, the
dataset’s ownership and creator are tracked through the CO’s
$\mathsf{copyrightOwnerId}$.

  * •

License attributes: Each license has a distinct $\mathsf{licenseId}$ and
encompasses a defined scope, typically a URL/URI. It includes details like
copyright ownership, digital signatures of owners, and validity timestamps.
The license type identifier $\mathsf{typeId}$ aids in determining the
applicable LVC smart contract for license validation. Moreover, it lists the
datasets covered under the terms of the license.

  * •

Model attributes: AI models are identified by a unique $\mathsf{modelId}$ and
associated with owners. They utilize datasets for training, which are listed
within the model’s attributes. Retrained models reference a source
$\mathsf{sourceModelId}$, and any subsequent models derived from it are listed
as child models in $\mathsf{childModelList}$. This structure establishes the
lineage of models and facilitates the tracking of relationships between models
and data within AI services.

TABLE I: Dataset, license, and model attributes.

| Atttributes |  Descriptions
---|---|---
Dataset | $\mathsf{datasetId}$ |  Unique identifier of the dataset.
$\mathsf{sourceUrl}$ |  URL from which the dataset was scraped.
$\mathsf{copyrightOwnerId}$ |  Unique identifier of the copyright owner.
$\mathsf{licenseId}$ |  Unique identifier of the copyright license.
$\mathsf{modelList}$ |  List of unique identifiers of the models trained on this dataset.
$\mathsf{modelOwnerId}$ |  Unique identifier of AO who scrapes and adds this dataset.
License | $\mathsf{licenseId}$ |  Unique identifier of the dataset.
$\mathsf{scope}$ |  URL to dataset. Datasets pointed by this URL fall within the scope of the license.
$\mathsf{copyrightOwnerId}$ |  Unique identifier of the copyright owner.
$\mathsf{copyrightOwnerSignature}$ |  Digital signature of the copyright owner.
$\mathsf{modelOwnerId}$ |  Unique identifier of the model owner.
$\mathsf{modelOwnerSignature}$ |  Digital signature of the model owner.
$\mathsf{validFrom}$ |  Timestamp indicating when the license takes effect.
$\mathsf{typeId}$ |  Unique identifier of the license type. Used to determine the smart contract to check the license validity.
$\mathsf{datasetList}$ |  List of identifiers of the datasets covered by this license.
Model | $\mathsf{modelId}$ |  Unique identifier of the AI model.
$\mathsf{modelOwnerId}$ |  Unique identifier of the model owner.
$\mathsf{datasetList}$ |  List of unique identifiers of training datasets.
$\mathsf{sourceModelId}$ |  Unique identifier of the source model that has been retrained.
$\mathsf{childModelList}$ |  List of identifiers of the models trained based on this model.

We highlight two aspects. First, the data model is extensible, enabling AOs
and COs to incorporate additional custom attributes as needed. For example, a
storage URL can be included in dataset metadata to indicate where AO stores
the dataset. License can include custom attributes such as expiration date,
exclusivity, and other terms and conditions. Second, a web path is employed to
delineate the scope of what is being licensed, considering that the majority
of AI models are trained using online data.

A running example. Fig.6 illustrates the logical interrelation among the three
data models, within an example scenario where Model-1 is initially trained
using three datasets, and subsequently retrained with a fourth dataset to
yield Model-2. The two models are linked through Model-2’s
$\mathsf{sourceModelId}$ attribute and Model-1’s $\mathsf{childModelList}$. A
dataset and a model are linked through the model’s $\mathsf{datasetList}$ and
the dataset’s $\mathsf{modelList}$. A license and a dataset are linked through
the license’s $\mathsf{datasetList}$ and the dataset’s $\mathsf{licenseId}$.

###  IV-B Functional Operations

This section delineates the operations that can be performed by AOs and COs,
along with their time complexity analysis. Table II lists the time complexity
of operations and the entities authorized to perform them. We assume that the
on-chain license registry, DMR, and MMR are implemented as hash maps on a
smart contract, resulting in a time complexity of $O(1)$ for searching them.

Figure 6: Model, dataset, and license relationships.

Obtain dataset licenses. The $\mathsf{getDatasetLicense}$ operation retrieves
copyright license of a given a dataset identifier $\mathsf{datasetId}$. It
initially searches the DMR hash map using the dataset $\mathsf{datasetId}$ as
the key, which incurs a time complexity of $O(1)$. Depending on whether the
returned DMR record contains a $\mathsf{lisenceId}$, this operation either
retrieves the license by $\mathsf{licenseId}$ or searches for a relevant
license in the license registry as follows:

  * •

Retrieve the license with $\mathsf{licenseId}$: This operation queries the
license registry hash map using the $\mathsf{licenseId}$ as the key. As the
resulting time complexity is $O(1)$, the overall time complexity remains the
same.

  * •

Search for a relevant license: This operation extracts the dataset’s
$\mathsf{copyrightOwnerId}$ and performs a search on the license registry
using $\mathsf{copyrightOwnerId}$, which involves a complexity of $O(1)$. This
search may yield a list of licenses with the same $\mathsf{copyrightOwnerId}$
(albeit with different scopes). Finally, a scan is conducted on the list of
licenses to filter out the licenses with irrelevant scopes. Our framework
operates on the premise that license scopes do not intersect, ensuring each
dataset corresponds to at most one license. As CO is unlikely to have many
licenses with the same AO for practical reasons, one can assume the size of
this list to be small. Consequently, we can still assume the overall time
complexity to be $O(1)$.

TABLE II: Operations, complexities, and authorizations.

Operation | Complexity | Authorisations
---|---|---
$\mathsf{getDatasetLicense}$ | $O(1)$ | AOs
$\mathsf{getModelLicenses}$ | $O(|D|+|M|)$ | AOs
$\mathsf{checkLicenseValidity}$ | $O(|E|)$ | AOs/COs
$\mathsf{getLicensedDatasets}$ | $O(|D||E|)$ | AOs
$\mathsf{getDatasetsByLicense}$ | $O(1)$ | AOs
$\mathsf{getModelsByLicense}$ | $O(|D||M|)$ | AOs
$\mathsf{getModelDatasets}$ | $O(|M|)$ | AOs

Obtain model license. Given a model identifier $\mathsf{modelId}$, the
$\mathsf{getModelLicenses}$ operation retrieves the licenses of its training
datasets. This operation requires executing $\mathsf{getDatasetLicense}$ for
each of xthe training datasets of the provided model and its upstream source
models. To identify the contributing training datasets, the operation
functions as a graph traversal algorithm on a graph with the given model as
the root node, the upstream models as intermediate nodes, and the datasets as
leaf nodes (as depicted in Fig.6). The time complexity of a basic graph
traversal algorithm is $O(|V|+|E|)$, where V is the set of vertices and E is
the set of edges. Therefore, given a graph with a set of M models and D
datasets, the time complexity of the graph traversal is $O(|D|+|M|)$. As
$\mathsf{getDatasetLicense}$’s complexity is $O(1)$, the graph traversal
dominates the overall time complexity.

Check license validity. Given license data and environment variables as
transaction inputs, the $\mathsf{checkLicenseValidity}$ operation verifies the
validity of the license. Environment variables include the current date, the
operating locations of AOs, and other variables that could potentially
contravene the terms and conditions stipulated in the license agreement.

First, we need to locate the corresponding LVC smart contract for validating
the license. This can be accomplished using another hash map where the license
type $\mathsf{typeID}$ serves as the key and LVC’s address as the value.
Consequently, this lookup operation can be performed in constant time, i.e.,
$O(1)$. Next, we need to invoke the identified LVC contract to determine the
license validity. The time complexity of the LVC contract is directly
proportional to the number of environment variables that need validation. We
abstract this time complexity as $O(|E|)$, where E is the set of environment
variables to validate. Therefore, the overall time complexity is
$O(1)+O(|E|)=O(|E|)$.

Obtain licensed datasets. The $\mathsf{getLicensedDatasets}$ operation
retrieves the list of dataset identifiers $\mathsf{datasetId}$s each with a
valid license. It entails executing $getDatasetLicense$ and
$checkLicenseValidity$ operations for each dataset. Given D datasets, the
overall time complexity is $O(|D|\times\\{O(1)+O(E)\\}=O(|D||E|)$.

Obtain authorized datasets by license. Given a license identifier
$\mathsf{licenseId}$, the $\mathsf{getDatasetsByLicense}$ operation retrieves
datasets covered by the license. This operation performs a search of the DMR
using the licenseId, resulting in a time complexity of $O(1)$.

Obtain authorized models by license. Given a license identifier
$\mathsf{licenseId}$, the $\mathsf{getModelsByLicense}$ operation retrieves
the metadata of the models covered by the license. This operation entails
executing $\mathsf{getDatasetsByLicense}$, followed by conducting a graph
traversal that goes from each dataset to the models trained on it (including
child models indirectly trained on it). In the worst case, the overall time
complexity is $O(|D||M|)$.

Obtain model datasets. Given a model identifier $\mathsf{modelId}$, the
$\mathsf{getModelDatasets}$ operation retrieves the identifiers of its
training datasets. This operation extracts the $\mathsf{datasetList}$
attribute from the provided model and its upstream source models. If the
provided model has a set of M upstream models, then the time complexity is
$O(|M|)$.

###  IV-C License Renewal

License validity check is an ongoing task because a valid license may become
invalid under certain circumstances (e.g., revoked or expired), necessitating
AOs and COs to take appropriate actions to ensure continuous compliance with
copyright laws. Following delineates how the framework facilitates license
renewal checks and renewals.

####  IV-C1 License Renewal Check

The framework supports three types of license renewal checks (LRCs): license-
driven, dataset-driven, and model-driven.

In license-driven LRC, AOs or COs conduct a periodic scan of the license
registry, performing $\mathsf{checkLicenseValidity}$ on each license. If a
license fails the validity check, an AO can execute the
$\mathsf{getModelsByLicense}$ operation to gather the identifiers of datasets
and models that depend on the invalid license. These can be added to a
blacklist to prevent the use of those datasets and models in future training
of new models or retaining. The specifics of how the blacklist is stored and
managed fall beyond the scope of this paper.

Dataset-driven and model-driven LRC can be conducted on-demand before training
a new model. In dataset-driven LRC, an AO can execute
$\mathsf{getDatasetLicense}$ operation followed by the
$\mathsf{checkLicenseValidity}$ operation for each training dataset to
identify any dataset needing a license renewal. In contrast, in model-driven
LRC, an AO can execute $\mathsf{getModelLicenses}$ operation followed by
$\mathsf{checkLicenseValidity}$ operation for each license of the model,
determining whether the model needs a license renewal.

####  IV-C2 License Renewal

A license renewal involves adding a new bilaterally signed license to the
license registry, rather than updating existing records. This enables AOs and
COs to access all historical licenses to prove regulatory compliance and avoid
any disputes. After a new license has been added, an AO can execute the
$\mathsf{getModelsByLicense}$ operation to gather the identifiers of datasets
and models that depend on the renewed license. Then the DMR records of
datasets are updated to reference the new license. As the list of dependent
datasets and models can now be considered eligible for training, their
identifiers are also removed from the blacklist.

]

###  IV-D Operation Atomicity

It is observed that several stages (i.e., S.1, S.3, and License Renewal)
involve the update of multiple records. Apart from ensuring integrity and
immutability, another advantage of maintaining DMR, license registry, and MMR
on-chain is that such multiple updates are guaranteed to be atomic. This is
because smart contracts can ensure atomicity where the actions included in one
transaction either all take effect or none of them take effect. Therefore,
care needs to be taken during implementation to ensure that all updates within
a stage should be included in the same transaction.

##  V Implementation on Daml

###  V-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.

TABLE III: Resources and authorisations.

Resource | Authorised Actor | Access Scope
---|---|---
DMR | AOs | Datasets added by the actor.
License Registry | AOs/COs | Licenses signed by the actor.
MMR | AOs | Models owned by the actor.
LVC API | AOs/COs | Licenses signed by the actor.
CLM API | COs | Licenses drafted by the actor.

###  V-B Smart Contract Implementation

Listing 1 illustrates the license smart contract template, constructed based
on the data schema in Table I. The $\mathsf{copyrightOwner}$ and
$\mathsf{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 on-chain 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.

⬇

1template License with

2 licenseId: Text

3 scope: Text

4 copyrightOwner: Party

5 modelOwner: Party

6 validFrom: Time

7 typeId: Text

8 datasetList: [Text]

9 where

10 signatory copyrightOwner, modelOwner

11

12 key (modelOwner, licenseId) : (Party, Text)

13 maintainer key._1

Listing 1: Daml smart contract template for license.

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

  * •

Only $\mathsf{modelOwner}$ has the authority to create and access these
contracts.

  * •

$\mathsf{modelOwner}$ is restricted to accessing $\mathsf{DatasetMeta}$ or
$\mathsf{ModelMeta}$ contracts created by themselves.

Full implementation details are open sourced333Open released at
https://github.com/yilin-sai/ai-copyright-framework.. Fig.7 illustrates the
class diagram of IBis design.

Figure 7: The class diagram of IBis implementation.

###  V-C Multi-party Signing

The generation of a bilaterally signed license contract adheres to Daml’s
Propose and Accept
Pattern444https://docs.daml.com/daml/patterns/initaccept.html#the-propose-and-
accept-pattern.. 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
choice555https://docs.daml.com/daml/intro/4_Transformations.html#choices-as-
methods, allowing the counterparty to exercise their decision. Upon exercising
the accept choice, a result contract is generated, symbolizing the agreement
between the two parties.

⬇

1template LicenseAgreement with

2 id: Text

3 scope: Text

4 copyrightOwner: Party

5 modelOwner: Party

6 validFrom: Time

7 typeId: Text

8 datasetList: [Text]

9 where

10 signatory copyrightOwner

11

12 key (copyrightOwner, id) : (Party, Text)

13 maintainer key._1

14

15 choice Accept: ContractId License

16 controller modelOwner

17 do create License

18 with licenseId; scope; copyrightOwner; modelOwner; validFrom; typeId;
datasetList

Listing 2: Daml smart contract template for license agreement.

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

##  VI Evaluation

###  VI-A Experimental Setup

Our proof-of-concept IBis implementation was deployed on a private Canton
blockchain comprising three nodes. All nodes were hosted on the same AWS EC2
$\mathsf{t2.xlarge}$ instance with four virtual CPUs and 16GB of RAM. While
Daml provides a range of options for data storage, PostgresSQL, running within
Docker containers, is chosen as the data storage to persist node data. Our
source code of the performance test is available666Testing script:
https://github.com/yilin-sai/ai-copyright-framework.

Our evaluation mainly focuses on three operations involving graph traversals:
fetching model licenses using $\mathsf{getModelLicenses}$, model datasets
using $\mathsf{getModelDatasets}$, and authorized models using
$\mathsf{getModelsByLicense}$. The former two operations pertain to copyright
management, while the latter concerns data provenance. To enhance the accuracy
of performance testing, for every parameter configuration, the operation of
$\mathsf{getModelLicenses}$ is executed ten times on ten randomly chosen
models, with the average execution time and standard deviation calculated
thereafter. Similarly, $\mathsf{getModelDatasets}$ undergoes execution on ten
randomly selected models. As for $\mathsf{getModelsByLicense}$, the operation
is performed on ten randomly chosen licenses, with the resultant average
execution time and standard deviation recorded.

###  VI-B Experimental Parameters

In real-world scenarios, the framework hosts data, including dataset metadata,
license, and model metadata, contributed by various AOs and COs. These
stakeholders engage in executing functional operations (outlined in Table II)
to realize data provenance and copyright management. Ensuring the efficiency
of operations, particularly those involving complex graph traversals, is
paramount in this context. The experimental environment is set up the
following parameters:

  * •

The framework accommodates $N$ AOs, where each scrape $D$ datasets for model
training. Therefore, the framework host a total of $N\times D$ datasets.

  * •

Each AO acquired $L$ licenses from various COs. Each dataset scraped by that
AO is assigned one of the $L$ licenses. For test purposes, the assignment is
done randomly. Consequently, the total number of licenses hosted in the
framework amounts to $N\times L$. In addition, some fraction of licenses may
be associated with multiple datasets, while other licenses without datasets.
This aligns well with real-world usage scenarios because AOs may collect
licenses before scraping the corresponding dataset.

  * •

To mirror the model retraining process in the real world, the experiment
assumes each AO retrained a model $M-1$ times and obtained a chain of $M$
models. Consequently, the total number of models hosted in the framework
amounts to $N\times M$.

  * •

Each model is trained on $T$ datasets. For the testing purpose, those datasets
are randomly picked from AO’s $D$ datasets.

Note that there are five parameters during the experimental setup, namely $N$,
$D$, $L$, $M$, and $T$. The system workload can be scaled up by increasing
these parameters. In our evaluation, adhering to the control variates method,
we measure the performance by varying each parameter individually while
keeping the other parameters fixed. Table IV lists the values of the four
parameters that remain fixed while adjusting the remaining parameter.

TABLE IV: Evaluation setup (adjusting $N$, $D$, $L$, $M$, $T$).

Parameter | N | D | L | M | T
---|---|---|---|---|---
N | 10 to 100 | 10 | 10 | 10 | 10
D | 10 | 10 to 100 | 10 | 10 | 100
L | 10 | 10 | 10 to 100 | 10 | 10
M | 1 | 1 | 1 | 1 to 10 | 1
T | 10 | 10 | 10 | 10 | 10 to 100

###  VI-C Evaluation of Fetching Model Licenses

Fig.8 illustrates the variations in execution time corresponding to
incremental adjustments in each of the five parameters. As explained above,
each data point represents the average execution time of
$\mathsf{getModelLicenses}$ in ten executions, with error bars indicating the
standard deviation. The result reveals that the execution time of
$\mathsf{getModelLicenses}$ increases linearly with the augmentation of the
number of models in the model chain $M$ and number of training datasets of
each model $T$. This correlation is logical, as elevating $M$ augments the
model training graph depth (see Fig.6), whereas elevating $T$ expands its
breadth.

The outcomes also indicate that the values of the number of scraped datasets
per model owner $D$, model owners $N$, and licenses per model owner $L$ exert
no discernible influence on the performance of $\mathsf{getModelLicenses}$. In
theory, these three parameters do not impact the graph size; hence they have
negligible effect on performance. However, theoretically, they could affect
performance as querying a record using its identifier might slow down with a
greater number of records. However, our optimization efforts, such as
designating data, model, and license identifiers as the primary key of a
record (cf. Sec.V-B), mitigate any observable impact of increased record
numbers. The results demonstrate that the performance of
$\mathsf{getModelLicenses}$ operation remains consistent regardless of the
number of model owners in the system, datasets they scrape, or licenses they
acquire, thereby affirming the scalability of the operation.

Figure 8: Performance of fetching model licenses.

###  VI-D Evaluation of Fetching Model Datasets

Fig.9 illustrates the variations in execution time corresponding to
incremental adjustments in each of the five parameters. The operation can be
viewed as a sub-operation of $\mathsf{getModelLicenses}$ that traverses the
entire graph from a model to licenses. In contrast, the
$\mathsf{getModelDatasets}$ operation stops the traversal early at the level
of datasets. Therefore, the two operations share many common characteristics
in terms of performance. The results highlight a notable correlation between
the execution time and the number of models in the model chain $M$ and
training datasets of each model $T$. As $M$ increases, indicating a deeper
model-data graph structure, and $T$ expands, indicating a broader breadth of
the graph, the execution time rises linearly. This relationship stems from the
increased computational complexity associated with traversing deeper and wider
graphs.

Moreover, experiments show that variations in the number of scraped datasets
per model owner $D$, model owners $N$, and licenses per model owner $L$ do not
significantly impact performance. This observation aligns with similar
findings for $\mathsf{getModelLicenses}$ and underscores the operation’s
scalability. The evaluated operation consistently maintains its performance
regardless of the number of model owners in the system, datasets they scrape,
or licenses they acquire, reflecting the scalability and efficiency in
managing data provenance.

Figure 9: Performance of fetching model datasets.

Figure 10: Performance of fetching authorized models.

###  VI-E Evaluation of Fetching Authorized Models

Fig.10 illustrates the variations in execution time corresponding to
incremental adjustments in each of the five parameters. The result exhibits an
overall increasing trend in execution time with the increasing number of
models in the model chain $M$. This observation is intuitive, as the operation
necessitates traversing more models as the chain of related model lengthens.
However, the average performance displays oscillations as $M$ increases,
accompanied by high standard deviations for each data point. These
fluctuations and high standard deviations stem from the presence of redundancy
of the licenses and datasets.

In real-world scenarios, redundancy often occurs because licenses may be
acquired in advance, before the corresponding data is scraped, or datasets may
be stored without immediate model training. Our experimental setup reflects
these real-world complexities, resulting in some executions being faster due
to the operation encountering redundant licenses or datasets. Consequently,
the graph traversal terminates early in these instances, leading to variations
in execution times. This phenomenon also explains the observed high standard
deviations in the other charts.

The results also indicate that the execution time remains constant as the
number of training datasets per model $T$ increases. This is because
increasing $T$ does not impact the size of the graph starting from a
particular license. However, the execution time linearly increases with the
increasing number of scraped datasets per model owner $D$. This phenomenon
occurs because as more datasets become associated with a license, the graph
starting from that license experiences an increase in breadth, consequently
prolonging the traversal time.

Additionally, the performance remains consistent with the increasing number of
model owners $N$ and licenses per model owner $L$, mirroring the behavior
observed in the previous operations. This consistency affirms the scalability
of IBis to accommodate a large number of users and licenses.

###  VI-F Discussions Between Evaluated Operations

It is evident that the execution time of fetching model datasets using
$\mathsf{getModelDatasets}$ operation is approximately half that of fetching
model licenses $\mathsf{getModelLicenses}$ using. This phenomenon arises
because fetching model datasets can be considered a sub-operation of fetching
model licenses, which undertakes partial tasks compared to all. While fetching
a license traverses the entire graph from a model to licenses, fetching a
dataset terminates the traversal early at the dataset level. Moreover, because
a training dataset consistently corresponds to a single license, traversing
from datasets to licenses involves the same number of edges as traversing from
models to datasets.

Moreover, the performance of fetching authorized model using
$\mathsf{getModelsByLicense}$ operation displays distinct performance
characteristics compared to the other two operations, particularly evidenced
by its high standard deviations. This variance arises due to the different
graph traversal directions. Additionally, the redundancy of datasets and
licenses is only encountered in the traversal direction of the operation.
Equivalently, while a dataset may not necessarily correspond to any model, a
model invariably corresponds to some datasets. Similarly, while a license may
not correspond to any datasets, a training dataset always corresponds to a
license. Consequently, the graph traversal performance in the direction of
$\mathsf{getModelsByLicense}$ exhibits greater statistical variability.

Overall, depending on the operation, the execution time can increase linearly
with the number of scraped datasets per model owner $D$, training datasets per
model $T$, or models in a model chain $M$. Meanwhile, the number of model
owners $N$ and licenses per model owner $L$ do not significantly affect the
execution time. This is consistent with our performance analysis in Table II
and validates scalability and feasibility.

##  VII Conclusion

In this paper, we present IBis, a blockchain-based data provenance, lineage,
and copyright management system for AI models. IBis provides evidence and
limits power scope for iterative model retraining and fine-tuning processes by
granting related licenses. We leverage blockchain-based multi-party signing
capabilities to streamline the establishment of legally compliant licensing
agreements between AI model owners and copyright holders. We also establish
access control mechanisms to safeguard confidentiality by limiting access to
authorized parties. Our system implementation is based on the Daml ledger
model and Canton blockchain. Performance evaluations underscore the
feasibility and scalability of IBis across varying user, dataset, model, and
license workloads. Potential future work includes exploring different on-chain
data structures to optimize the performance of graph traversals, and extending
IBis to cover additional stages in AI lifecycle, such as data cleaning, model
testing, and model explanation.

## References

  * [1] R. Bommasani _et al._ , “On the opportunities and risks of foundation models,” _arXiv preprint arXiv:2108.07258_ , 2021.
  * [2] W. X. Zhao _et al._ , “A survey of large language models,” _arXiv preprint arXiv:2303.18223_ , 2023.
  * [3] Y. Zhu _et al._ , “Large language models for information retrieval: A survey,” _arXiv preprint arXiv:2308.07107_ , 2023.
  * [4] L. Bonifacio, H. Abonizio, M. Fadaee, and R. Nogueira, “Inpars: Data augmentation for information retrieval using large language models,” _arXiv preprint arXiv:2202.05144_ , 2022.
  * [5] J. Li _et al._ , “Pretrained language models for text generation: A survey,” _arXiv preprint arXiv:2201.05273_ , 2022.
  * [6] J. Chen _et al._ , “Benchmarking large language models in retrieval-augmented generation,” in _AAAI_ , 2024.
  * [7] N. Carlini _et al._ , “Extracting training data from large language models,” in _USENIX Security_ , 2021, pp. 2633–2650.
  * [8] J. Hoffmann and thers, “An empirical analysis of compute-optimal large language model training,” _NIPS_ , vol. 35, pp. 30 016–30 030, 2022.
  * [9] T. Chu, Z. Song, and C. Yang, “How to protect copyright data in optimization of large language models?” in _AAAI_ , vol. 38, no. 16, 2024, pp. 17 871–17 879.
  * [10] N. Vyas, S. M. Kakade, and B. Barak, “On provable copyright protection for generative models,” in _Int. Conf. on Machine Learning (ICML)_. PMLR, 2023, pp. 35 277–35 299.
  * [11] Z. Yu, Y. Wu, N. Zhang, C. Wang, Y. Vorobeychik, and C. Xiao, “Codeipprompt: intellectual property infringement assessment of code language models,” in _Int. Conf. on Machine Learning (ICML)_. PMLR, 2023, pp. 40 373–40 389.
  * [12] Q. Lu _et al._ , “Developing responsible chatbots for financial services: A pattern-oriented responsible AI engineering approach,” _IEEE Intelligent Systems_ , 2023.
  * [13] Q. Lu, L. Zhu, X. Xu, J. Whittle, D. Zowghi, and A. Jacquet, “Operationalizing responsible AI at scale: CSIRO data61’s pattern-oriented responsible AI engineering approach,” _Communications of the ACM (CACM)_ , vol. 66, no. 7, pp. 64–66, 2023.
  * [14] A. Power, “Licensing agreements,” _Miss. LJ_ , vol. 42, p. 169, 1970.
  * [15] M. Benjamin, P. Gagnon, N. Rostamzadeh, C. Pal, Y. Bengio, and A. Shee, “Towards standardization of data licenses: The montreal data license,” _arXiv preprint arXiv:1903.12262_ , 2019.
  * [16] D. Contractor _et al._ , “Behavioral use licensing for responsible AI,” in _ACM Conf. on Fairness, Accountability, and Transparency_ , 2022, pp. 778–788.
  * [17] D. Siddarth, D. Acemoglu, D. Allen, K. Crawford, J. Evans, M. Jordan, and E. Weyl, “How AI fails us,” _arXiv preprint arXiv:2201.04200_ , 2021.
  * [18] R. Li _et al._ , “How do smart contracts benefit security protocols?” _arXiv preprint arXiv:2202.08699_ , 2022.
  * [19] L. T. Nguyen _et al._ , “Blockchain-empowered trustworthy data sharing: Fundamentals, applications, and challenges,” _arXiv preprint arXiv:2303.06546_ , 2023.
  * [20] X. Xu, I. Weber, and M. Staples, _Architecture for Blockchain Applications_. Springer, 2019.
  * [21] W. Zhang _et al._ , “Blockchain-based distributed compliance in multinational corporations’ cross-border intercompany transactions,” in _Advances in Information and Communication Networks_. Cham: Springer Int. Publishing, 2019, pp. 304–320.
  * [22] T. Scott, A. L. Post, J. Quick, and S. Rafiqi, “Evaluating feasibility of blockchain application for DSCSA compliance,” _SMU Data Science Review_ , vol. 1, no. 2, 2018.
  * [23] M. Allena, “Blockchain technology and regulatory compliance: Towards a cooperative supervisory model,” _European Review of Digital Administration & Law_, pp. 37–43, 2022.
  * [24] O. Ural and K. Yoshigoe, “Survey on blockchain-enhanced machine learning,” _IEEE Access_ , vol. 11, pp. 145 331–145 362, 2023.
  * [25] A. A. Hussain and F. Al-Turjman, “Artificial intelligence and blockchain: A review,” _ETT_ , vol. 32, no. 9, p. e4268, 2021.
  * [26] Y. Liu, F. R. Yu, X. Li, H. Ji, and V. C. Leung, “Blockchain and machine learning for communications and networking systems,” _IEEE Communications Surveys & Tutorials_, 2020.
  * [27] A. Bernauer _et al._ , “Daml: A smart contract language for securely automating real-world multi-party business workflows,” 2023.
  * [28] D. A. C. Team, “Canton: A Daml based ledger interoperability protocols,” Digital Asset, Tech. Rep., 2020. [Online]. Available: https://www.digitalasset.com/hubfs/Canton/canton-whitepaper.pdf?hsLang=en
  * [29] D. Kreuzberger, N. Kühl, and S. Hirschl, “Machine learning operations (MLOps): Overview, definition, and architecture,” _IEEE Access_ , vol. 11, pp. 31 866–31 879, 2023.
  * [30] J. Litman, “What notice did,” _Boston University Law Review_ , vol. 96, pp. 717–744, 2016.
  * [31] Q. Wang, R. Li, Q. Wang, and S. Chen, “Non-fungible token (NFT): Overview, evaluation, opportunities and challenges,” _arXiv preprint arXiv:2105.07447_ , 2021.
  * [32] C. Meurisch and M. Mühlhäuser, “Data protection in AI services: A survey,” _ACM Computing Surveys_ , 2021.
  * [33] B. Gedik and L. Liu, “Protecting location privacy with personalized k-anonymity: Architecture and algorithms,” _IEEE Trans. on Mobile Computing (TMC)_ , vol. 7, no. 1, pp. 1–18, 2007.
  * [34] D. Xu, S. Yuan, and X. Wu, “Achieving differential privacy and fairness in logistic regression,” in _Companion Proc. of The World Wide Web Conf. (WWW)_ , 2019, pp. 594–599.
  * [35] J. Zhang, Z. Gu, J. Jang, H. Wu, M. P. Stoecklin, H. Huang, and I. Molloy, “Protecting intellectual property of deep neural networks with watermarking,” in _AsiaCCS_ , 2018, pp. 159–172.
  * [36] R. Gilad-Bachrach _et al._ , “Cryptonets: Applying neural networks to encrypted data with high throughput and accuracy,” in _ICML_. PMLR, 2016, pp. 201–210.
  * [37] P. Mohassel and Y. Zhang, “Secureml: A system for scalable privacy-preserving machine learning,” in _SP_. IEEE, 2017, pp. 19–38.
  * [38] B. D. Rouhani, M. S. Riazi, and F. Koushanfar, “Deepsecure: Scalable provably-secure deep learning,” in _Proc. of the Annual Design Automation Conf. (DAC)_ , 2018, pp. 1–6.
  * [39] R. Shokri and V. Shmatikov, “Privacy-preserving deep learning,” in _CCS_ , 2015, pp. 1310–1321.
  * [40] S. Servia-Rodríguez, L. Wang, J. R. Zhao, R. Mortier, and H. Haddadi, “Privacy-preserving personal model training,” in _IEEE/ACM Int. Conf. on Internet-of-Things Design and Implementation (IoTDI)_. IEEE, 2018, pp. 153–164.
  * [41] W. Liang _et al._ , “Circuit copyright blockchain: Blockchain-based homomorphic encryption for IP circuit protection,” _IEEE Trans. on Emerging Topics in Computing (TETC)_ , vol. 9, no. 3, pp. 1410–1420, 2020.
  * [42] Y. Liu, H. Du _et al._ , “Blockchain-empowered lifecycle management for AI-generated content products in edge networks,” _IEEE Wireless Communications_ , 2024.
  * [43] A. Savelyev, “Copyright in the blockchain era: Promises and challenges,” _Computer Law & Security Review_, vol. 34, no. 3, pp. 550–561, 2018.
  * [44] N. Jing, Q. Liu, and V. Sugumaran, “A blockchain-based code copyright management system,” _Information Processing & Management_, vol. 58, no. 3, p. 102518, 2021.
  * [45] B. Wang _et al._ , “Image copyright protection based on blockchain and zero-watermark,” _TNSE_ , vol. 9, no. 4, pp. 2188–2199, 2022.
  * [46] G. Yu _et al._ , “Ironforge: An open, secure, fair, decentralized federated learning,” _TNNLS_ , 2023.
  * [47] A. Borzunov _et al._ , “Distributed inference and fine-tuning of large language models over the internet,” _NIPS_ , vol. 36, 2024.
  * [48] X. Liu _et al._ , “Decentralized federated unlearning on blockchain,” _arXiv preprint arXiv:2402.16294_ , 2024.
  * [49] Y. Gao, Z. Song, and J. Yin, “Gradientcoin: A peer-to-peer decentralized large language models,” _arXiv.2308.10502_ , 2023.
  * [50] E. Androulaki _et al._ , “Hyperledger Fabric: A distributed operating system for permissioned blockchains,” in _EuroSys_ , 2018, pp. 1–15.