Copyright for this paper by its authors. Use permitted under Creative Commons
License Attribution 4.0 International (CC BY 4.0).

Non official and non reviewed paper for CheckThat’23

[orcid=0000-0001-5909-2745<EMAIL_ADDRESS>url=https://manexagirrezabal.github.io/, ]

# KUCST at CheckThat 2023:
How good can we be with a generic model?

Manex Agirrezabal  Centre for Language Technology (CST), Department of Nordic
Studies and Linguistics, University of Copenhagen, Emil Holms kanal 2, 2300
Copenhagen, Denmark

(2023)

###### Abstract

In this paper111The author of the paper could not submit the paper on time for
various reasons, but the system did appear in the official CheckThat rankings.
we present our method for tasks 2 and 3A at the CheckThat2023 shared task. We
make use of a generic approach that has been used to tackle a diverse set of
tasks, inspired by authorship attribution and profiling. We train a number of
Machine Learning models and our results show that Gradient Boosting performs
the best for both tasks. Based on the official ranking provided by the shared
task organizers, our model shows an average performance compared to other
teams.

###### keywords:

LaTeX class paper template paper formatting CEUR-WS

##  1 Introduction

Checkworthiness, Subjectivity, Political Bias, Factuality, and Authority.
Those are interest areas of the CheckThat! Lab, which is the responsible of
organizing a series of competitions where different research groups are asked
to work on a challenge. In this work we decided to put our efforts in two of
those areas: subjectivity and political bias.

In the era of digital media and news, it is very important to ensure the
access to objective news. Failure to comply with this, may compromise
democracy, as subjective information can be used to shape the opinion of their
recipients (readers, listeners, and so on). Objectivity is, thus, a
requirement for a democratic society. This work is an attempt to provide a
model that can detect whether a sentence is objective or subjective.

If we move the discussion topic to a political side, political biases are
still a concern in society, especially now that broadcasting any type of
content is easier than previously. Let us suppose for a moment that we are
able to make sure that all news are objective. Even though we make sure that
all news are objective, this may still not mitigate political bias. It is
still possible to have politically biased articles if, for instance, some
information is missing, or there is no fact-checking. It is, therefore, very
important to control for these issues for a more democratic society.

In this paper we present our approach for tasks 2 [1] and 3A [2] at the
CheckThat2023 shared task [3]. Our approach is based on features inspired by
the authorship attribution and profiling community.

This paper is structured as follows. First we review some works on
subjectivity detection and political bias detection. Later we present the data
used and methods developed. After that we show the results of different models
and we further discuss them. We then conclude the paper and propose some
possible future directions.

##  2 Related work

### Subjectivity detection

Das and Bandyopadhyay [4] proposed a subjectivity detection model that
incorporates a combination of lexico-semantic, syntactic, and discourse-level
features. Their approach includes features such as POS tags, Sentiwordnet,
word stems, syntactic information, chunks, dependency information, and
discourse-level features like the title of the text, first paragraph, and last
two sentences. Additionally, they use genetic algorithms for optimization.
Notably, their experimental results demonstrate high precision and recall
rates exceeding 90% for the English language, with a particularly high recall.
Because of this, this model stands out as one of the most performant
approaches to date, offering valuable insights for future research directions.
In our work, however, we have focused on prioritizing genericness, simplicity,
and interpretability.

In the field of subjectivity detection, Lin and He [5] introduced subjLDA, a
model that leverages lexical clues and weak supervision. Initial findings
indicate that subjLDA outperformed the widely used LDA model in terms of
various evaluation metrics, with the exception of slightly lower objective
recall. Furthermore, subjLDA demonstrated comparable performance to a
previously proposed bootstrapping approach, despite utilizing a significantly
smaller training set. These results are highly intriguing, particularly given
the specific requirements of our task. SubjLDA would have been a reliable and
suitable choice, but as our interest is to check the performance of our
generic model, we will not make use of it.

Following recent trends, in the work by [6] they employed BERT and different
fine-tuning strategies for the detection of subjectivity in the data by [7]
and [8]

In their work, Sagnika [9] and colleagues tested the efficacy of CNN-LSTM
networks with attention for subjectivity detection. They represent sentences
as word embeddings that include sentiment and part-of-speech information. They
show that incorporating attention in their proposed model improves its
peformance, which is because the model can remember long range relationships
and dependencies within the sentences [9].

### Political bias detection

Baly and colleagues [10] conducted notable work in political bias detection by
constructing a well-balanced dataset encompassing a diverse range of topics
and media sources. They ensured the effectiveness of their models by testing
them with examples from unseen media during training. This approach prevents
the models from merely learning to detect the source of the target news
article, instead emphasizing the prediction of its political ideology. The
authors proposed several sophisticated models, including ones based on
adversarial media adaptation and a unique triplet loss framework to discourage
the models from predominantly modeling the source information rather than the
political bias present in the news article.

Chen et al. [11] conducted an analysis of political biases in news articles
using Recurrent Neural Networks with Gated Recurrent Units (GRU). In their
study, they employed a reverse feature analysis to gain further insights into
the results. To interpret the findings, they utilized various tools, including
LIWC (Linguistic Inquiry and Word Count) features [12]. Their investigation
revealed an interesting observation that the last quarter of news articles
appeared to be the most biased section. This finding sheds light on the
potential significance of the concluding parts of news articles in terms of
political bias.

There have been works in the development of political bias detection models
for other languages. For instance Gangula and colleagues [13] we created a
dataset that consisted of 1329 news articles from various Telugu newspapers.
Their task, which involves classifying bias towards political parties rather
than the typical left, right, or center categorization, introduces an
additional layer of complexity. This approach may prove beneficial as
different political parties often exhibit distinct styles, and their model may
capture these nuances. The authors utilized a headline encoder, an article
encoder, and an attention layer. Subsequently, they applied softmax to make
predictions regarding the associated political party. Comparing this
architecture to several less complex baseline methods, their final model
incorporating attention outperformed all the baselines.

In the work by Aksenov and colleagues, [14] a model for political bias
detection specifically designed for German language. They constructed a
dedicated dataset for this task and conducted experiments using various
features, including Bag-of-Words, TF-IDF, and BERT. Four different
classification models were trained: Logistic Regression, Naive Bayes, Random
Forest, and EasyEnsemble. Notably, they conducted an additional analysis to
identify the most relevant words associated with different bias classes. This
work closely aligns with our own approach, making it highly relevant to our
research.

##  3 Data and Mathod

We utilized the dataset provided by the organizers of the shared task [3, 1,
2]. The relevant details and statistics are presented in the table below. Task
2 consists of approximately 1,000 instances, wherein sentences from news
articles are annotated as either objective or subjective. Notably, around 60%
of the sentences are labeled as objective, while the remaining 40% are
classified as subjective. In Task 3A, we have access to a larger corpus of
approximately 45,000 instances, comprising news articles and their
corresponding headlines. Each article in Task 3A is annotated with a political
bias, indicating whether it leans towards the center, left, or right ideology.

Task | #classes | #instances (train) | #instances (test) | FE. time (mins)
---|---|---|---|---
Task 2 | 2 | 702 | 347 | 1.4
Task 3A | 3 | 30197 | 14874 | 94.35

In our approach to address the task at hand, we followed a general methodology
that we anticipated would be applicable to various tasks, including bot vs.
human discrimination, subjectivity detection, sexism detection, and others.
While our original intention was to compare feature importance across
different tasks, this article primarily emphasizes the characteristics of
subjectivity and political bias detection.

We employed a range of commonly used stylometric features, drawing inspiration
from the works of Koppel and Schler [15] and Stamatatos [16]. Specifically,
our feature set included the following:

  * •

Word-level Bag-of-Words (unigrams): This feature representation captures the
frequency of individual words in the input text.

  * •

TF-IDF Weighted Bag-of-Words (unigrams): This feature representation applies
TF-IDF weighting to the word-level Bag-of-Words, considering both the term
frequency and its inverse document frequency.

  * •

Character-level Bag-of-Words (1-4grams): This feature representation captures
the presence and frequency of character-level n-grams, ranging from 1 to 4
characters in length.

  * •

POS Tag Bag-of-Words (1-4grams): This feature representation encodes the part-
of-speech tags of the text, considering both the presence and frequency of
different POS n-grams.

  * •

Morphological Features: We utilized the Stanza package, specifying the
appropriate model, to extract morphological features from the input text.

  * •

BERT Encoding: To capture deeper contextual information, we employed the BERT-
based model [17], specifically the bert-base-cased model, to generate
embeddings for the input text.

We train seven different classifiers: K-Nearest Neighbors ($K=5$), Logistic
Regression, Linear Support Vector Machine, Multilayer Perceptron, Decision
Tree, Random Forest and Gradient Boosting. All models are trained using a
Train/test validation procedure, where two thirds of the data are used for
training and the remaining part is used for testing (0.66 vs 0.33).

##  4 Results and discussion

Please find in Table 1 and 2 the performance of different classifiers in the
two tasks, together with a majority baseline. We can observe that all models
surpass the majority baseline in terms of the weighted F1-score. Gradient
Boosting is the best classifier in both tasks and KNN seems to perform the
poorest in both cases as well.

We find relevant to briefly mention the training time, as this might be a
reason to select or avoid certain classifiers. In the case of Task 2, as the
amount of data is relatively small, all classifiers were trained in less than
one minute. However, in task 3A, as there were 30,000 instances for training,
it took around one hour for training the Gradient Boosting classifier. All
other methods required less than 5 minutes. If training time was to be a
relevant matter when deciding the best classifier, the next possible choice
could be the Logistic Regression or the Multilayer Perceptron.

| Majority | KNN | LR | LSVM | MLP | DT | RF | GB
---|---|---|---|---|---|---|---|---
weightedf1s | 0.459866 | 0.61393 | 0.708894 | 0.704949 | 0.682075 | 0.640001 | 0.719856 | 0.769598
accuracy | 0.608069 | 0.622478 | 0.714697 | 0.711816 | 0.688761 | 0.639769 | 0.729107 | 0.772334
Training time | $<1s$ | $<1s$ | $<1s$ | $<1s$ | $<30s$ | $<1s$ | $<1s$ | $<30s$
Table 1: Check that task 2 results (2 labels: OBJ, SUBJ) | Majority | KNN | LR | LSVM | MLP | DT | RF | GB
---|---|---|---|---|---|---|---|---
weightedf1s | 0.218145 | 0.419038 | 0.521688 | 0.455131 | 0.524287 | 0.453776 | 0.502435 | 0.559401
accuracy | 0.38927 | 0.421541 | 0.523262 | 0.510354 | 0.522791 | 0.451459 | 0.5119 | 0.561382
Training time | $<1s$ | $<1s$ | $<30s$ | $<5m$ | $<5m$ | $<1m$ | $<1m$ | $<1h$
Table 2: Check that task 3A results (3 labels: left, center, right)

Based on official results from the shared task organizers, in Task 2, our
model ranked 4th out of 11 teams with a Macro F1-score of $0.73$. This
indicates a reasonably good performance on the given task. The results for
Task 3A reveal a rather high Mean Absolute Error (MAE) of 0.736. Our model
secured the 3rd position out of 5 participants on the leaderboard. These
results highlight the challenging nature of the task.

In Task 2, we observed that TFIDF features consistently yielded poor results.
This finding suggests that the topic of a text may not significantly influence
the likelihood of it being subjective or objective. However, further
investigations are necessary to validate this hypothesis conclusively.

Additionally, we noticed that character Bag-of-Words (BOWs) features exhibited
relatively strong performance in both Task 2 and Task 3A. However, the exact
reasons behind their effectiveness remain challenging to interpret.

Our study utilized simple features, primarily focusing on authorship
attribution and profiling features. It is important to note that these
features may not be fully representative or capture the entirety of the
complex dynamics associated with the subjectivity and objectivity of texts.
Future research endeavors should consider incorporating more comprehensive and
diverse feature sets to enhance the accuracy and robustness of the models.

##  5 Conclusion and Future Work

In this work we present our approach for the detection of subjectivity and
political bias. We employed a generic model inspired by authorship attribution
and profiling, and tested with a number of classifiers. Our results show that
the Gradient Boosting method is the best performing one. Our model ranked 4th
out of 11 teams in task 2, and 3rd out of 5 teams in task 3A.

As our model was not specifically designed to perform subjectivity detection
or political bias detection, there are many improvements that can be done for
this specific task by including domain-specific features. For instance, as the
last portion of news articles tends to be more subjective [11], this
information could be exploited.

Besides, we believe it would be interesting to make an attempt to predict what
is the subjective portion of a news article when this is labeled as
subjective. This could be done in a similar way that structural sentiment
analysis was performed [18].

To conclude, we believe that the approach followed by Lin and He [5], where
they make use of lexical clues for subjectivity detection is a good future
direction, especially because the limited size of our corpus.

## References

  * Galassi et al. [2023] A. Galassi, F. Ruggeri, A. B.-C. no, F. Alam, T. Caselli, M. Kutlu, J. M. Struss, F. Antici, M. Hasanain, J. Köhler, K. Korre, F. Leistra, A. Muti, M. Siegel, M. D. Turkmen, M. Wiegand, W. Zaghouani,  Overview of the CLEF-2023 CheckThat! lab task 2 on subjectivity in news articles,  in: Working Notes of CLEF 2023–Conference and Labs of the Evaluation Forum, CLEF ’2023, Thessaloniki, Greece, 2023.
  * Da San Martino et al. [2023] G. Da San Martino, F. Alam, M. Hasanain, R. N. Nandi, D. Azizov, P. Nakov,  Overview of the CLEF-2023 CheckThat! lab task 3 on political bias of news articles and news media,  in: Working Notes of CLEF 2023–Conference and Labs of the Evaluation Forum, CLEF ’2023, Thessaloniki, Greece, 2023.
  * Barrón-Cedeño et al. [2023] A. Barrón-Cedeño, F. Alam, T. Caselli, G. Da San Martino, T. Elsayed, A. Galassi, F. Haouari, F. Ruggeri, J. M. Struss, R. N. Nandi, G. S. Cheema, D. Azizov, P. Nakov,  The clef-2023 checkthat! lab: Checkworthiness, subjectivity, political bias, factuality, and authority,  in: J. Kamps, L. Goeuriot, F. Crestani, M. Maistro, H. Joho, B. Davis, C. Gurrin, U. Kruschwitz, A. Caputo (Eds.), Advances in Information Retrieval, Springer Nature Switzerland, Cham, 2023, pp. 506–517.
  * Das and Bandyopadhyay [2010] A. Das, S. Bandyopadhyay,  Subjectivity detection using genetic algorithm,  Computational Approaches to Subjectivity and Sentiment Analysis (2010) 14.
  * Lin et al. [2011] C. Lin, Y. He, R. Everson,  Sentence subjectivity detection with weakly-supervised learning,  in: Proceedings of 5th international joint conference on natural language processing, 2011, pp. 1153–1161.
  * Huo and Iwaihara [2020] H. Huo, M. Iwaihara,  Utilizing bert pretrained models with various fine-tune methods for subjectivity detection,  in: Web and Big Data: 4th International Joint Conference, APWeb-WAIM 2020, Tianjin, China, September 18-20, 2020, Proceedings, Part II 4, Springer, 2020, pp. 270–284.
  * Pang and Lee [2004] B. Pang, L. Lee,  A sentimental education: Sentiment analysis using subjectivity summarization based on minimum cuts,  in: Proceedings of the 42nd Annual Meeting of the Association for Computational Linguistics (ACL-04), 2004, pp. 271–278.
  * Hube and Fetahu [2019] C. Hube, B. Fetahu,  Neural based statement classification for biased language,  in: Proceedings of the twelfth ACM international conference on web search and data mining, 2019, pp. 195–203.
  * Sagnika et al. [2021] S. Sagnika, B. S. P. Mishra, S. K. Meher,  An attention-based cnn-lstm model for subjectivity detection in opinion-mining,  Neural Computing and Applications 33 (2021) 17425–17438.
  * Baly et al. [2020] R. Baly, G. Da San Martino, J. Glass, P. Nakov,  We can detect your bias: Predicting the political ideology of news articles,  in: Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), 2020, pp. 4982–4991.
  * Chen et al. [2020] W.-F. Chen, K. Al Khatib, H. Wachsmuth, B. Stein,  Analyzing political bias and unfairness in news articles at different levels of granularity,  in: Proceedings of the Fourth Workshop on Natural Language Processing and Computational Social Science, 2020, pp. 149–154.
  * Pennebaker et al. [2015] J. W. Pennebaker, R. L. Boyd, K. Jordan, K. Blackburn, The development and psychometric properties of LIWC2015, Technical Report, 2015.
  * Gangula et al. [2019] R. R. R. Gangula, S. R. Duggenpudi, R. Mamidi,  Detecting political bias in news articles using headline attention,  in: Proceedings of the 2019 ACL workshop BlackboxNLP: analyzing and interpreting neural networks for NLP, 2019, pp. 77–84.
  * Aksenov et al. [2021] D. Aksenov, P. Bourgonje, K. Zaczynska, M. Ostendorff, J. M. Schneider, G. Rehm,  Fine-grained classification of political bias in german news: A data set and initial experiments,  in: Proceedings of the 5th Workshop on Online Abuse and Harms (WOAH 2021), 2021, pp. 121–131.
  * Koppel et al. [2009] M. Koppel, J. Schler, S. Argamon,  Computational methods in authorship attribution,  Journal of the American Society for information Science and Technology 60 (2009) 9–26.
  * Stamatatos [2009] E. Stamatatos,  A survey of modern authorship attribution methods,  Journal of the American Society for information Science and Technology 60 (2009) 538–556.
  * Devlin et al. [2019] J. Devlin, M.-W. Chang, K. Lee, K. Toutanova,  BERT: Pre-training of deep bidirectional transformers for language understanding,  in: Proceedings of the 2019 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies, Volume 1 (Long and Short Papers), Association for Computational Linguistics, Minneapolis, Minnesota, 2019, pp. 4171–4186. URL: https://aclanthology.org/N19-1423. doi:10.18653/v1/N19-1423.
  * Barnes et al. [2022] J. Barnes, L. Oberlaender, E. Troiano, A. Kutuzov, J. Buchmann, R. Agerri, L. Øvrelid, E. Velldal,  SemEval 2022 task 10: Structured sentiment analysis,  in: Proceedings of the 16th International Workshop on Semantic Evaluation (SemEval-2022), Association for Computational Linguistics, Seattle, United States, 2022, pp. 1280–1295. URL: https://aclanthology.org/2022.semeval-1.180. doi:10.18653/v1/2022.semeval-1.180.


# Citadel: Self-Sovereign Identities on Dusk Network

Xavier Salleras  Dusk Network, Amsterdam, Netherlands  Universitat Pompeu
Fabra, Barcelona, Spain<EMAIL_ADDRESS>
## Abstract

The amount of sensitive information that service providers handle about their
users has become a concerning fact in many use cases, where users have no
other option but to trust that those companies will not misuse their personal
information. To solve that, Self-Sovereign Identity (SSI) systems have become
a hot topic of research in recent years: SSI systems allow users to manage
their identities transparently. Recent solutions represent the rights of users
to use services as Non-Fungible Tokens (NFTs) stored on Blockchains, and users
prove possession of these rights using Zero-Knowledge Proofs (ZKPs). However,
even when ZKPs do not leak any information about the rights, the NFTs are
stored as public values linked to known accounts, and thus, they can be
traced. In this paper, we design a native privacy-preserving NFT model for the
Dusk Network Blockchain, and on top of it, we deploy `Citadel`: our novel
full-privacy-preserving SSI system, where the rights of the users are
privately stored on the Dusk Network Blockchain, and users can prove their
ownership in a fully private manner.

Keywords: Self-Sovereign Identity; Dusk Network; Zero-Knowledge Proofs;
Blockchain; Applied Cryptography.

###### Contents

  1. 1 Introduction
    1. 1.1 Related Work
    2. 1.2 Contributions
    3. 1.3 Roadmap
  2. 2 Preliminaries
    1. 2.1 Elliptic Curves
    2. 2.2 Commitments and Hash Functions
    3. 2.3 Merkle Trees
    4. 2.4 Digital Signatures
    5. 2.5 Zero-Knowledge Proofs
    6. 2.6 zk-SNARKs
    7. 2.7 Blockchain
  3. 3 Phoenix Transaction Model
    1. 3.1 Overview of Phoenix
    2. 3.2 Protocol Keys
    3. 3.3 Protocol Details
  4. 4 Our Solution: Citadel
    1. 4.1 Overview
    2. 4.2 A Private NFT Model for Dusk
    3. 4.3 Description of Citadel
      1. 4.3.1 Protocol Details
      2. 4.3.2 Security Analysis
      3. 4.3.3 Benchmarks
  5. 5 Conclusions and Future Work
  6. Acknowledgements

##  1 Introduction

The amount of services available on the Internet is increasing year after
year, as well as the concerns about how Service Providers (SPs) handle the
sensitive information about their users. In this scenario, SPs are entities
that users need to trust, especially regarding the fact that they will behave
correctly when managing their personal information. In this regard, Self-
Sovereign Identity (SSI) systems [1, 2, 3] have become a research area of
interest in the last few years. When it comes to building privacy-preserving
authentication methods in services, they play a prominent role: grant users a
way to manage their identities in a fully transparent manner. In other words,
users of a service implementing an SSI system, are aware of all the sensitive
information the SP is requesting, and they can consent to or deny each
request.

SSI systems are useful in a wide set of scenarios, like distributing tickets
for events, managing users of video or music streaming subscriptions, using
car or parking sharing applications, etc. But these examples are not the only
kind of contexts where SSI systems are an important privacy feature to
implement. If we move our attention to the Internet of Things (IoT) paradigm,
we observe a growing density of IoT devices in our cities: medical devices,
pollution sensors, traffic lights, IP cameras, etc. In some examples, like an
autonomous car sharing its location with an SP or other cars nearby, being
able to share only such information but preventing traceability at the very
same time, would be an interesting feature to implement. In other words, would
be interesting to have SSI systems in these scenarios as well.

###  1.1 Related Work

Interesting SSI approaches have been introduced recently, like the one
detailed in [4]. This paper states a way to deploy an SSI system that grants
anonymity to its users at the network level. Other solutions like [5]
introduce a Blockchain-based system for preserving the privacy of users when
managing their vaccine certificates.

In most cases, state-of-the-art SSI systems use Zero-Knowledge Proofs (ZKPs)
[6] as the backbone of their architecture: cryptographic primitives allowing
users to prove knowledge of some information, without leaking anything about
it. This is the case of `SANS` [7], where the authors introduce a private
authentication protocol based on these primitives. Using `SANS`, users can
prove their rights to access different services, without the SP knowing the
identity of the users.

Often, they also rely on Blockchain technologies [8], in order to achieve
decentralization and immutability, when it comes to buying and granting rights
to users. For instance, projects like iden3111https://iden3.io or
Jolocom222https://jolocom.io build SSI systems where owners of Decentralized
Identities (DIDs) are able to manage them in a private manner. At the time of
writing this, both solutions rely on the Ethereum Blockchain.

On the other hand, `FORT` [9] is an SSI system that relies on Non-Fungible
Tokens (NFTs): assets uniquely identifiable that contain some specific
information. What they do, is represent the right acquired by someone as an
NFT stored on a Blockchain, and they can prove ownership of this right by
means of a ZKP. However, even when it does a great job preserving the privacy
of the users of different services, this solution still has some open problems
to address: the NFTs, as implemented nowadays, are publicly stored on
Blockchains like Ethereum. This means that, even when users can privately
prove ownership of such rights, they can still be traced on-chain. As stated
in the open problems section of their paper, the authors explain how being
able to integrate their solution into Blockchains like Dusk Network would lead
to enhanced privacy. Dusk Network is a Blockchain where all the transactions
are private by default, and capable of executing smart contracts with built-in
privacy features. Being able to integrate a private-by-design NFT model into
Dusk, would lead to the possibility of designing and deploying an SSI system
on top of it, which would prevent on-chain traceability.

Furthermore, `FORT` presents another problem: the SPs need to be trusted, as
the ZKPs sent to them could be reused by them, impersonating like this the
users. As such, finding a way to ensure that a license that has been already
used cannot be reused in other scenarios, would be a desirable feature.

###  1.2 Contributions

In this paper, we introduce two main contributions. First, we design a private
NFT model to be integrated into Dusk Network. Using such a model, a user
buying an NFT will receive a token that only they will be able to read. This
approach has full integration with the Dusk Network Blockchain: the changes to
the original protocol are minimal and have zero impact on their performance.
Plus, our contribution is secure under the same assumptions taken for the
original transaction model of Dusk, called Phoenix.

Second, we introduce `Citadel`: an SSI system fully integrated into Dusk that
allows users to acquire licenses (a.k.a. rights), and prove their ownership
using ZKPs. By means of our novel and private NFT model, the licenses are
privately stored in the Blockchain, and thus, we solve the traceability
problem that other solutions had. In particular, we provide a system with the
following capabilities:

  * •

Proof of Ownership: a user of a service is able to prove ownership of a
license that allows them to use such a service.

  * •

Proof of Validity: our solution introduces the possibility to revoke licenses.
Users can prove ownership of a valid license, that has not been revoked.

  * •

Unlinkability: the SP cannot link any activity of their users with other
activities done in the network.

  * •

Decentralized Nullification: our system solves the problem regarding the
possibility of reusing the proofs, where a malicious SP could impersonate the
user after receiving a valid proof: by means of an on-chain and decentralized
nullification, like done in the standard stack of Dusk, proofs cannot be
reused.

  * •

Attribute Blinding: the user is capable of deciding which information they
want to leak to the SP, blinding the value and providing only the desired
information.

Furthermore, our solution is fully integrated into the Dusk stack, where the
deployment of the solution will have minimal impact on other parts already
implemented. In this same regard, Dusk has some features allowing users to
delegate heavy computing tasks to trusted parties, in a secure and private
manner. Our solution has been designed taking all these features into account,
and thus, heavy computing tasks of our protocol can be delegated as well. This
fact is important, as allows for better scalability and faster integration of
our protocol into a wider set of scenarios, like web environments, IoT devices
with low computing power, etc.

After describing our solution in full detail, we analyze its security, and
finally provide benchmarks using our proof-of-concept implementation333The
proof-of-concept implementation can be found in the following repository:
https://github.com/dusk-network/citadel, to demonstrate its deployment
feasibility.

###  1.3 Roadmap

In Section 2, we introduce the preliminaries needed to follow up with the
whole paper. In Section 3, we introduce in detail Phoenix, the transaction
model of Dusk Network, needed to build our solution. In Section 4, we describe
`Citadel` with full details. We conclude and explain the future work in
Section 5.

##  2 Preliminaries

In this section, we introduce the background needed to understand the whole
paper. We first introduce the basics of elliptic curves, commitments, and
Merkle trees. Later, we review the specific ZKPs schemes related to our
solution, and finally, we describe Blockchain technologies.

###  2.1 Elliptic Curves

One of the main elements required for constructing the ZKP scheme that we will
use in this work are elliptic curves. An elliptic curve is defined as follows.

######  Definition 2.1 (Elliptic curve).

Let $E$ be an algebraic curve defined by the projective solutions of the
equation

$Y^{2}=X^{3}+aX+b,$

for some $a,b\in\mathbb{F}_{q}$. If $4a^{3}-27b^{2}\neq 0$, we call $E$ an
_elliptic curve over $\mathbb{F}_{q}$_, and denote this by $E/\mathbb{F}_{q}$.

We are particularly interested in the so-called pairing-friendly elliptic
curves, and we describe them now. Let $E$ be an elliptic curve over a finite
field $\mathbb{F}_{q}$, where $q$ is a prime number. We have the bilinear
groups $(\mathbb{G}_{1},\mathbb{G}_{2},\mathbb{G}_{T})$ of prime order $p$,
and a pairing

$e:\mathbb{G}_{1}\times\mathbb{G}_{2}\rightarrow\mathbb{G}_{T}$

being a bilinear map. As the map $e$ is bilinear, the following relation is
satisfied

$e(aP,bQ)=e(P,Q)^{ab},$

for any $P,Q\in E$.

We are particularly interested in two elliptic curves, needed later on to
describe the transaction model of Dusk Network. They are the BLS12-381 [10]
and the Jubjub [11] elliptic curves. Let $p,q$ be two specific prime numbers
of $255$ and $381$ bits, respectively. The curve BLS12-381 is defined over
$\mathbb{F}_{q}$ by the equation

$E:Y^{2}=X^{3}+4,$

and has different subgroups $\mathbb{G}_{1},\mathbb{G}_{2}$ such that
$\\#\mathbb{G}_{1}=\\#\mathbb{G}_{2}=p$. This curve is pairing-friendly,
meaning that pairings can be efficiently computed. On the other hand, the
Jubjub curve is defined by the equation

$J:-X^{2}+Y^{2}=1+\left(-\frac{10240}{10241}\right)X^{2}Y^{2},$

over $\mathbb{F}_{p}$ (it is important to recall that $p$ is the order of a
prime subgroup of the BLS12-381). We define a subgroup $\mathbb{J}$ whose
order $t$ is a $252$-bit prime. Throughout the document, we will mainly use
scalar values from the field $\mathbb{F}_{t}$, and elements from $\mathbb{J}$.

###  2.2 Commitments and Hash Functions

A _commitment scheme_ allows a party to commit to a secret value $v$, to be
revealed at a later time. A commitment scheme works like a safe-deposit box,
in the following sense. The party that wishes to make a commitment puts the
value $v$ inside the box, and locks it. They keep the key, but the box is kept
in a public place. The commitment _hides_ the value inside, until the owner
decides to use the key and open it. At the same time, the commitment _binds_
the value, ensuring that the owner cannot change it after committing. We are
particularly interested in Non-interactive Commitment Schemes, defined as
follows:

######  Definition 2.2 (Non-interactive Commitment).

A non-interactive commitment scheme consists of a tuple of algorithms (Setup,
Commit, Open). The Setup algorithm
$\mathsf{ck}\leftarrow\mathsf{Setup}(1^{\lambda})$ generates a public
commitment key $\mathsf{ck}$ given the security parameter $\lambda$. Given the
public commitment key $\mathsf{ck}$, the commitment algorithm Commit defines a
function
$\mathsf{Com}_{\mathsf{ck}}:\mathcal{M}\times\mathcal{R}\rightarrow\mathcal{C}$
for a message space $\mathcal{M}$, a randomness space $\mathcal{R}$ and a
commitment space $\mathcal{C}$. Given a message $m\in\mathcal{M}$, the
commitment algorithm samples $r\leftarrow\mathcal{R}$ uniformly at random and
computes $\mathsf{Com}_{\mathsf{ck}}(m;r)\in\mathcal{C}.$ Given $m,r$ and a
commitment $c\in\mathcal{C}$, the Open algorithm
$\mathsf{Open}_{\mathsf{ck}}(m;r;c)$ outputs $1/0$ whether or not $c$ is a
valid commitment for the pair $m,r$. A non-interactive commitment scheme is
perfectly hiding, and computationally binding under the discrete logarithm
assumption.

In this work, we will use the Pedersen commitment along with the Jubjub
elliptic curve. Let $\mathbb{J}$ be a group of order $t$ and set our message
and randomness spaces $\mathcal{M},\mathcal{R}=\mathbb{F}_{t}$ and our
commitment space $\mathcal{C}=\mathbb{J}$. The Setup, Commit, and Open
algorithms for Pedersen commitments are defined as follows:

  * •

_Setup._ Sample and output the commitment key
$\mathsf{ck}=(G,G^{\prime})\leftarrow\mathbb{J}^{2}$.

  * •

_Commit._ On input a message $m\in\mathcal{M}$, sample randomness
$r\leftarrow\mathbb{F}_{t}$ and output

$c=\mathsf{Com}_{\mathsf{ck}}(m;r)=mG+rG^{\prime}.$

  * •

_Open._ Reveal $m,r$. With these values, anyone can recompute the commitment
and check whether it matches the commitment previously provided.

The Pedersen commitment scheme is perfectly hiding, and computationally
binding under the discrete logarithm assumption.

On the other hand, we will make use of hash functions, which we define as
follows.

######  Definition 2.3 (Hash Functions).

A _cryptographic hash function_ is a function
$H:\\{0,1\\}^{*}\rightarrow\\{0,1\\}^{\ell}$ that is collision-resistant, that
is, it is hard to find $x,x^{\prime}\in\\{0,1\\}^{*}$ such that $x\neq
x^{\prime}$ but $H(x)=H(x^{\prime})$.

Throughout the document, we will be using two specific hash functions: first,
BLAKE2b [12], a lightweight and efficient hash function. Second, Poseidon
[13], whose main feature is being SNARK-friendly: it is cheap in terms of
computing resources when computed into a specific ZKP scheme called zk-SNARK.

###  2.3 Merkle Trees

_Merkle trees_ [14] are data structures containing at every node the hash of
its children nodes. Considering a $k$-ary tree of $h$ levels, the single node
at level $0$ is called the _root_ of the tree, and the $k^{h}$ nodes at level
$h$ are called the _leaves_. Given a node placed in the level $i$, the $k$
nodes in the level $i+1$ that are adjacent to it are called its _children_.
Plus, a node is the other’s _sibling_ if they all are children of the same
node.

The tree is partially updated every time a new value is written (or modified)
into a leaf, always resulting in a new root of the tree. Furthermore, given a
root $r$, it is easy to prove that a value $x$ is in a leaf of a tree with
root $r$. The proof works as follows:

  * •

_Prove._ For $i=h,\dots,1$, let $x_{i}$ be the node that is in level $i$ and
is in the unique path from $x$ to the root. Let $y_{i,1},\dots,y_{i,k-1}$ be
the $k-1$ siblings of $x_{i}$. Output

$(x,(y_{1,1},\dots,y_{1,k-1}),\dots,(y_{h,1},\dots,y_{h,k-1})).$

  * •

_Verify_. Parse input as
$(x_{h},(y_{1,1},\dots,y_{1,k-1}),\dots,(y_{h,1},\dots,y_{h,k-1}))$, where
$x_{h}$ is the purported value and $y_{i,1},\dots,y_{i,k-1}$ are the purported
siblings at level $i$. For $i=h-1,\dots,0$, compute444Additionaly, the prover
also has to send $\lceil\log_{2}k\rceil$ bits for each level, specifying the
position of $x_{i}$ with respect to its siblings, so that the verifier knows
in which order to arrange the inputs of the hash.

$x_{i}=H\left(x_{i+1},y_{i+1,1},\dots,y_{i+1,k-1}\right).$

If $x_{0}$ equals the root $r$ of the set we are proving membership of, the
proof is verified.

We can prove membership in a set of size $k^{h}$ by sending $kh$ values, so we
can state that the communication complexity for proving the membership is
$O(kh)$. If the hash function is collision-resistant, the proof is sound.

###  2.4 Digital Signatures

Digital signatures are one of the most important pieces needed to build our
solution. In particular, we are interested in the Schnorr signature scheme,
which we describe now. Let $G,G^{\prime}\leftarrow\mathbb{J}$. Then, we have
the following algorithms:

  * •

_Setup._ Sample a secret key $\mathsf{sk}\leftarrow\mathbb{F}_{t}$ and compute
a public key $\mathsf{pk}=\mathsf{sk}G$.

  * •

_Sign._ To sign a message $m$ using $\mathsf{sk}$, sample
$r\leftarrow\mathbb{F}_{t}$ and compute $R=rG$. Compute the challenge
$c=H(m,R)$, and set

$u=r-c\mathsf{sk}.$

Set the signature $\mathsf{sig}=(R,u)$.

  * •

_Verify._ To verify a signature $\mathsf{sig}=(R,u)$ of a message $m$ using
$\mathsf{pk}$, we first compute $c=H(m,R)$ and check whether the following
equality holds:

$\displaystyle R\stackrel{{\scriptstyle?}}{{=}}uG+c\mathsf{pk},$

If it equals, accept the signature, reject otherwise.

This scheme is existentially unforgeable under chosen-message attacks under
the discrete logarithm assumption, in the random oracle model [15, Section
12.5.1].

We are also interested in a double-key version of this signature scheme, that
will be used to delegate some computations later in the protocol. We have the
following algorithms:

  * •

_Setup._ Sample a secret key $\mathsf{sk}\leftarrow\mathbb{F}_{t}$ and compute
a public keypair
$(\mathsf{pk},\mathsf{pk}^{\prime})=(\mathsf{sk}G,\mathsf{sk}G^{\prime})$.

  * •

_Sign._ To sign a message $m$ using $\mathsf{sk}$, sample
$r\leftarrow\mathbb{F}_{t}$ and compute $(R,R^{\prime})=(rG,rG^{\prime})$.
Compute the challenge $c=H(m,R,R^{\prime})$, and also

$u=r-c\mathsf{sk}.$

Finally, set the signature $\mathsf{sig}=(R,R^{\prime},u)$.

  * •

_Verify._ To verify a signature $\mathsf{sig}=(R,R^{\prime},u)$ of a message
$m$ using $(\mathsf{pk},\mathsf{pk}^{\prime})$, we first compute
$c=H(m,R,R^{\prime})$ and check whether the following equalities hold:

$\displaystyle R\stackrel{{\scriptstyle?}}{{=}}uG+c\mathsf{pk},$
$\displaystyle
R^{\prime}\stackrel{{\scriptstyle?}}{{=}}uG^{\prime}+c\mathsf{pk}^{\prime}.$

If they are equal, accept the signature, reject otherwise.

###  2.5 Zero-Knowledge Proofs

A Zero-Knowledge Proof (ZKP) [6] is a cryptographic primitive allowing a
prover $\mathcal{P}$ to convince a verifier $\mathcal{V}$ that a public
statement is true, without leaking any secret information.

Given a statement $u$, and a witness $w$ being some secret information only
known by $\mathcal{P}$, $\mathcal{P}$ wants to convince $\mathcal{V}$ that
they know $w$. Both $u$ and $w$ are related by a set of operations defined by
a circuit, a graph composed of different wires and gates, which leads to a set
of equations involving the inputs and the outputs of these gates. Each of
these equations is called a constraint. $\mathcal{P}$ can execute a proving
algorithm using $u$ as the set of public inputs, and $w$ as the private
inputs. This execution outputs a set of elements, which we call the proof
$\pi$. $\mathcal{P}$ sends $\pi$ to $\mathcal{V}$, who will use a verifying
algorithm to verify that $u$ is true, for a given $w$ only known by
$\mathcal{P}$. In essence, ZKPs must satisfy 3 properties:

  * •

Completeness: If the statement is true, $\mathcal{P}$ must be able to convince
$\mathcal{V}$.

  * •

Soundness: If the statement is false, $\mathcal{P}$ must not be able to
convince $\mathcal{V}$ that the statement is true.

  * •

Zero-knowledge: $\mathcal{V}$ must not learn any information from the proof
beyond the fact that the statement is true.

First ZKP schemes used to achieve the aforesaid properties by exchanging
several messages between $\mathcal{P}$ and $\mathcal{V}$. However, non-
interactive ZKPs [16] arose, providing an extra feature, where $\mathcal{P}$
could prove statements to $\mathcal{V}$ by sending them a single message,
instead of several interactions.

Even so, computing and verifying ZKPs used to require high computing
resources, and this made them impractical in real applications. More recently,
Zero-Knowledge Succinct and Non-interactive ARguments of Knowledge (zk-SNARKs)
[17] appeared: ZKPs that can be computed and verified in a more efficient way,
compared to previous solutions, making them suitable for real applications,
like privacy-preserving cryptocurrencies [18].

###  2.6 zk-SNARKs

zk-SNARKs [19] are the most used ZKPs, because they are short and succinct:
the proofs can be verified in a few milliseconds. However, they require a
trusted setup where some public parameters are generated. These parameters,
called the Common Reference String (CRS) are used by $\mathcal{P}$ and
$\mathcal{V}$ to generate and verify proofs. To generate the CRS, a secret
randomness $\tau$ is used, and such randomness should be destroyed afterward.
If an attacker gets $\tau$, the soundness property of the scheme breaks: the
attacker would be able to compute false proofs that anyone could verify as if
they were correct. As such, the CRS is commonly computed using a secure Multi-
Party Computation (MPC) protocol [20], where $\tau$ can only be leaked if all
the participants are malicious. The computing complexity of generating a
setup, computing proofs, and verifying them, depends on the number of
operations that we do in the circuit, which is also the number of gates $n$.

###  2.7 Blockchain

A Blockchain [21] is a unique and immutable data structure called ledger, and
shared by a set of nodes. Cryptocurrencies like Bitcoin [8] use such
technology, and populate the ledger with transactions exchanging money between
parties. These transactions are cryptographically validated by the nodes of
the network, to be sure that each user spends what belongs to them. This
process is a consensus agreed upon among all the users of the network (e.g.
Proof of Work [22], Proof of Stake [23], etc.).

Beyond the feature of exchanging money, Blockchains like Ethereum [24] grant
the possibility of executing decentralized applications (DApps) on-chain.
DApps are possible thanks to smart contracts [25], programs that can be
executed on-chain thanks to the Ethereum Virtual Machine (EVM) [26]. Such
contracts and the EVM allow, for instance, to execute some action (like
issuing a payment) upon fulfilling some conditions.

Furthermore, other Blockchains like Dusk Network [27] also provide virtual
machines to execute smart contracts. In this particular case, Dusk has the
`Rusk` virtual machine, which like the EVM can execute smart contracts, but
with the difference that all the transactions handled by `Rusk` are private by
default, thanks to ZKPs.

From a more technical perspective, it is worth mentioning that, in order to
prevent saturation of the network, users are required to pay gas in order to
execute transactions. This is the amount of Duskies (Dusk’s coin) per amount
of bytes needed to execute a transaction. Depending on how busy the Dusk
Network is, the price of the gas increases or decreases. Like this, performing
a Denial-of-Service (DoS) attack becomes so expensive that is infeasible [28].

##  3 Phoenix Transaction Model

In this section, we introduce the details about
Phoenix555https://github.com/dusk-network/phoenix-core, the transaction model
used by Dusk Network.

###  3.1 Overview of Phoenix

Dusk Network is an open-source public blockchain with a UTXO-based
architecture that allows the execution of obfuscated transactions and
confidential smart contracts. In Phoenix, UTXOs are called notes, and the
network keeps track of all these notes by storing their hashes in the leaves
of a Merkle tree of notes. In other words, when a transaction is validated,
the network includes the hashes of the new notes to the leaves of this tree.

All transactions include a ZKP called tx_proof that proves that the
transaction has been performed following the network rules. Essentially, what
this ZKP does is the following: first, it nullifies a note that the user is
willing to spend. Second, proves that the user knows the value of a new note
to mint, that will be sent to the receiver. Finally, proves that the amount of
Dusk coins nullified is equal to the amount of coins created.

Greater details about the parameters included in the transaction have been
skipped here, for the sake of completeness. Nevertheless, the next subsections
explain how the protocol manages the notes nullification and minting, by
introducing first the different keys the users have to handle.

###  3.2 Protocol Keys

In Phoenix, we have different kinds of keys. First, we have the static keys
that belong to each user of the network, and we introduce them here as
follows. Let $G,G^{\prime}\leftarrow\mathbb{J}$ be two JubJub points acting as
our generators. We denote by $H^{\mathsf{Poseidon}}$ and
$H^{\mathsf{BLAKE2b}}$ the Poseidon and BLAKE2b hash functions, respectively.
Each user computes the following keys:

  * •

Secret key: $\mathsf{sk}=(a,b)$, where $a,b\leftarrow\mathbb{F}_{t}$.

  * •

Public key: $\mathsf{pk}=(A,B)$, where $A=aG$ and $B=bG$.

As noticed, Phoenix uses two-element keys, which allows users of the network
to delegate the process of scanning for the notes addressed to them.

On the other hand, each note is associated with a unique one-time key pair (an
approach introduced in [29]), instead of using the static public key of the
receiver, which hinders traceability.

The computation of these keys is based on the Diffie–Hellman key exchange
protocol [30]. The note public key of a note sent to a receiver with public
key pair $\mathsf{pk}=(A,B)$, and its associated note secret key, are computed
as follows:

  * •

Note public key: a sender willing to send money to a receiver whose public key
$\mathsf{pk}=(A,B)$ is known by them in advance, must first compute a note
public key $\mathsf{npk}$ following next steps.

    1. 1.

Sample $r$ uniformly at random from $\mathbb{F}_{t}$.

    2. 2.

Compute a symmetric Diffie–Hellman key $\mathsf{k_{DH}}=rA$.

    3. 3.

Compute a one-time public key
$\mathsf{npk}=H^{\mathsf{BLAKE2b}}(\mathsf{k_{DH}})G+B$.

    4. 4.

Compute $R=rG$.

The sender of a note will attach to it the note public key $\mathsf{npk}$ and
the partial Diffie–Hellman $R$ used to create $\mathsf{npk}$. Given a pair
$(\mathsf{npk},R$), the receiver can identify whether the note was sent to
them by recomputing $\mathsf{\tilde{k}_{DH}}=aR$ (using their secret $a$), and
checking the equation

$\mathsf{npk}\stackrel{{\scriptstyle?}}{{=}}H^{\mathsf{BLAKE2b}}(\mathsf{\tilde{k}_{DH}})G+B.$

  * •

Note secret key: the receiver can compute the note secret key
$\mathsf{nsk}=H^{\mathsf{BLAKE2b}}(\mathsf{k_{DH}})+b$, to be used when
willing to spend that note. This key can only be computed by the receiver of
the note since they are the only ones holding the whole secret key
$\mathsf{sk}=(a,b)$, and $\mathsf{sk}$ cannot be recovered from public
information. This is due to the discrete logarithm assumption in $\mathbb{J}$.

###  3.3 Protocol Details

A note is defined as the following set of elements:

$\mathsf{N}=\\{\mathsf{type},\mathsf{com},\mathsf{pos},\mathsf{nonce},\mathsf{enc},\mathsf{npk},R\\}.$

where $\mathsf{type}$ indicates the type of the note, either transparent or
obfuscated; $\mathsf{com}$ is a commitment to the value of the note;
$\mathsf{pos}$ is the position of the note in the Merkle tree of notes;
$\mathsf{nonce}$ is an initialization vector needed for the encryption scheme;
$\mathsf{enc}$ is an encryption of the opening of $\mathsf{com}$ that can be
decrypted using the receiver’s view key; $\mathsf{npk}$ is the note’s public
key, whose associated private key $\mathsf{nsk}$ can only be computed by the
receiver of the note; and $R$ is a point in the Jubjub subgroup $\mathbb{J}$
that allows the receiver to compute $\mathsf{nsk}$ and also identify that they
are the receiver of the transaction.

We describe Phoenix in the general scenario in which a sender wishes to send
different amounts of money $\mathsf{v_{1}},\dots,\mathsf{v_{n}}$ to different
receivers with public keys $\mathsf{pk_{1}},\dots,\mathsf{pk_{n}}$. We assume
the sender owns a set of notes
$\\{\mathsf{N^{old}_{1}},\dots,\mathsf{N^{old}_{m}}\\}$ each with an
associated amount $\mathsf{w_{i}}$ such that

$\sum_{i=1}^{m}\mathsf{w_{i}}\geq\sum_{i=1}^{n}\mathsf{v_{i}},$

i.e. the sender has enough funds.

When creating the transaction to transfer the funds, the sender will have to
nullify the set of old notes being spent and mint a new set of notes
$\\{\mathsf{N^{new}_{1}},\dots,\mathsf{N^{new}_{n}}\\}$ with the corresponding
values $\mathsf{v_{i}}$, and assigned to the corresponding receivers. The most
common case is $\mathsf{n}=2$, where a sender generates a note
$\mathsf{N^{new}_{1}}$ with value $\mathsf{v}$ for a receiver, and a second
note $\mathsf{N^{new}_{2}}$ for themselves with value
$\mathsf{change}=\mathsf{v}-\sum_{i=1}^{m}\mathsf{w_{i}}$.

To mint a new note for a receiver whose static public key is $\mathsf{pk}$, we
first compute the note public key $(\mathsf{npk},R)$ of the receiver as
described in Section 3.2. Next, we need to set the type of the transaction: if
the transaction is transparent, we set $\mathsf{type}=0$, and if the
transaction is obfuscated, we set $\mathsf{type}=1$. We also set $\mathsf{v}$
to the amount of money of the new note $\mathsf{N}{}$. Finally, we need to
commit to $\mathsf{v}$, and encrypt the opening as well. To do so, we first
set a blinding factor for the commitment and a nonce for the encryption:

  * •

If $\mathsf{type}=0$, set $s=0$ and $\mathsf{nonce}=0$.

  * •

If $\mathsf{type}=1$, set $s\leftarrow\mathbb{F}_{t}$ and
$\mathsf{nonce}\leftarrow\mathbb{F}_{t}$.

and compute the value commitment
$\mathsf{com}=\mathsf{Com}_{\mathsf{ck}}(v;s)$. Then, we encrypt the opening
of $\mathsf{com}$:

  * •

If $\mathsf{type}=0$, then set $\mathsf{enc}=\mathsf{v}$.

  * •

If $\mathsf{type}=1$, then
$\mathsf{enc}=\mathsf{Enc}_{\mathsf{k_{DH}}}(\mathsf{v}||s;\mathsf{nonce})$.

Now, we can set the new note to

$\mathsf{N}=\\{\mathsf{type},\mathsf{com},\mathsf{nonce},\mathsf{enc},\mathsf{npk},R\\}.$

The next step is to compute a ZKP using the circuit depicted in Figure 1 to
prove the following elements:

  * •

Membership: the sender must prove that every
$\mathsf{N}\in\\{\mathsf{N^{old}_{i}}\\}_{\mathsf{i}=1}^{\mathsf{m}}$ is
included in the Merkle tree of notes. To do so, the sender provides a Merkle
proof for $H^{\mathsf{Poseidon}}(\mathsf{N})$, and the circuit verifies the
Merkle proof in verify_merkle_proof(). We observe that all these inputs are
private and hence, the proof will not reveal which note is being spent, only
that it belongs to the Merkle tree of notes.

  * •

Ownership: the sender must prove that they hold the note secret key
$\mathsf{nsk}$ of every note
$\mathsf{N}\in\\{\mathsf{N^{old}_{i}}\\}_{\mathsf{i}=1}^{\mathsf{m}}$. Instead
of including their private key as an input to the circuit and computing
$\mathsf{npk}$ inside, the sender proves (using the verify_signature() box
inside the circuit) that they can sign a message with that key. In this case,
they use the double-key Schnorr signature scheme to sign the hash of the
transaction.

  * •

Nullification: the sender must prove that
$\mathsf{nullifier}=H^{\mathsf{Poseidon}}(\mathsf{npk}^{\prime}||\mathsf{pos})$.
Note that the sender provides the nullification key
$\mathsf{npk}^{\prime}=\mathsf{nsk}G^{\prime}$ as an input to the circuit and
not the note secret key $\mathsf{nsk}$. As we just explained, the double-key
Schnorr signature guarantees that $\mathsf{npk}^{\prime}$ is indeed
$\mathsf{nsk}G^{\prime}$. The result of the hash() box is the nullifier, which
is a public output of the circuit that is later included as part of the
transaction.

  * •

Balance integrity: the verify_balance() box checks that

$\sum_{i=1}^{m}\mathsf{w_{i}}-\sum_{i=1}^{n}\mathsf{v_{i}}-\mathsf{gas}=0,$
(1)

where $\mathsf{gas}$ is the maximum amount of gas that the sender is willing
to pay for the transaction.

Figure 1: Arithmetic circuit for a Dusk transaction proof.

Observe that using the double-key Schnorr signature as proof that the user
holds $\mathsf{nsk}$, allows users to delegate the generation of the ZKP to a
partially trusted third party, that is, a proof helper. This delegation would
require the user to entrust the old and new values of the notes to the proof
helper, but not their secret key.

Finally, the remaining checks not verified inside the circuit are performed by
the network. For instance, checking that the nullifier included in the
transaction matches the output of the circuit, or that the note has the right
typeset.

##  4 Our Solution: Citadel

In this section, we introduce `Citadel`. We start with an overview of the
protocol, its elements, and its use cases. Then, we introduce the main element
required by our solution: a private NFT model for Dusk. Finally, we detail our
novel SSI system, `Citadel`.

###  4.1 Overview

In this section, we describe a novel protocol for authenticating in several
services but preserving at the very same time our privacy. Imagine we want to
buy a ticket for a concert. Nowadays, what we would do in most cases is to buy
the ticket using a web page that will get information about our browser, our
credit card, our bank account, ourselves… Moreover, they will charge us a fee
for the ticket management service, and probably they will charge a fee to the
concert promotor as well. Furthermore, as soon as we show the ticket to the
concert, they will be able to link our image to the information previously
gathered.

Using `Citadel`, we can do much better. In particular, we want to buy a
license (a.k.a. a right) to use some service (e.g. the ticket of the example
above is a license, to be used in a concert, which is a service) without
leaking any information about us. Furthermore, we want to use such a service
as many times as permitted by the SP, without them being able to link our
activity, or learn our identity. Moreover, we want a decentralized system that
does not rely on third parties to manage our identities and licenses.

To achieve the aforesaid features, we first rely on Dusk Network as the
decentralized framework that our solution is based. Then, we need a way to
privately share assets among users of the Dusk Network. For this reason, in
Section 4.2 we design a novel and private NFT model for Dusk. Finally, we need
a way to anonymously prove ownership of our acquired licenses (i.e. the NFTs),
so we introduce our solution in Section 4.3.

###  4.2 A Private NFT Model for Dusk

As described in Section 3, coins in Dusk are represented as notes, and they
can be either transparent note ($\mathsf{type}=0$), or obfuscated note
($\mathsf{type}=1$). Here we introduce two new types of notes: transparent NFT
note ($\mathsf{type}=2$) and obfuscated NFT note ($\mathsf{type}=3$).

As stated previously, a user willing to spend Dusk notes needs to mint new
notes while nullifying the old ones. Like this, a user can spend one note, and
create a new note for the receiver, and another one with the change for
themselves. When willing to mint a new NFT, a user will need to execute the
minting contract where a Dusk note will be used to pay for the contract gas
(and thus, it will be nullified), and a new note will be created to receive
the change. Additionally, a new NFT note will be created. The creation of an
NFT note does not need to be part of the ZKP circuit, as it is not involved in
the balance to be verified. As such, it is enough to include the new NFT note
in the transaction. A note representing an NFT contains the same data as other
notes do, but in this case, what before was the note value in Dusk coins $v$,
now is the $\mathsf{payload_{NFT}}$ of the NFT. To mint a new note, we first
compute the note public key $\mathsf{npk}$ and the value $R$ of the receiver
as described in Section 3.2, plus the symmetric key $\mathsf{k_{DH}}$. Then,
we set the parameters of each new NFT note $\mathsf{N}$ by executing a
function

$\mathsf{mint\\_nft}(\mathsf{npk},R,\mathsf{payload_{NFT}},\mathsf{k_{DH}})$

whose workflow is described in Algorithm 1.

Inputs:

$(\mathsf{npk},R)$: the public note key of the receiver $\mathsf{npk}$ and the
related value $R$.

$\mathsf{payload_{NFT}}$: a value being the desired content of our NFT note
$\mathsf{N}{}$.

$\mathsf{k}$: a symmetric encryption key.

Algorithm:

  1. 1.

Set the type of note.

     * •

If the NFT note is transparent, set $\mathsf{type}=2$.

     * •

If the NFT note is obfuscated, set $\mathsf{type}=3$.

  2. 2.

Set a nonce for the encryption.

     * •

If $\mathsf{type}=2$, set $\mathsf{nonce}=0$.

     * •

If $\mathsf{type}=3$, set $\mathsf{nonce}\leftarrow\mathbb{F}_{t}$.

  3. 3.

Encrypt the $\mathsf{payload_{NFT}}$.

     * •

If $\mathsf{type}=2$, then set $\mathsf{enc}=\mathsf{payload_{NFT}}$.

     * •

If $\mathsf{type}=3$, then
$\mathsf{enc}=\mathsf{Enc}_{\mathsf{k}}(\mathsf{payload_{NFT}};\mathsf{nonce})$,
where $\mathsf{Enc}()$ is a symmetric encryption function.

  4. 4.

Set the new NFT note to

$\mathsf{N}=\\{\mathsf{type},\mathsf{enc},\mathsf{nonce},R,\mathsf{npk}\\}.$

Algorithm 1 Minting algorithm for private NFTs.

As described previously, users willing to spend notes have to nullify them, a
process that involves providing a ZKP whose circuit computes the hash of the
note. In this process, the parameter $\mathsf{type}$ is set to private, as it
is not relevant information for the protocol. It is of paramount importance to
notice that after deploying this model, this parameter has to be public.
Otherwise, an adversary could spend an NFT note pretending to be spending a
regular note and would be able to create huge amounts of money out of the
blue.

On the other hand, and as described in this section, the changes in the whole
protocol are minimal. As such, deploying our model to the current system
should be trivial.

###  4.3 Description of Citadel

Now, we are going the introduce all the details about `Citadel`. Then, we will
detail its security analysis, and finally, we will perform some experiments in
order to get benchmarks of the protocol.

####  4.3.1 Protocol Details

Let us have a user willing to pay a service provider SP for a license to use
their service, and willing to anonymously prove ownership of this license
afterward. First, the user will execute a payment in the Dusk Network
addressed to the SP, including into the transaction the required information
to receive the license. Upon receiving the payment, the SP will send back a
license to the user, using the same Blockchain. In order to use the license,
the user will have to call a smart contract deployed in the Dusk Network,
called the license contract. Essentially, the user will provide a proof that
demonstrates that they own a valid license, the license contract will verify
the proof, and will append a license nullifier to a Merkle tree of nullifiers.
By means of a session cookie included in the same contract call, and addressed
to the SP, the user will be able to request the service using an off-chain and
secure channel. The workflow is depicted in Figure 2, and described with full
details in the following protocol.

Protocol 1 Citadel.
---
Environment: A Service Provider SP offering a service, and publicly sharing
its public key $\mathsf{pk}_{\mathsf{SP}}$.
A user willing to use a service provided by the SP.
The Dusk Network Blockchain.
Protocol: 1. (user) $\mathsf{send\\_note\\_license\\_req}$ : Compute a note
public key $(\mathsf{npk}_{\mathsf{user}},R_{\mathsf{user}})$ belonging to the
user, using the user’s own public key, and also an additional key
$\mathsf{k}_{\mathsf{user}}=H^{\mathsf{Poseidon}}(\mathsf{npk}_{\mathsf{user}},\mathsf{nsk}_{\mathsf{user}})$,
by computing first the user’s $\mathsf{nsk}_{\mathsf{user}}$. Then, send the
required amount of Dusk coins to the SP, in order to pay for the service. Into
the same transaction, send an NFT to the SP using the function
$\mathsf{mint\\_nft}(\mathsf{npk}_{\mathsf{SP}},R_{\mathsf{SP}},\mathsf{payload_{NFT}},\mathsf{k_{DH}})$,
whose arguments are computed as follows: •
$(\mathsf{npk}_{\mathsf{SP}},R_{\mathsf{SP}})$ is the SP’s note public key,
computed through his public key $\mathsf{pk}_{\mathsf{SP}}$. •
$\mathsf{payload_{NFT}}=(\mathsf{npk}_{\mathsf{user}},R_{\mathsf{user}},\mathsf{k}_{\mathsf{user}})$.
• $\mathsf{k_{DH}}$ is computed using the SP’s public key. 2. (SP)
$\mathsf{get\\_note\\_license\\_req}$ : Continuously check the network for
incoming license requests. Upon receiving the payment from a user, define a
set of attributes $attr$ representing the license, and compute a digital
signature as follows: sig_lic= sign_single_key_sk_SP(npk_user, attr) 3. (SP)
$\mathsf{send\\_note\\_license}$ : Set the
$\mathsf{payload_{NFT}}=\\{\mathsf{sig_{lic}},\mathsf{attr}\\}$, and send the
license to the user using the function
$\mathsf{mint\\_nft}(\mathsf{npk}_{\mathsf{user}},R_{\mathsf{user}},\mathsf{payload_{NFT}},\mathsf{k}_{\mathsf{user}})$.
4. (user) $\mathsf{get\\_note\\_license}$ : Receive the note containing the
license. 5. (user) $\mathsf{call\\_nullify\\_license}$ : When desiring to use
the license, nullify it by executing a call to the license contract. The
following steps are performed: • The user sets a session cookie
$\mathsf{sc}=(\mathsf{s_{0}},\mathsf{s_{1}},\mathsf{s_{2}})\leftarrow\mathbb{F}_{t}$.
• The user creates a new NFT note where $\mathsf{payload_{NFT}}=\mathsf{sc}$,
and the SP is the receiver. • The user issues the transaction that includes
the NFT described in the previous step, by calling the license contract. In
this case, the tx_proof is computed as done in the standard Phoenix model, but
into the same circuit, the circuit depicted in Figure 3 is appended. • The
network validators will execute the smart contract, which verifies the proof.
Upon success, the NFT note will be forwarded, and the license nullifier
$\mathsf{nullifier_{lic}}$ will be added to the Merkle tree of nullifiers. 6.
(SP) $\mathsf{get\\_note\\_session\\_cookie}$ : Receive a note containing the
session cookie $\mathsf{sc}$. 7. (user) $\mathsf{req\\_service}$ : Request the
service to the SP, establishing communication using a secure channel, and
providing the tuple
$(\mathsf{tx\\_hash},\mathsf{pk}_{\mathsf{SP}},\mathsf{attr},c,\mathsf{sc})$.
8. (SP) $\mathsf{grant\\_service}$ : Grant or deny the service upon
verification of the following steps: • Check whether or not the values
$(\mathsf{attr},\mathsf{pk}_{\mathsf{SP}},c)$ are correct. • Check whether or
not the openings
$((\mathsf{pk}_{\mathsf{SP}},\mathsf{s_{0}}),(\mathsf{attr},\mathsf{s_{1}}),(c,\mathsf{s_{2}}))$
match the commitments
$\mathsf{com}_{0}^{hash},\mathsf{com}_{1},\mathsf{com}_{2}$ found in the
transaction $\mathsf{tx\\_hash}$.

Figure 2: Overview of the protocol messages exchanged between the user, the
Dusk Network, and the SP.

Figure 3: Arithmetic circuit for proving a license’s ownership.

As can be seen, the fact that only the user knows the $\mathsf{nsk}$ required
to compute $\mathsf{sig_{lic}}$ allows them to prove ownership of the license,
by means of the double key Schnorr signature, and this license is verified by
proving knowledge of a valid signature verified with the public key of the SP.

Moreover, we can appreciate in the circuit how the license is linked to the
$\mathsf{npk}_{\mathsf{user}}$, and the user also verifies a Merkle proof that
proves membership of this note in the Dusk Network. This brings the revocation
feature: if under some circumstances the SP no longer accepts some previously
issued licenses, they can prove to the network that a given note contains a
license issued by them, and under a consensus agreement, it will be removed.
As such, after removal, the user will not be able to provide valid proofs for
this license anymore. Plus, it can happen that a user receives a license, but
the transaction is finally not accepted in the Blockchain (e.g. the
transaction proof was not correct, some regulation checks have failed, etc.).
In this scenario, the received license will not be valid, and the user indeed
will not be able to provide a correct Merkle proof.

Furthermore, the SP might request the user to nullify the license they are
using (i.e. this is a single-use license, like entering a concert). This is
done through the computation of $\mathsf{nullifier_{lic}}$. The deployment of
this part of the circuit has two different possibilities:

  * •

If we set $c=0$ (or directly remove this input from the circuit), the license
will be able to be used only once.

  * •

If the SP requests the user to set a custom value for $c$ (e.g. the date of an
event), the license will be able to be reused only under certain conditions.

It is also interesting to notice that the whole protocol has been designed
with perfect integration into Dusk Network. As can be noticed, all the
information needed to prove ownership of a license is stored on-chain. As
such, a user setting up a new instance of the Dusk wallet will be able to
retrieve all the licenses by simply knowing his static secret key, as would be
done with the whole Dusk protocol. The same happens with the delegation of the
received notes check, where the user delegates the process of checking which
notes are addressed to them. In `Citadel`, the user can securely delegate the
check of received licenses. Furthermore, proof delegation is also possible, as
the user knowing $\mathsf{nsk}$ will use this key to sign a specific
transaction, and this cannot be modified.

####  4.3.2 Security Analysis

We start the security analysis of `Citadel` by elaborating on the ZKP scheme
to use. The need for a trusted setup is one of the main drawbacks of some ZKP
constructions like PlonK, especially when used in scenarios like
cryptocurrencies. An untrusty setup where an adversary gets the seed used to
compute it would allow them to create false transactions, and this would lead
to huge losses of money. In `Citadel`, an untrusted setup would lead to user
impersonation, and being able to use others’ licenses.

On the other hand, the soundness property of each scheme relies on different
security assumptions [31] (e.g. the specific zk-SNARK described in [32] uses a
strong assumption, the q-Power Knowledge of Exponent ($q$-PKE) assumption). In
other words, the security of these schemes relies on the security of elliptic
curves, where breaking the security of the selected curve would lead to being
able to generate false proofs. In our scenario, the BLS12-381 [18] is used. It
is estimated to have around 128 bits of security, which complies with the
security standards.

We now put the spotlight on the security of the circuit we have designed,
which grants the following features:

  * •

Proof of Ownership: the circuit used in `Citadel` verifies a signature
$\mathsf{sig_{lic}}$ of an input message
$(\mathsf{npk}_{\mathsf{user}},\mathsf{attr})$, using the public key of SP,
$\mathsf{pk}_{\mathsf{SP}}$. Also, a double key signature $\mathsf{sig_{tx}}$
of a transaction hash $\mathsf{tx\\_hash}$ is verified in-circuit, referring
to the transaction where the ZKP will be appended.

$\mathsf{sig_{lic}}$ verification ensures that the license attributes are
correct, and $\mathsf{sig_{tx}}$ ensures that the user owns such a license, as
only they can compute $\mathsf{npk}_{\mathsf{user}}$ using the note secret key
and compute such a signature, while keeping all these values private, so SP
cannot learn the identity of the user. An adversary would not be able to prove
ownership as long as $\mathsf{nsk}_{\mathsf{user}}$ is not leaked to them.
This is true under the discrete logarithm assumption.

  * •

Proof of Validity: the fact that $\mathsf{npk}_{\mathsf{user}}$ is part of the
signature $\mathsf{sig_{lic}}$, ensures that the license is assigned to a
specific note of the Dusk Network, and thus, a specific user of this
blockchain. The circuit verifies a Merkle proof of the NFT note containing the
license, which is included in the Merkle tree of notes. This ensures that the
license the user is proving ownership of has been transacted in the Dusk
Network, and is a valid license at the moment of issuing the transaction.

An adversary willing to successfully prove ownership of a transferred license
would have to craft a new pair $(\mathsf{npk}_{\mathsf{user}},$attr$)$ that
verifies $\mathsf{sig_{lic}}$. This is infeasible under the discrete logarithm
assumption. Furthermore, the crafted $\mathsf{npk}_{\mathsf{user}}$ would have
to be a collision verifying the Merkle proof.

  * •

Unlinkability: the user sends the one-time key pair
$(\mathsf{npk}_{\mathsf{user}},R_{\mathsf{user}})$ to the SP, instead of the
public key $\mathsf{pk}$. The fact that the information about the user learned
by the SP is a set of one-time values ensures that the identity of the user
sending these values cannot be linked to other activities done in the network.
The key $\mathsf{npk}_{\mathsf{user}}$ is computed from the value
$\mathsf{nsk}_{\mathsf{user}}$, which is kept secret and used only one time.
As there are no other values involved in the process that identifies the user,
they cannot be linked to the user’s identity. This is true as long as the user
does not reuse $\mathsf{nsk}_{\mathsf{user}}$. On the other hand,
$\mathsf{npk}_{\mathsf{user}}=H^{\mathsf{BLAKE2b}}(rA)G+B$, where $r$ is
sampled at random and $(A,B)$ is the user’s public key. As both
$H^{\mathsf{BLAKE2b}}(rA)G$ and $B$ are only known by the user, there is no
way an adversary can learn $B$, because $\mathsf{npk}_{\mathsf{user}}$ can be
decomposed in many ways.

From the point of view of the network, there is unlinkability as well: when
issuing the transaction, no one is able to link the nullified license to the
SP, as the $\mathsf{pk}_{\mathsf{SP}}$ is blinded by committing to this value
using the hash() function and a random value $\mathsf{s_{0}}$. An adversary
would not be able to learn $\mathsf{pk}_{\mathsf{SP}}$ as long as the
randomness involved in the hashing process is not leaked to them. This is true
assuming that the hashing function is collision-resistant. On the other hand,
both $\mathsf{attr}$ and $c$ could leak information about the service and the
user. For this reason, we commit to these values (as they are scalars instead
of points, we can use the Pedersen Commitment which requires fewer constraints
than the hash function). An adversary would not be able to learn
$(\mathsf{attr},c)$ as long as the random values involved in the commitments
are not leaked to them. This is true under the discrete logarithm assumption,
which holds for the Pedersen commitment.

  * •

Decentralized Nullification: the circuit computes the hash of
$\mathsf{npk}_{\mathsf{user}}$ and a public challenge $c$, resulting in
$\mathsf{nullifier_{lic}}$. The format of the $c$ value could change in
different scenarios. Taking the example of proving ownership of a ticket for
an event, ideally, $c$ would be the date of such an event. If a function
checking if a given nullifier has been previously seen, results in the
equation
$\mathsf{is\\_seen}(\mathsf{nullifier_{lic}},\mathsf{previous\\_nullifiers}[])\stackrel{{\scriptstyle?}}{{=}}1$
holding, it means that someone already entered the event with the same
license. As such, we ensure that a user cannot use the same license multiple
times, nor compute valid proofs for other users.
$\mathsf{npk}_{\mathsf{user}}$ is fixed in advance, as such,
$\mathsf{nullifier_{lic}}$ will always be the same for a given public input
$c$, which needs to be validated by the SP.

  * •

Attribute Blinding: As described previously, the user provides an opening for
the commitment $\mathsf{com}_{1}$ to the SP, thus leaking the $\mathsf{attr}$
value. An adversary would not be able to provide a valid opening as long as
the randomness involved in the commitment of $\mathsf{attr}$ is not leaked to
them. This is true under the discrete logarithm assumption, which holds for
the Pedersen commitment.

Depending on the use case, it could be desirable that the values involved in
$\mathsf{attr}$ are kept totally or partially private. In this scenario, and
as suggested in the `FORT` protocol, the user could instead provide an
additional proof of knowledge, proving to the SP that they know the opening of
$\mathsf{com}_{1}$. As an example, a Bulletproof is a kind of ZKP allowing to
prove knowledge of a value that lies within a certain range.

####  4.3.3 Benchmarks

We use `dusk-plonk` to code the circuit used in our solution. Like this, we
get the number of constraints of its different elements and thus, the
efficiency of computing (and verifying) proofs. Our circuit needs four main
functions:

  * •

hash(): we use the Poseidon hash function, which uses 977 contraints when
hashing 1 input. The amount of constraints increases depending on the number
of inputs.

  * •

commit(): the Pedersen commitment requires 527 constraints.

  * •

verify_sig_single_key(): Dusk uses the Schnorr proof signature scheme over
BLS12-381, which uses 3388 constraints when using the single key version.

  * •

verify_sig_double_key(): Dusk uses the Schnorr proof signature scheme over
BLS12-381, which uses 6645 constraints when using the double key version.

  * •

verify_merkle_proof(): the circuit needs to verify a Merkle proof. Dusk uses
Merkle trees of depth 17, as such, our solution will need to compute 17
Poseidon hashes. This sums up to 17807 constraints.

We implemented our circuit using a total amount of 34861 constraints. Here, we
need to add the constraints needed to compute the default tx_proof, which are
31486 constraints for nullifying one note. We benchmarked both the prover and
verifier using an Apple Silicon M1 CPU. The prover takes 16.232 seconds to
compute the proof, and the verifier 0.007 seconds to verify it.

Plus, it has to be taken into account that an advantage of `Citadel` is that
licenses can be nullified much before being used. This means that long ZKP
proving times will not have a big impact on the performance of the protocol
even when using devices with low computing resources. Nonetheless, and as
mentioned previously, computations can be delegated as done in the standard
Phoenix model, so high-performing CPUs will compute the proofs even in less
time.

##  5 Conclusions and Future Work

In this paper, we have introduced two main contributions. We have described a
private-by-design NFT model for the Dusk Network Blockchain. This allows
issuing of unique assets in the network, that remain private to anyone but the
receiver. We also showed how this approach perfectly integrates into the
current transaction model of Dusk.

Then, we introduced `Citadel`, which uses the NFT model to issue licenses to
users, whose ownership can be privately demonstrated afterward. Among all the
features described in the protocol details, we demonstrated how the main
problems in previous solutions are solved: licenses cannot be traced on-chain,
and their usage can be nullified in a decentralized manner by means of the
Blockchain itself. As such, our solution serves the privacy concerns of the
users, while the SPs have the guarantee that the licenses they issue will not
be misused (e.g. used more times than what is permitted). After detailing the
security behind our protocol, we provided a proof-of-concept implementation of
the proving system, along with some benchmarks and deployment specifications
that prove its feasibility in a real scenario.

Beyond all the use cases and examples described in this work, our solution can
also be seen as a framework to be adapted and modified according to the needs
that specific applications can have. Working in more specific applications and
being able to deploy `Citadel` in real scenarios would be interesting future
work.

## Acknowledgements

This work has been funded by Dusk Network. We also want to thank Marta Bellés
and Javier Silva from Dusk Network for their insightful comments on this work.

## References

  * [1] Sovrin Foundation.  Sovrin: A Protocol and Token for Self-Sovereign Identity and Decentralized Trust.  https://sovrin.org/wp-content/uploads/Sovrin-Protocol-and-Token-White-Paper.pdf, January 2018.
  * [2] Alexander Mühle, Andreas Grüner, Tatiana Gayvoronskaya, and Christoph Meinel.  A survey on essential components of a self-sovereign identity.  Computer Science Review, 30:80–86, Nov 2018.
  * [3] Marta Bellés-Muñoz and Vanesa Daza.  Self-Sovereign Identity, pages 1–3.  Springer Berlin Heidelberg, Berlin, Heidelberg, 2019.
  * [4] Quinten Stokkink, Dick H. J. Epema, and Johan Pouwelse.  A truly self-sovereign identity system.  CoRR, abs/2007.00415, 2020.
  * [5] Amal Abid, Saoussen Cheikhrouhou, Slim Kallel, and Mohamed Jmaiel.  Novidchain: Blockchain-based privacy-preserving platform for covid-19 test/vaccine certificates.  Software: Practice and Experience, 52(4):841–867, 2022.
  * [6] S Goldwasser, S Micali, and C Rackoff.  The knowledge complexity of interactive proof-systems.  In Proceedings of the Seventeenth Annual ACM Symposium on Theory of Computing, STOC ’85, pages 291–304, New York, NY, USA, 1985. ACM.
  * [7] Xavier Salleras and Vanesa Daza.  Sans: Self-sovereign authentication for network slices.  Security and Communication Networks, 2020, 2020.
  * [8] Satoshi Nakamoto.  Bitcoin: A peer-to-peer electronic cash system, 2008.  https://bitcoin.org/bitcoin.pdf, Accessed on 06/02/2022.
  * [9] Xavier Salleras, Sergi Rovira, and Vanesa Daza.  Fort: Right-proving and attribute-blinding self-sovereign authentication.  Mathematics, 10(4), 2022.
  * [10] Sean Bowe and Jack Grigg.  Implementation of the BLS12-381 pairing-friendly elliptic curve construction.  Available online: https://github.com/zkcrypto/bls12_381 (accessed on 1 June 2022).
  * [11] Sean Bowe, Eirik Ogilvie-Wigley, , and Jack Grigg.  Implementation of the Jubjub elliptic curve group.  Available online: https://github.com/zkcrypto/jubjub (accessed on 1 June 2022).
  * [12] J. P. Aumasson, Samuel Neves, Zooko Wilcox-O’Hearn, and Christian Winnerlein.  BLAKE2: simpler, smaller, fast as MD5.  https://blake2.net/, January 2013.
  * [13] Lorenzo Grassi, Dmitry Khovratovich, Christian Rechberger, Arnab Roy, and Markus Schofnegger.  Starkad and poseidon: New hash functions for zero knowledge proof systems.  Cryptology ePrint Archive, Report 2019/458, 2019.  https://eprint.iacr.org/2019/458.
  * [14] Ralph C Merkle.  A digital signature based on a conventional encryption function.  In Conference on the theory and application of cryptographic techniques, pages 369–378. Springer, 1987.
  * [15] Jonathan Katz and Yehuda Lindell.  Introduction to modern cryptography.  CRC press, 2020.
  * [16] Manuel Blum, Paul Feldman, and Silvio Micali.  Non-interactive zero-knowledge and its applications.  In Proceedings of the Twentieth Annual ACM Symposium on Theory of Computing, STOC ’88, pages 103–112, New York, NY, USA, 1988. ACM.
  * [17] Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza.  Succinct non-interactive zero knowledge for a von neumann architecture.  Cryptology ePrint Archive, Report 2013/879, 2013.  https://eprint.iacr.org/2013/879.
  * [18] Daira Hopwood, Sean Bowe, Taylor Hornby, and Nathan Wilcox.  Zcash Protocol Specification - Version 2019.0.2, 2019.  https://github.com/zcash/zips/blob/master/protocol/protocol.pdf, Accessed on 28/09/2021.
  * [19] Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza.  Succinct non-interactive zero knowledge for a von neumann architecture.  In 23rd USENIX Security Symposium (USENIX Security 14), pages 781–796, San Diego, CA, August 2014. USENIX Association.
  * [20] Sean Bowe, Ariel Gabizon, and Ian Miers.  Scalable Multi-party Computation for zk-SNARK Parameters in the Random Beacon Model.  Cryptology ePrint Archive, Report 2017/1050, 2017.  https://eprint.iacr.org/2017/1050, Accessed on 28/09/2021.
  * [21] Stephan Leible, Steffen Schlager, Moritz Schubotz, and Bela Gipp.  A review on blockchain technology and blockchain projects fostering open science.  Frontiers in Blockchain, 2:16, 2019.
  * [22] Arthur Gervais, Ghassan O Karame, Karl Wüst, Vasileios Glykantzis, Hubert Ritzdorf, and Srdjan Capkun.  On the security and performance of proof of work blockchains.  In Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, pages 3–16, 2016.
  * [23] Iddo Bentov, Charles Lee, Alex Mizrahi, and Meni Rosenfeld.  Proof of activity: Extending bitcoin’s proof of work via proof of stake [extended abstract] y.  ACM SIGMETRICS Performance Evaluation Review, 42(3):34–37, 2014\.
  * [24] Gavin Wood.  Ethereum: A secure decentralised generalised transaction ledger (istanbul version), June 2021.
  * [25] Anastasia Mavridou and Aron Laszka.  Designing secure ethereum smart contracts: A finite state machine based approach.  In International Conference on Financial Cryptography and Data Security, pages 523–540. Springer, 2018.
  * [26] Everett Hildenbrandt, Manasvi Saxena, Nishant Rodrigues, Xiaoran Zhu, Philip Daian, Dwight Guth, Brandon Moore, Daejun Park, Yi Zhang, Andrei Stefanescu, et al.  Kevm: A complete formal semantics of the ethereum virtual machine.  In 2018 IEEE 31st Computer Security Foundations Symposium (CSF), pages 204–217. IEEE, 2018.
  * [27] Toghrul Maharramov, Dmitry Khovratovich, and Emanuele Francioni.  The dusk network whitepaper, 2021.  https://dusk.network/uploads/The_Dusk_Network_Whitepaper_v3_0_0.pdf, Accessed on 04/02/2022.
  * [28] Ting Chen, Xiaoqi Li, Y. Wang, Jiachi Chen, Zihao Li, Xiapu Luo, Man Ho Allen Au, and Xiaosong Zhang.  An adaptive gas cost mechanism for ethereum to defend against under-priced dos attacks.  ArXiv, abs/1712.06438, 2017.
  * [29] Nicolas Van Saberhagen.  Cryptonote v 2.0.  2013\.
  * [30] Whitfield Diffie and Martin Hellman.  New directions in cryptography.  IEEE Transactions on Information Theory, 22(6):644–654, 1976.
  * [31] Shafi Goldwasser and Yael Tauman Kalai.  Cryptographic assumptions: A position paper.  In Eyal Kushilevitz and Tal Malkin, editors, Theory of Cryptography, pages 505–522, Berlin, Heidelberg, 2016. Springer Berlin Heidelberg.
  * [32] Jens Groth.  On the size of pairing-based non-interactive arguments.  Cryptology ePrint Archive, Report 2016/260, 2016.  https://eprint.iacr.org/2016/260.