exchange/doc/cbdc-it/cbdc-it.tex

% The Spanish pdf looks too crowded. For Italian, maybe bigger font 
% and/or extra space between lines/paragraphs?

%\renewcommand{\abstractname}{Sommario}
%\renewcommand{\refname}{Riferimenti bibliografici}

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage{url}
\usepackage{amsmath}
\usepackage{hyperref}
\usepackage{graphicx}
\usepackage{natbib}
\usepackage[italian]{babel}
\title{Come emettere una moneta digitale di banca centrale}
\author{David Chaum\footnote{david@chaum.com} \\
  xx Network \and
  Christian Grothoff\footnote{christian.grothoff@bfh.ch} \\
  BFH\footnote{Università di Scienze Applicate di Berna}
  \quad e Progetto GNU \and
  Thomas Moser\footnote{thomas.moser@snb.ch} \\
  Banca Nazionale Svizzera}
\date{Questa versione: febbraio 2022 \\
      Prima versione:  maggio 2020}

\begin{document}

\maketitle

\begin{abstract} 
Con l'emergere di Bitcoin e delle criptovalute stabili (per es. Diem, 
già nota come Libra) recentemente proposte dai colossi del web, le 
banche centrali affrontano una crescente concorrenza da parte di 
operatori privati che offrono la propria alternativa digitale al 
contante fisico. Non trattiamo qui la questione normativa se una banca 
centrale debba emettere o meno una moneta digitale. Contribuiamo invece 
all'attuale dibattito di ricerca spiegando in che modo una banca centrale 
potrebbe farlo, se lo volesse. Proponiamo un sistema basato su token 
senza tecnologia di registro distribuito, e mostriamo che le monete  
elettroniche emesse in passato, basate solo su software, possono essere 
migliorate per tutelare la privacy nelle transazioni, soddisfare i 
requisiti normativi in modo efficace e offrire un livello di protezione 
resistente ai computer quantistici contro il rischio sistemico per 
la privacy. Né la politica monetaria né la stabilità del sistema 
finanziario sarebbero realmente interessate da questo sistema dal 
momento che una CBDC emessa in questo modo replicherebbe il contante 
fisico anziché i depositi bancari. \\

JEL: E42, E51, E52, E58, G2
\\

Parole chiave: monete digitali, banca centrale, CBDC, firma cieca, 
criptovalute stabili, \textit{stablecoins}
\end{abstract}

\vspace{40pt}

\section*{Ringraziamenti}
Vorremmo ringraziare Michael Barczay, Roman Baumann, Morten Bech, 
Nicolas Cuche, Florian Dold, Andreas Fuster, Stefan Kügel, Benjamin 
Müller, Dirk Niepelt, Oliver Sigrist, Richard Stallman, Andreas Wehrli 
e tre collaboratori anonimi per i loro commenti e suggerimenti. Le 
posizioni, le opinioni, i risultati e le conclusioni o raccomandazioni 
espresse in questo documento sono strettamente quelle degli autori. 
Non riflettono necessariamente le posizioni della Banca nazionale 
svizzera (BNS). La BNS declina ogni responsabilità per eventuali 
errori, omissioni o inesattezze che dovessero comparire nel documento.

Traduzione: Dora Scilipoti \& Luca Saiu
\newpage

%\tableofcontents

\section{Introduzione}\label{1.-introduzione}

Dall'avvento dei personal computer negli anni ottanta, e più 
specificamente da quando nel 1991 la \textit{National Science 
Foundation} revocò le restrizioni sull'uso di Internet per scopi 
commerciali, c'è stata una ricerca sulla creazione di moneta digitale 
per i pagamenti online. La prima proposta è stata quella 
di~\cite{Chaum1983}. Sebbene tali metodi siano stati attuati, non hanno 
preso piede; le carte di credito sono invece diventate il metodo più 
diffuso per i pagamenti online. La proposta di~\cite{Nakamoto} per una 
versione puramente \textit{peer-to-peer} di moneta digitale e il 
conseguente lancio di Bitcoin avvenuto con successo hanno inaugurato 
una nuova era di ricerca e sviluppo di valute digitali. La piattaforma 
CoinMarketCap elenca oltre 5.000 criptovalute. Recentemente le banche 
centrali hanno iniziato a considerare, o almeno a studiare, 
l'emissione di monete 
digitali~\cite[vedi][]{AuerBoehme,AuerCornelli,Boar,Kiff,Mancini-Griffoli}.

Attualmente le banche centrali emettono due tipi di moneta: (i) 
riserve sotto forma di conti di regolamento presso le banche centrali, 
destinate solo agli operatori dei mercati finanziari, e (ii) divisa 
disponibile per tutti sotto forma di banconote. Di conseguenza, la 
letteratura sulla moneta digitale di banca centrale (\textit{Central Bank 
Digital Currency} - CBDC) distingue tra (a) CBDC all'ingrosso ad 
accesso ristretto e (b) CBDC al dettaglio disponibile per il 
pubblico~\cite[si veda, ad esempio,][]{Bech}. 
Una CBDC all'ingrosso sarebbe meno destabilizzante per il sistema attuale 
dato che le banche e gli operatori dei mercati finanziari hanno già 
accesso alla moneta digitale della banca centrale sotto forma di conti 
presso questa istituzione, che utilizzano per regolare i pagamenti 
interbancari. La domanda qui è se la tokenizzazione della moneta di banca 
centrale e la tecnologia di registro distribuito (\textit{Distributed Ledger 
Technology} - DLT) offrano vantaggi particolari rispetto ai sistemi con 
regolamento lordo in tempo reale (\textit{Real-Time Gross Settlement} - RTGS) 
esistenti. Finora la risposta è negativa, almeno per i pagamenti 
interbancari nazionali~\cite[vedi][]{Chapman}.

Una CBDC al dettaglio, che sarebbe una nuova forma di moneta di banca 
centrale disponibile per il pubblico, potrebbe essere più destabilizzante 
per il sistema attuale, a seconda di come è progettata. Più una CBDC 
compete con i depositi delle banche commerciali, maggiore è la minaccia 
ai finanziamenti bancari, con effetti potenzialmente negativi sul credito 
bancario e sull'attività economica~\cite[vedi][]{Agur}. Tuttavia, una 
CBDC al dettaglio potrebbe anche essere vantaggiosa~\cite[vedi][]{Bordo,Berentsen,Bindseil,Niepelt,Riksbank,BoE}. 
Mettere a disposizione di tutti una moneta elettronica di banca centrale 
esente dal rischio di controparte potrebbe migliorare la stabilità e la 
resilienza del sistema di pagamenti al dettaglio. Potrebbe inoltre fornire 
un'infrastruttura di pagamento neutrale per incoraggiare la concorrenza, 
l'efficienza e l'innovazione. Nel complesso, è probabile che i costi e i 
benefici di una CBDC al dettaglio differiscano da un paese all'altro. Per 
il punto di vista della Banca nazionale svizzera, che non ha in programma 
l'emissione di una CBDC al dettaglio, si veda~\cite{Jordan}.

Nel presente documento analizziamo la CBDC al dettaglio, ma senza 
affrontare la questione se una banca centrale \emph{debba o meno} emetterla. 
Ci concentriamo invece sul possibile design di una CBCD. L'interesse 
per la progettazione di CBDC è recentemente aumentato 
considerevolmente~\cite[si, veda ad esempio,][]{Allen,BoE}. Il design che 
proponiamo differisce notevolmente da altre proposte. Il nostro sistema 
si basa sulla tecnologia eCash descritta da~\cite{Chaum1983,Chaum1990}, 
migliorandola. In particolare, proponiamo una CBDC basata su token, solo 
con software e senza tecnologia di registro distribuito. La DLT è 
un'architettura interessante in assenza di un operatore centrale o se le 
entità che interagiscono non accettano di nominare un operatore centrale 
fidato. Questo non è certo il caso di una CBDC al dettaglio emessa da una 
\emph{banca centrale}. Distribuire il registro delle transazioni della 
banca centrale con una \textit{blockchain} non fa che aumentare i costi 
di transazione; non porta alcun vantaggio tangibile nell'implementazione 
da parte di una banca centrale. L'utilizzo della DLT per emettere moneta 
digitale può essere utile in assenza di una banca centrale (ad esempio, 
il progetto Sovereign delle Isole Marshall) o se l'intenzione esplicita 
è quella di fare a meno di una banca centrale (ad esempio, 
Bitcoin).\footnote{Potrebbero esserci casi opportuni di utilizzo della 
DLT per le infrastrutture dei mercati finanziari, come gli scambi digitali, 
dove sorge la questione di come incorporare la moneta della banca centrale 
all'interno di una struttura DLT per eseguire i regolamenti. Tuttavia, 
in tali situazioni i potenziali benefici della DLT, ad esempio costi 
inferiori o riconciliazione automatica, non derivano da un'emissione 
decentralizzata di moneta di banca centrale.}

La CBDC basata su token che proponiamo consente anche di preservare 
una caratteristica fondamentale del contante fisico: la privacy nelle 
transazioni. Spesso si sostiene che l'uso della crittografia per la 
tutela della privacy richieda così tanta potenza di calcolo da rendere 
impraticabile la sua implementazione su dispositivi 
portatili~\cite[vedi][]{Allen}. Sebbene questo possa essere vero nel 
caso di una tecnologia di registro distribuito, dove la tracciabilità 
delle transazioni è necessaria per prevenire la doppia spesa~\citet{Narayanan}, 
non lo è nel caso proposto in questo documento, dove si ha un protocollo 
di firma cieca di tipo Chaum e la partecipazione di una banca centrale. 
La nostra CBDC, basata su firme cieche e un'architettura a due livelli, 
garantisce una tutela della privacy nelle transazioni perfetta e 
quanto-resistente, fornendo al contempo protezioni sociali che sono di 
fatto più potenti rispetto a quelle delle banconote per la lotta al 
riciclaggio di denaro (\textit{Anti-Money Laundering} - AML) e al 
finanziamento del terrorismo (\textit{Counter Terrorism Financing} - CFT).

La privacy nelle transazioni è importante per tre motivi. In primo luogo, 
protegge gli utenti dal potenziale abuso di monitoraggio e sorveglianza 
da parte dei governi. Anche se si pensa di non avere nulla da nascondere, 
i piani di sorveglianza di massa restano problematici, se non altro per 
il rischio di errori e abusi, soprattutto se condotti senza trasparenza 
e responsabilità~\cite[vedi][]{Solove}. In secondo luogo, la privacy nelle 
transazioni protegge gli utenti dallo sfruttamento dei dati da parte dei 
fornitori di servizi di pagamento. Infine, salvaguarda gli utenti dalla 
controparte nelle transazioni in quanto esclude possibili comportamenti 
opportunistici successivi o rischi per la sicurezza dovuti a negligenza 
o mancata protezione dei dati dei clienti~\cite[vedi][]{Kahn2005}.

Questo documento è strutturato come segue: nella Sezione II si spiega 
la differenza tra la moneta di banca centrale e altri tipi di moneta. 
Nella Sezione III si esaminano i modelli di CBDC tipici e generici prima 
di proporre il nostro progetto nella Sezione IV. Si considerano poi 
gli aspetti normativi e le politiche (V) e il relativo lavoro (VI). 
Infine, si conclude (VII).


\section{Cos'è la moneta di banca centrale?}
        \label{2.-cos'è-la-moneta-di-banca-centrale}

La moneta è un attivo che può essere utilizzato per acquistare beni e 
servizi. Per essere considerato moneta, l'attivo deve essere accettato 
da entità diverse dall'emittente. Ecco perché i voucher, ad esempio, 
non sono considerati moneta. La moneta autentica deve essere 
\emph{comunemente} accettata come mezzo di scambio. Sebbene la moneta 
abbia altre funzioni, ad esempio come unità di conto e riserva di valore, 
la sua caratteristica distintiva è la sua funzione di mezzo di scambio. 
Normalmente l'unità di conto (cioè come avvengono la fissazione dei 
prezzi e la contabilizzazione dei debiti) coincide per ragioni 
pratiche con il mezzo di scambio. Una separazione può tuttavia 
verificarsi se il valore del mezzo di scambio manca di stabilità 
rispetto ai beni e servizi scambiati.\footnote{Ciò può accadere 
spontaneamente in un ambito caratterizzato da un'inflazione elevata, 
ad esempio quando i prezzi sono quotati in USD ma i pagamenti vengono 
effettuati in valuta locale. Lo stesso vale per i pagamenti in Bitcoin, 
dove i prezzi sono solitamente fissati in USD o altre valute locali a 
causa dell'elevata volatilità del Bitcoin. Una separazione può anche 
essere progettata appositamente, come nel caso 
dell'\textit{Unidad de Fomento} (UF) in Cile o i Diritti Speciali di 
Prelievo (DSP) del Fondo Monetario Internazionale (FMI). Tuttavia, 
anche in questi casi lo scopo è quello di avere un'unità di conto più 
stabile.} La moneta deve anche essere una riserva di valore per fungere 
da mezzo di scambio perché deve preservare il suo potere d'acquisto tra 
il momento in cui si riceve e quello in cui si spende. In ogni modo, 
ci sono molti altri attivi che fungono da riserva di valore, come azioni, 
obbligazioni, metalli preziosi e immobili. Pertanto, la caratteristica 
di riserva di valore non è distintiva della moneta.

In un'economia moderna, il pubblico utilizza due tipi diversi di 
moneta: (a) moneta statale e (b) moneta privata. La moneta statale viene 
generalmente emessa dalla banca centrale, che agisce in qualità di 
agente dello Stato. La moneta della banca centrale è disponibile per 
alcune istituzioni finanziarie sotto forma di depositi presso la banca 
centrale (riserve) e per il pubblico sotto forma di valuta (banconote e 
monete), nota anche come «contante». In una economia moderna con valuta 
fiat, tale moneta non ha un valore intrinseco. Legalmente è una passività 
della banca centrale, sebbene non sia rimborsabile. Nella maggior parte 
dei paesi, la moneta della banca centrale è definita come avente corso 
legale, il che significa che deve essere accettata per il pagamento dei 
debiti monetari, comprese le tasse e le sanzioni legali. Sebbene ciò 
garantisca un certo valore alla moneta della banca centrale, lo status 
di corso legale non è sufficiente per mantenere un valore stabile. È la 
politica monetaria della banca centrale che mantiene il valore della 
moneta. Mantenere la stabilità dei prezzi, vale a dire un valore stabile 
della moneta rispetto a quello dei beni e dei servizi scambiati, è 
infatti una delle principali responsabilità delle banche centrali.

La maggior parte dei pagamenti in un'economia moderna vengono effettuati 
con moneta privata emessa dalle banche commerciali ed è costituita da 
depositi bancari a vista che le persone detengono presso queste banche. 
Sono depositi che si posssono utilizzare mediante assegni, carte di 
debito, carte di credito e altri mezzi di trasferimento di denaro e 
costituiscono una passività della banca commerciale di riferimento. Una 
caratteristica fondamentale di questi depositi è che le banche commerciali 
garantiscono la convertibilità su richiesta in moneta della banca centrale 
ad un prezzo fisso, vale a dire, alla pari. I depositanti possono prelevare 
i propri fondi in contante o trasferirli ad un valore fisso di 1:1. Le 
banche commerciali mantengono stabile il valore della propria moneta 
ancorandola a quella della banca centrale.

Tuttavia, in un sistema di riserva frazionaria, una banca commerciale, 
anche se solvibile, potrebbe non avere liquidità a sufficienza per 
onorare la sua promessa di convertire i depositi bancari in moneta 
della banca centrale (ad esempio, nel caso di una corsa agli sportelli) 
in modo tale che i clienti non possano prelevare i propri soldi. Una 
banca può anche diventare insolvente e fallire, e di conseguenza i 
clienti possono perdere denaro. Per questo motivo le banche commerciali 
sono soggette a regolamentazioni volte a mitigare tali rischi.

Una differenza notevole tra la moneta di una banca centrale e la 
moneta privata emessa da una banca commerciale è, pertanto, che 
quest'ultima comporta un rischio di controparte. Una banca centrale 
può sempre adempiere ai suoi obblighi utilizzando la propria moneta 
non rimborsabile. In un'economia nazionale, la moneta della banca 
centrale è l'unico attivo monetario esento da rischi di credito e di 
liquidità. È pertanto l'attivo tipicamente preferito per regolare i 
pagamenti nelle infrastrutture dei mercati finanziari (si veda, per 
esempio, \textit{CPMI-IOSCO Principles for Financial Market 
Infrastructures}, 2012). Un'altra differenza risiede nella capacità 
della moneta della banca centrale di sostenere il sistema monetario 
nazionale fornendo un valore di riferimento con cui la moneta delle 
banche commerciali mantiene la piena convertibilità.

A parte le banche commerciali, altre entità private tentano 
occasionalmente di emettere moneta; le criptovalute sono solo il 
tentativo più recente. Ma a differenza dei depositi bancari, tale 
moneta non è comunemente accettata come mezzo di scambio. Questo vale 
anche per Bitcoin, la criptovaluta più ampiamente accettata. Un 
ostacolo all'utilità delle criptovalute come mezzo di scambio è l'elevata 
volatilità del loro valore. In risposta a questo problema sono emerse 
le criptovalute stabili, cosiddette «stablecoins». Le 
\textit{stablecoin} generalmente tentano di stabilizzare il proprio 
valore in due modi: imitando le banche centrali (\textit{stablecoin} 
algoritmiche) o imitando le banche commerciali e strumenti di 
investimento (\textit{stablecoin} ancorate ad attivi).\footnote{Per una 
tassonomia delle \textit{stablecoin}, si veda~\cite{Bullmann}.}

Le «\textit{stablecoin} algoritmiche» si basano su algoritmi per regolare 
l'offerta della moneta. In altre parole, cercano di stabilizzarne il 
prezzo attraverso una «politica monetaria algoritmica». Esistono 
esempi di tali \textit{stablecoin} (per es. Nubits), ma finora nessuna è 
riuscita a stabilizzare il proprio valore per molto tempo.

Le \textit{stablecoin} «ancorate ad attivi» differiscono in base al tipo 
di attivo che utilizzano e ai diritti concessi ai possessori. I tipi di 
attivi generalmente utilizzati sono: valuta (riserve di banche centrali, 
banconote o depositi presso banche commerciali), materie prime (come 
l'oro), titoli e talvolta altre criptovalute. La capacità di un tale 
schema di stabilizzare il valore della moneta rispetto agli attivi 
sottostanti dipende in modo cruciale dai diritti legali acquisiti dai 
detentori della moneta. Se una \textit{stablecoin} è riscattabile ad un 
prezzo fisso (ad esempio, 1 moneta = 1 USD o 1 moneta = 1 oncia d'oro), 
la stabilità si può teoricamente ottenere.\footnote{Se possa stabilizzare 
il valore della \textit{stablecoin} anche rispetto ai beni e servizi 
scambiati dipende essenzialmente da quanto sia stabile il valore degli 
attivi su cui poggia rispetto al valore dei beni e servizi.} Tale strategia 
riproduce essenzialmente quella delle banche commerciali garantendo la 
convertibilità nell'attivo sottostante su richiesta. Tuttavia, a differenza 
dei depositi bancari, che in genere sono coperti solo parzialmente dalle 
riserve della banca centrale, le  \textit{stablecoin} sono spesso 
completamente garantite dalle riserve di attivi sottostanti al fine di 
evitare il rischio di liquidità, principalmente perché non dispongono di 
tutele pubbliche tali come l'assicurazione dei depositi e il prestatore 
di ultima istanza che offrono invece le banche regolamentate.

Le \textit{stablecoin} che utilizzano le valute come attivi sono anche 
dette «stablecoin a valuta fiat». Detenere il 100\% delle 
garanzie sotto forma di valuta (banconote o depositi bancari) non risulta però 
molto redditizio. Di conseguenza, i fornitori di \textit{stablecoin} hanno 
un buon motivo per rispiarmiare sugli attivi passando ad un sistema di 
riserva frazionaria, proprio come hanno fatto le banche 
commerciali.\footnote{L'incertezza sulla garanzia delle 
\textit{stablecoin} può essere uno dei motivi per cui vengono scambiate 
al di sotto del loro valore nel mercato parallelo~\cite[vedi][]{Lyons}. 
Casi simili si sono storicamente verificati anche con le banconote, quando 
erano ancora emesse dalle banche commerciali. Le banconote venivano 
scambiate a prezzi scontati nel mercato parallelo prima che l'emissione 
fosse nazionalizzata e trasferita alle banche centrali come monopolio.} 
Ciò comporta la riduzione degli attivi meno redditizi al minimo ritenuto 
necessario per soddisfare il requisito di convertibilità e l'aumento 
degli attivi liquidi a rendimento più elevato come i titoli di stato. 
Questo migliora la redditività ma aumenta nel contempo il livello 
di rischio. Tuttavia, anche se una \textit{stablecoin} fosse garantita 
interamente da depositi presso le banche commerciali, rimarrebbe comunque 
vulnerabile ai rischi di insolvenza del credito e di liquidità della 
relativa banca. Tale rischio può essere evitato effettuando i depositi 
presso la banca centrale in modo che siano le riserve di quest'ultima a 
garantire la \textit{stablecoin}. Tali \textit{stablecoin} sono state 
chiamate «CBDC sintetiche»~\cite[][]{Adrian}. È importante sottolineare che 
queste \textit{stablecoin} non sono moneta di banca centrale e quindi 
non costituiscono una CBDC in quanto non sono registrate come passività 
della banca centrale e, pertanto, rimangono soggette al rischio di 
controparte, ovvero al rischio di fallimento dell'emittente.

% Not sure the reference to Adrian above is fixed correctly. 

Se una \textit{stablecoin} non è rimborsabile ad un prezzo fisso, la sua 
stabilità rispetto all'attivo sottostante non è garantita. Se la 
\textit{stablecoin} rappresenta comunque una quota di proprietà 
dell'attivo sottostante, lo schema ricorda quello di un fondo comune di 
investimento chiuso o di un fondo indicizzato quotato (\textit{Exchange-
Traded Fund} - ETF) e si applicano i relativi rischi. Il valore 
della moneta dipenderà dal valore patrimoniale netto del fondo, ma il 
suo valore effettivo può variare. Se ci sono partecipanti autorizzati 
a creare e riscattare \textit{stablecoin} e quindi ad agire come 
arbitraggisti, come nel caso degli ETF e come previsto per la 
Diem~\cite[][]{Libra}, la deviazione si presume minima.

% Not sure the reference to Libra above is fixed correctly.

Nel complesso, le \textit{stablecoin} hanno maggiori possibilità di 
diventare moneta rispetto alle criptovalute, soprattutto se 
adeguatamente regolamentate, anche se la disponibilità di CBDC 
limiterebbe notevolmente la loro utilità.

\section{Modelli generici di CBDC} \label{3.-modelli-generici-di-cbdc}

Come abbiamo visto, la CBDC sarebbe una passività della banca 
centrale. Due modelli possibili che si trovano nella letteratura 
sull'argomento sono (a) CBDC basata su conti e (b) CBDC basata su 
token (o sul valore). Questi modelli corrispondono ai due tipi 
esistenti di moneta delle banche centrali e ai relativi sistemi di 
pagamento (Kahn e Roberds 2008): riserve delle banche centrali 
(sistema basato su conti) e banconote (sistema basato su token). Un 
pagamento si verifica quando un'attivo monetario viene trasferito da un 
pagatore a un beneficiario. In un sistema basato su conti, il 
trasferimento avviene addebitando sul conto del pagatore e 
accreditando sul conto del beneficiario. In un sistema basato su 
token, il trasferimento avviene trasferendo il valore stesso o il 
token, ovvero un oggetto che rappresenta l'attivo monetario. Il miglior 
esempio di token è il contante (monete o banconote). Pagare in contanti 
equivale a consegnare una moneta o una banconota. Non è necessario 
registrare il trasferimento, il semplice possesso del token è 
sufficiente. Pertanto, le parti non sono tenute a rivelare la propria 
identità in nessun momento durante la transazione, entrambe possono 
rimanere anonime. Ciononostante, il beneficiario deve essere in grado di 
verificare l'autenticità del token. Questo è il motivo per cui le 
banche centrali investono notevoli risorse nelle caratteristiche di 
sicurezza delle banconote.

È stato suggerito che la distinzione tra sistemi basati su conti e 
quelli basati su token non sia applicabile alle monete digitali~\cite[][]{Garratt}. 
Noi al contrario riteniamo che ci sia una differenza significativa. La 
differenza essenziale risiede nelle informazioni contenute nell'attivo. 
In un sistema basato su conti, gli attivi (i conti) sono riconducìbili  
ad una cronologia delle transazioni che include tutte le operazioni di 
credito e addebito dei conti. In un sistema basato su token, gli attivi 
(i token) contengono solo informazioni sul valore del token e 
sull'entità che lo ha emesso. I sistemi basati su token sono quindi 
l'unica possibilità per ottenere la stessa privacy nelle transazioni che 
offre il contante.\footnote{Sebbene il termine «Bitcoin» suggerisca 
l'uso di token, Bitcoin è un sistema basato su conti. L'unica differenza 
tra un sistema tradizionale basato su conti e una \textit{blockchain} è 
che i conti non sono conservati in un database centrale ma in un 
database decentralizzato di solo accodamento.}

% Not sure the reference to Garratt above is fixed correctly.

\subsection{CBDC basata su conti}\label{cbdc-basata-su-conti}

Il modo più semplice per avviare una CBDC sarebbe consentire al 
pubblico di detenere conti deposito presso la banca centrale. Ciò 
comporta che la banca centrale si facesse responsabile dei controlli per 
conoscere i propri clienti (\textit{Know-Your-Customer} - KYC) e di 
garantire la conformità con i requisiti per la lotta al riciclaggio di 
denaro e al finanziamento del terrorismo. Ciò includerebbe non solo la 
gestione del processo iniziale di conoscenza del cliente, ma anche 
l'autenticazione dei clienti per le transazioni bancarie, la gestione 
delle frodi e delle autenticazioni false positive e false negative. 
Data la scarsa presenza fisica delle banche centrali nella società e il 
fatto che probabilmente oggi non sono disposte ad eseguire l'autenticazione 
dei cittadini su larga scala, qualsiasi CBDC basata su conti richiederebbe 
alla banca centrale di delegare questi compiti. Tutti i servizi di 
assistenza e manutenzione di tali conti potrebbero essere affidati ad  
operatori esterni~\cite[][]{Bindseil}, oppure le banche commerciali potrebbero 
essere obbligate per legge ad aprire conti presso la banca centrale per i
propri clienti~\cite{Berentsen}.

% Not sure the references to Bindseil, and Berentsen, above are fixed correctly.

Una CBDC basata su conti darebbe potenzialmente alla banca centrale 
l'accesso a molti dati aggiuntivi. Uno dei motivi di preoccupazione è 
che i governi potrebbero facilmente mettere in atto una sorveglianza 
di massa e imporre sanzioni ai singoli titolari dei conti. La natura 
centralizzata di tali interventi li rende poco costosi e facili da 
applicare nei confronti di persone o gruppi. Ci sono molti esempi di 
sorveglianza abusiva contro critici e oppositori politici, anche nelle 
democrazie. Si potrebbe argomentare che le banche centrali indipendenti 
siano in grado di salvaguardare tali informazioni dall'intrusione del 
governo e dagli abusi politici, ma ciò aprirebbe comunque una nuova 
strada alle pressioni politiche che minacciano l'indipendenza delle 
banche centrali. Inoltre, un database centrale sarebbe un obiettivo 
cospicuo per gli attacchi: anche l'accesso in sola lettura ad una parte 
del database potrebbe creare rischi significativi per le persone i cui 
dati sarebbero esposti.

Se dovessero forniri conti bancari per il pubblico, le banche centrali 
entrerebbero in diretta concorrenza con le banche commerciali, competizione 
che comporterebbe due rischi. In primo luogo, potrebbe minacciare la base 
dei depositi delle banche e, all'estremo, portare alla disintermediazione 
bancaria. Ciò potrebbe influire negativamente sulla disponibilità di 
credito per il settore privato e, di conseguenza, sull'attività 
economica~\cite[][]{Agur}. La disintermediazione delle banche potrebbe anche 
condurre alla centralizzazione dell'allocazione del credito all'interno 
della banca centrale, con ripercussioni negative sulla produttività e 
sulla crescita economica. In secondo luogo, la possibilità per le persone 
di trasferire i propri depositi nel porto sicuro di una banca centrale 
potrebbe accelerare le corse agli sportelli nei periodi di crisi economica.

% Not sure the reference to Agur above is fixed correctly.

Vi sono però argomentazioni contrarie. \cite{Brunnermeier} 
sostengono che i trasferimenti di fondi dai depositi ai conti 
CBDC porterebbero alla sostituzione automatica del finanziamento 
mediante depositi con il finanziamento tramite la banca centrale, il 
che andrebbe ad esplicitare la garanzia finora implicita di prestatore 
di ultima istanza delle banche centrali. \cite{Berentsen} 
sostengono che la concorrenza delle banche centrali potrebbe persino 
avere un effetto disciplinare sulle banche commerciali e quindi 
aumentare la stabilità del sistema finanziario, dato che queste ultime 
sarebbero costrette a consolidare la sicurezza dei propri modelli 
economici per eviatare corse agli sportelli.

Esistono anche proposte per ridurre il rischio di disintermediazione 
restringendo o scoraggiando l'uso della CBDC come riserva di valore. Una 
delle proposte è di limitare la quantità di CBDC che si può possedere. 
Una seconda proposta consiste nell'applicare un tasso di interesse 
variabile ai conti in CBDC, in modo che il rendimento sia sempre 
sufficientemente inferiore a quello dei conti nelle banche commerciali, 
arrivando eventualmente fino a tassi negativi, in modo da rendere la CBDC 
meno attraente come riserva di valore~\cite{Kumhof,Bindseil}. Oltre a ciò, 
per evitare le corse agli sportelli \cite[][]{Kumhof} suggeriscono che la 
CBDC non dovrebbe essere emessa a fronte di depositi bancari ma solo a 
fronte di obbligazioni come i titoli di stato. Nel complesso, una CBDC 
basata su conti richiederebbe un'analisi più approfondita di queste 
problematiche.

% References to Kumhof, Bindseil above should render like this:
% valore (Kumhof & Noone, 2018 e Bindseil, 2020).

% Not sure the reference to Kumhof above is fixed correctly.

\subsection{CBDC Basata su token e legata al hardware}
\label{cbdc-basata-su-token-e-legata-al-hardware}

In alternativa ai conti deposito, una banca centrale potrebbe emettere 
token elettronici. Tecnicamente ciò richiede un sistema per garantire che 
i token elettronici non possano essere copiati facilmente. Le funzioni 
fisicamente non clonabili~\cite[vedi][]{Katzenbeisser} e le aree 
sicure nell'hardware~\cite[vedi][]{Alves,Pinto} sono due tecnologie 
possibili per la prevenzione della copia digitale. Le funzioni 
fisicamente non clonabili, tuttavia, non possono essere scambiate su 
Internet (eliminando di fatto l'uso principale delle CBDC) e le precedenti 
funzionalità di sicurezza nell'hardware per la prevenzione della copia 
sono state ripetutamente compromesse~\cite[si veda, ad esempio,][]{Wojtczuk,Johnston,Lapid}.

Un vantaggio fondamentale delle CBDC basate su token rispetto a quelle 
basate su conti è che i sistemi tokenizzati funzionerebbero offline, 
ovvero, gli utenti potrebbero scambiare token (\textit{peer-to-peer}) 
senza coinvolgere la banca centrale, proteggendo così la privacy e la 
libertà delle persone. Tuttavia, la disintermediazione che si verifica 
quando gli utenti possono scambiare token elettronici senza 
intermediari bancari che eseguano i controlli per la conoscenza dei 
clienti e le procedure per la lotta al riciclaggio di denaro e al 
finanziamento del terrorismo renderebbe difficile la lotta alla 
criminalità.

Le schede SIM sono oggi il mezzo più ampiamente disponibile per un 
sistema di pagamento sicuro basato su hardware, ma comportano anche 
dei rischi. L'esperienza~\cite[si veda, ad esempio,][]{Soukup,Garcia,Kasper,CCC} 
suggerisce che qualsiasi dispositivo economicamente riproducibile in grado 
di memorizzare token con valore monetario, che una persona possa possedere 
e che consenta transazioni offline --- e quindi il furto mediante 
clonazione delle informazioni in esso contenute --- sarà l'obiettivo di 
attacchi di contraffazione riusciti non appena il valore economico 
dell'attacco risulti sostanziale. Tali attacchi provengono anche da 
utenti che forzano il proprio hardware~\cite[vedi][]{Allen}. Per 
limitare l'impatto di una compromissione, i sistemi con carte di pagamento 
che sono stati precedentemente implementati dependono dalla resistenza 
alle manomissioni in combinazione con il rilevamento delle frodi. 
Tuttavia, il rilevamento delle frodi richiede la capacità di identificare 
i pagatori e tenere traccia dei clienti, il che non è compatibile con la 
privacy nelle transazioni.

\section{Una CBDC basata su token progettata per tutelare la privacy}
\label{4.-una-cbdc-basata-su-token-progettata-per-tutelare-la-privacy}

La CBDC qui proposta è di tipo «solo software», semplicemente 
un'applicazione per smartphone che non richiede alcun hardware aggiuntivo. 
Il design fa affidamento su eCash e GNU Taler. Taler fa parte del progetto 
GNU, il cui fondatore, Richard Stallman, ha coniato il termine 
«\emph{Software Libero}», ora spesso indicato come \textit{Free/Libre 
and Open Source Software} (FLOSS).\footnote{Per ulteriori informazioni 
su GNU, si veda \url{https://www.gnu.org} e \cite{Stallman}. GNU Taler 
è rilasciato sotto la licenza libera \textit{GNU Affero General Public 
License} del Progetto GNU. Altri programmi del progetto GNU noti tra gli 
economisti sono \textit{R} e \textit{GNU Regression, Econometrics and 
Time-series Library} (GRETL). Per un'analisi dei vantaggi del FLOSS 
rispetto al software proprietario nel campo della ricerca, si veda~\cite{Baiocchi}, \cite{Yalta2008} e \cite{Yalta2010}. 
Sulle licenze libere e open source, si veda~\cite{Lerner}.} Il software 
è considerato libero se la sua licenza concede agli utenti quattro libertà 
essenziali: la libertà di eseguire il programma come si desidera, la 
libertà di studiare il programma e modificarlo, la libertà di ridistribuire 
copie del programma e la libertà di distribuire copie delle versioni 
modificate del programma. Il software libero non impedisce la 
commercializzazione; fornire supporto tecnico per il software è un modello 
di business standard per il FLOSS.

Dato il gran numero di parti interessate coinvolte in una CBDC al 
dettaglio (la banca centrale, il settore finanziario, i venditori e 
i clienti) e l'importanza critica dell'infrastruttura, una CBDC al 
dettaglio deve essere basata sul FLOSS. Imporre una soluzione 
proprietaria, che comporta la dipendenza da un fornitore specifico, 
sarebbe probabilmente un ostacolo all'adozione fin dall'inizio. Con il 
FLOSS, tutte le parti interessate hanno accesso a ogni dettaglio della 
soluzione e il diritto di adattare il software alle proprie esigenze. 
Ciò facilita l'integrazione e migliora l'interoperabilità e la 
concorrenza tra i fornitori.\footnote{Tuttavia, l'hardware privato 
potrebbe avere un ruolo da svolgere. La protezione degli archivi delle 
chiavi e di alcune funzioni di controllo, ad esempio, può essere un'area 
dove l'hardware dedicato valutato solo da un numero limitato di esperti 
può presentare dei vantaggi, nella misura in cui tale sicurezza sia solo 
additiva.} Consente inoltre alla banca centrale di soddisfare i requisiti 
di trasparenza e responsabilità. I vantaggi del FLOSS riguardo la 
sicurezza sono anche ampiamente riconosciuti. La disponibilità del codice 
sorgente e la libertà di modificarlo facilitano l'identificazione degli 
errori e la loro rapida correzione. \footnote{Ad esempio, un bollettino 
sulla sicurezza informatica emesso dall'Agenzia per la sicurezza nazionale 
degli Stati Uniti (NSA) nell'aprile 2020 esorta gli utenti a dare la 
priorità al software libero nella scelta e nell'utilizzo dei servizi 
collaborativi per le comunicazioni su Internet: «Lo sviluppo open source 
garantisce trasparenza sulla robustezza del codice e la sua conformità 
alle migliori pratiche di programmazione, evitando l'introduzione di 
vulnerabilità o punti deboli che potrebbero mettere a rischio utenti e 
dati» (U/OO/134598-20).}

Nell'architettura che proponiamo, tutte le interazioni tra consumatori 
e venditori si fanno con le banche commerciali, ma la creazione di moneta 
e il database sono forniti esclusivamente dalla banca centrale. Le banche 
commerciali autenticano i clienti quando ritirano CBDC così come i 
venditori o beneficiari quando le ricevono. Quando spendono CBDC, 
invece, i clienti o pagatori devono solo autorizzare le transazioni senza 
bisogno di identificarsi. I pagamenti risultano più economici, più facili 
e più veloci, evitando al contempo interferenze con la privacy~\cite[][]{Dold}. 
L'autenticazione dei clienti quando ritirano CBDC, nonché dei venditori 
o beneficiari quando le ricevono, consente altresì di adempire alle 
normative sulla conoscenza dei clienti e sulla lotta al riciclaggio di 
denaro e al finanziamento del terrorismo.

% Not sure the reference to Dold above is fixed correctly.

La CBDC che si propone in questo documento è un vero e proprio 
strumento digitale al portatore perché quando l'utente preleva una 
somma di denaro sotto forma di numero, tale numero viene «accecato» o 
nascosto dallo smartphone con un'apposita crittografia. Nel sistema 
stesso, una moneta è una coppia di chiavi pubblica-privata dove la 
chiave privata è nota solo al proprietario della moneta.\footnote{In 
Bitcoin, un sistema basato su conti, la coppia di chiavi è un conto 
dove la chiave pubblica rappresenta l'«indirizzo» e quindi una sorta di 
«identità», anche se pseudonimo.} La moneta trae il suo valore 
finanziario dalla firma della banca centrale apposta sulla chiave 
pubblica della moneta. La banca centrale firma con la propria chiave 
privata e detiene più coppie di chiavi di valore per apporre la firma 
cieca su monete di diverso valore unitario. Il venditore può utilizzare 
la corrispondente «chiave pubblica» della banca centrale per verificare 
la firma. Tuttavia, al fine di garantire che la moneta non sia stata 
copiata e già ritirata da un altro beneficiario (cioè che non sia stata 
«spesa due volte»), il venditore deve depositare la moneta affinché la 
banca centrale possa confrontarla con un archivio di monete ritirate. 
Poiché né la banca commerciale né la banca centrale vedono il numero 
della moneta durante il prelievo, in seguito, quando il venditore 
deposita la moneta, non si sa quale utente l'abbia ritirata. L'accecamento 
e la privacy che ne deriva fanno di questa tipologia di CBDC un vero e 
proprio strumento digitale al portatore.

Nell'analisi che segue forniamo una panoramica approfondita della 
tecnologia e mostriamo come si può integrare con il sistema bancario 
esistente per creare una CBDC.  \citet{Dold} fornisce ulteriori 
dettagli.

\subsection{Componenti fondamentali}\label{componenti-fondamentali}

Di seguito si descrivono i componenti principali del protocollo, comprese 
le basi matematiche per una delle possibili rappresentazioni delle 
primitive crittografiche utilizzate, allo scopo di illustrare in 
che modo potrebbe funzionare un'implementazione. Considerando che 
esistono altri modelli matematici equivalenti per ciascun componente, 
presentiamo solo la più semplice delle soluzioni sicure a noi note.

\emph{Firme digitali.} L'idea che sta alla base delle firme digitali in 
uno schema di firma a chiave pubblica è quella di garantire che il 
titolare della chiave privata sia l'unico in grado di firmare un 
messaggio, mentre la chiave pubblica consente a chiunque di verificare 
la validità della firma.\footnote{La crittografia a chiave pubblica è 
stata introdotta da~\cite{Diffie} e le prime implementazioni di firme 
digitali sono state quelle di~\cite{Rivest}.} Il risultato della funzione 
di verifica della firma è la dichiarazione binaria «vero» o «falso». Se 
il messaggio è firmato con la chiave privata che appartiene alla chiave 
pubblica di verifica, il risultato è «vero», altrimenti è «falso». 
Nella nostra proposta il messaggio è una moneta o una banconota con un 
numero di serie, e la firma della banca centrale ne attesta la 
validità. Sebbene GNU Taler utilizzi per impostazione predefinita le 
moderne firme EdDSA~\cite[vedi][]{Bernstein2012}, qui presentiamo un 
semplice schema di firma crittografica basato su RSA~\cite[][]{Rivest}, un 
sistema crittografico ben studiato.\footnote{Per un'analisi della 
lunga storia del crittosistema RSA e uno studio degli attacchi a questo 
sistema, si veda~\cite{Boneh}.} Tuttavia, in linea di principio, è 
possibile utilizzare qualsiasi tecnologia di firma crittografica 
(DSA, ECDSA, EdDSA, RSA, ecc.)

% Not sure the reference to Rivest above is fixed correctly.

Per generare una chiave RSA, il firmatario prende prima due grandi 
numeri primi indipendenti $p$ e $q$ e calcola $n = \emph{pq}$, 
nonché la funzione phi di Eulero 
$\phi(n) = (p - 1)(q - 1)$. 
Quindi, si può utilizzare qualsiasi $e$ con $1 < e < \phi(n)$ e 
$\gcd(e, \phi(n)) = 1$ per definire una chiave pubblica $(e,n)$. 
La condizione che il massimo comune denominatore ($\texttt{MCD}$) di $e$ e 
$\phi(n)$ debba essere 1 (cioè, che devono essere 
primi tra loro) assicura che l'inverso di 
$e \mod \phi(n)$ esista. 
Questo inverso è la 
corrispondente chiave privata $d$. Data $\phi(n)$, la chiave 
privata $d$ può essere calcolata mediante l'algoritmo esteso 
di Euclide tale che 
$d \cdot e \equiv 1 \mod \phi(n)$.

Data la chiave privata $d$ e la chiave pubblica $(e, n)$, una semplice 
firma RSA 
$s$ su un messaggio $m$ è 
$s \equiv m^{d} \mod n$. 
Per verificare la firma si calcola 
$m' \equiv s^{e} \mod n$. 
Se $m'$ e $m$ corrispondono, la firma è valida e dimostra che il 
messaggio è stato firmato con la chiave privata che corrisponde alla 
chiave pubblica di verifica (autenticazione del messaggio) e che il 
messaggio non è stato modificato durante il transito (integrità del 
messaggio). In pratica, le firme vengono poste sull'hash dei messaggi 
piuttosto che sui messaggi stessi. Le funzioni di hash calcolano le 
impronte digitali dei messaggi (\textit{digest}), che sono identificatori 
univoci e brevi per i messaggi. Firmare un hash breve è molto più veloce 
che firmare un messaggio di grandi dimensioni, e la maggior parte degli 
algoritmi di firma funzionano solo su input relativamente brevi.\footnote{Nel 
caso del crittosistema RSA, il limite di lunghezza è di 
$\log_{2}n$ bit.}

\emph{Firme cieche.} Utilizziamo le firme cieche introdotte 
da~\cite{Chaum1983} per tutelare la privacy degli acquirenti. Una firma 
cieca viene utilizzata per creare una firma crittografica per un messaggio 
senza rivelare al firmatario il contenuto del messaggio. Nella nostra proposta, 
ciò impedisce alle banche commerciali e alla banca centrale di poter risalire 
all'acquirente tracciando gli acquisti. In linea di principio, la nostra 
proposta funziona con qualsiasi sistema di firma cieca, ma la soluzione migliore 
rimane la variante basata su RSA descritta da~\cite{Chaum1983}. 

L'accecamento viene eseguito dai clienti, che accecano le proprie 
monete prima di trasmetterle alla banca centrale per la firma. I 
clienti non devono quindi affidare alla banca centrale la tutela della 
propria privacy. Inoltre, l'accecamento con RSA fornirebbe protezione 
della privacy anche contro gli attacchi informatici quantistici. La 
banca centrale, dal canto suo, predispone più coppie di chiavi di 
valore per apporre la firma cieca su monete di diverso valore 
unitario, e fornisce le corrispondenti chiavi pubbliche 
$(e, n)$ per tali valori.

Sia $f$ il valore di hash di una moneta e quindi l'identificatore 
univoco per questa moneta. Il cliente che preleva la moneta prima 
genera un fattore di accecamento casuale $b$ e calcola 
$f' \equiv fb^{e} \mod n$ 
con la chiave pubblica della banca centrale per quel valore. 
La moneta accecata $f'$ viene quindi trasmessa alla banca centrale per 
la firma. La banca centrale firma $f'$ con la sua chiave 
privata $d$ calcolando la firma cieca 
$s' \equiv \left(f' \right)^{d} \mod n$, appone 
la firma $s'$ alla moneta accecata $f'$ e restituisce la coppia 
$(s',f')$ al cliente. Il cliente può quindi rimuovere l'accecamento 
della firma calcolando 
$s \equiv s'b^{- 1} \mod n$. 
Ciò è possibile perché 
$\left( f' \right)^d = f^db^{ed} = f^db$, e quindi 
moltiplicando $s'$ con $b^{- 1}$ si ottiene $f^d$, che è una firma RSA 
valida su $f$ come prima: 
$s^e \equiv f^{de} \equiv f \mod n$.

Nella proposta originale di Chaum, le monete erano dei semplici 
gettoni. Quel che vogliamo, invece, è che i consumatori possano 
utilizzare le firme digitali per stipulare contratti. A tal fine, ogni 
volta che un portafoglio digitale preleva una moneta, in primo luogo 
crea per la moneta una chiave privata casuale $c$ e calcola la 
corrispondente chiave pubblica $C$ per creare firme digitali con i 
normali sistemi di firma crittografica (come DSA, ECDSA, EdDSA e 
RSA). Quindi si deriva $f$ mediante una funzione di hash crittografica 
dalla chiave pubblica $C$, prima che la banca centrale ne apponga la 
firma cieca (utilizzando un nuovo fattore di accecamento casuale per 
ciascuna moneta). Ora il cliente può utilizzare $c$ per firmare 
elettronicamente gli acquisti, spendendo così la moneta.

Come visto sopra, la banca centrale andrebbe a predisporre coppie di 
chiavi diverse per ogni valore unitario di moneta e pubblicherebbe le 
chiavi pubbliche che i clienti userebbero per prelevare denaro. Queste 
chiavi di valore, e quindi le monete, avrebbero una data di scadenza 
prima della quale dovrebbero essere spese o scambiate con monete 
nuove. Ai clienti verrebbe concesso un certo periodo di tempo per 
scambiare le monete. Un processo simile esiste per le banconote 
fisiche, dove le serie di banconote vengono regolarmente rinnovate per 
essere dotate delle più recenti caratteristiche di sicurezza, tranne 
per il fatto che le banconote generalmente rimangono in circolazione 
per decenni anziché per pochi anni o mesi.\footnote{In Svizzera, 
ad esempio, la Banca nazionale svizzera ha iniziato a ritirare dalla 
circolazione l'ottava serie di banconote nell'aprile 2016. Questa serie 
era stata messa in circolazione alla fine degli anni novanta. Dal 1 
gennaio 2020, tuttavia, tutte le banconote a partire dalla sesta serie 
(emesse nel 1976) fino alle serie future restano valide e possono essere 
scambiate a tempo indeterminato con banconote correnti.}

Da un punto di vista tecnico, una data di scadenza offre due vantaggi. 
In primo luogo, migliora l'efficienza del sistema perché la banca 
centrale può cancellare i dati scaduti, evitando così di dover 
archiviare e poi cercare in un elenco sempre crescente di monete 
(spese) per rilevare una doppia spesa. In secondo luogo, riduce i 
rischi per la sicurezza dato che la banca centrale non deve 
preoccuparsi di attacchi alle proprie chiavi (private) di valore ($d$) 
scadute. Inoltre, anche se una chiave privata venisse compromessa, il 
periodo durante il quale l'attaccante può utilizzarla è breve. In aggiunta, 
l'addebito di una commissione di cambio consentirebbe alla banca centrale di 
applicare tassi di interesse negativi, se ritenuto necessario. La banca centrale 
potrebbe anche, se lo desidera, fissare un limite di conversione per cliente in 
considerazione dell'antiriciclaggio e l'antiterrorismo (soglia di «contante») o 
per motivi di stabilità finanziaria (per prevenire accaparramenti e corse agli 
sportelli).

\emph{Protocollo di scambio di chiavi.} GNU Taler utilizza un protocollo 
di scambio di chiavi in un modo particolare per fornire un collegamento 
tra la moneta originale e il resto reso per quella stessa moneta. Ciò 
garantisce che il resto possa sempre essere reso senza compromettere 
la trasparenza del reddito e la privacy dei consumatori. Lo stesso 
meccanismo si può utilizzare per i rimborsi anonimi ai clienti. Il 
protocollo gestisce anche i guasti alla rete e ai componenti, 
assicurando che i pagamenti siano andati a buon fine o siano stati 
definitivamente annullati e che tutte le parti abbiano una prova 
crittografica dell'esito. Questo corrisponde all'incirca agli scambi 
atomici nei protocolli \textit{interledger} o allo scambio equo nei 
tradizionali sistemi \textit{e-cash}.

La costruzione matematica più comune per un protocollo di scambio di 
chiavi è la costruzione~\cite{Diffie}), che 
consente a due parti di derivare una chiave segreta condivisa. A tale 
scopo, condividono due parametri di dominio $p$ e $g$, che possono 
essere pubblici, dove $p$ è un numero primo grande e $g$ è una radice 
primitiva modulo $p$.\footnote{Un intero $g$ è una radice primitiva 
modulo $p$ se per ogni intero $a$ coprimo a $p$ esiste un intero $k$ 
per il quale 
$g^k \equiv a \mod p$. 
In pratica, $g$ dovrebbe essere una radice primitiva $(p-1)$-esima, detta 
anche generatore, al fine di prevenire attacchi a sottogruppi come quelli 
Pohlig-Hellman~\cite[vedi][]{Lim}.} Ora, le due parti scelgono le loro 
chiavi private \emph{a} e \emph{b}, che sono due numeri interi grandi. 
Con queste chiavi private e i parametri di dominio, generano le 
rispettive chiavi pubbliche 
$A \equiv g^{a} \mod p$ e $B \equiv g^{b} \mod p$. 
Ciascuna parte può ora utilizzare la propria chiave privata e la chiave 
pubblica dell'altra parte per calcolare la chiave segreta condivisa 
$k \equiv \left( g^b \right)^{a} \equiv \left( g^{a} \right)^{b} \equiv g^{\text{ab}} \mod p$.\footnote{
Lo stesso meccanismo potrebbe essere utilizzato per garantire 
che le monete non vengano trasferite a terzi durante il prelievo. A 
questo scopo, gli utenti devono salvaguardare una chiave di identità a 
lungo termine. Il processo di prelievo potrebbe quindi essere 
costruito allo stesso modo di quello utilizzato da GNU Taler per dare 
il resto, tranne per il fatto che quando si preleva dal conto bancario 
del cliente verrebbe utilizzata la chiave d'identità a lungo termine 
del cliente al posto della moneta originale. Tuttavia, le garanzie 
sulla privacy potrebbero decadere se il cliente non protegge la chiave 
d'identità a lungo termine, con il conseguente rischio di furto di 
tutte le monete residue. Dato che il rischio nei trasferimenti a terzi 
quando si prelevano monete è basso, non è chiaro se questa riduzione 
del rischio possa essere un buon compromesso.}

Per ottenere il resto, il cliente parte dalla chiave privata della 
moneta parzialmente spesa $c$. Sia $C$ la chiave pubblica corrispondente, 
per esempio  
$C = g^{c} \mod p$. 
Quando la moneta fu parzialmente spesa in precedenza, la banca centrale 
registrò la transazione relativa a $C$ nel proprio database. Per 
semplicità, assumiamo che esista un valore unitario che corrisponda 
esattamente a questo valore residuo. In caso contrario, il protocollo si 
riavvia finché non viene reso tutto il resto. Sia $(e,n)$ la 
chiave di valore per il resto da rendere.

Per ottenere il resto, l'acquirente crea prima $\kappa$ chiavi di 
trasferimento private $t_{i}$ per 
$i \in \left\{ 1,\ldots,\kappa \right\}$ e calcola le 
corrispondenti chiavi pubbliche $T_{i}$. Queste chiavi di 
trasferimento $\kappa$ sono semplicemente coppie di chiavi 
pubbliche-private che consentono al cliente di eseguire localmente il 
protocollo di scambio di chiavi, con il cliente che gioca su entrambi 
i lati del processo, $\kappa$ volte tra $c$ e ogni $t_{i}$. 
Se si usa Diffie-Hellman come protocollo per lo scambio di chiavi, si 
ottiene 
$T_{i} \equiv g^{t_{i}} \mod p$.

Il risultato sono tre trasferimenti 
$K_{i} \equiv \emph{KX}(c,t_{i})$. Il protocollo di scambio di chiavi 
può essere utilizzato in diversi modi per ottenere lo stesso valore 
$K_{i} \equiv \emph{KX}(C,t_{i}) = \emph{KX}(c,T_{i})$. 
Data $K_{i}$, il cliente utilizza una funzione crittografica hash $H$ 
per ricavare i valori 
$(b_{i},c_{i}) \equiv H(K_{i})$, dove 
$b_{i}$ è un fattore di accecamento valido per la chiave di valore 
$(e,n)$ e $c_{i}$ 
è una chiave privata per la nuova moneta da ottenere come resto. 
$c_{i}$ deve essere adatta sia per creare firme crittografiche sia per 
un uso futuro con il protocollo di scambio di chiavi 
(come $c$, per ottenere resto a partire dal resto). 
Sia $C_{i}$ la chiave pubblica corrispondente a $c_{i}$. 
Il cliente chiede quindi alla banca centrale di creare una firma cieca su 
$C_{i}$ per $i \in \{ 1,\ldots,\kappa\}$.\footnote{Se dovesse essere 
utilizzato il crittosistema RSA per le firme cieche, useremmo 
$f \equiv \emph{FDH}_{n}(C_{i})$, dove 
$\emph{FDH}_{n}()$ 
è l'hash del dominio completo sul dominio $n$.} In questa richiesta, il 
cliente si impegna anche con le chiavi pubbliche 
$T_{i}$. 
La richiesta è autorizzata mediante una firma effettuata con la chiave 
privata $c$.

Invece di restituire direttamente la firma cieca, la banca centrale 
chiede prima al cliente di dimostrare che ha utilizzato correttamente la 
costruzione di cui sopra fornendo 
$\gamma \in \left\{ 1,\ldots,\kappa \right\}$. 
Il cliente deve quindi mostrare alla banca centrale la 
$t_{i}$ per $i \neq \gamma$. 
La banca centrale può quindi calcolare 
$K_{i} \equiv \emph{KX}(C,t_{i})$ e ricavare i valori 
$(b_{i},c_{i})$. Se per tutte le 
$i \neq \gamma$ la $t_{i}$ fornita dimostra che il cliente ha utilizzato 
correttamente la costruzione, la banca centrale restituisce la firma 
cieca su $C_{\gamma}$. 
Se il cliente non fornisce una prova corretta, il valore residuo della 
moneta originale viene perso. Questo penalizza efficacemente coloro che 
tentano di eludere la trasparenza del reddito con un'aliquota fiscale 
stimata di $1 - \frac{1}{\kappa}$.

Per evitare che un cliente cospiri con un venditore che sta tentando di 
evadere il fisco, la banca centrale consente a chiunque 
conosca $C$ di ottenere, in qualsiasi momento, i valori di 
$T_{\gamma}$ 
e le firme cieche di tutte le monete collegate alla moneta originaria $C$. 
Ciò permette al possessore della moneta originaria, che conosce $c$, di 
calcolare 
$K_{\gamma} \equiv \emph{KX}( c,T_{\gamma})$ 
e da lì ricavare 
$(b_{i},c_{i})$ 
per, infine, rimuovere la firma cieca. Di conseguenza, un venditore che 
nasconde il proprio reddito in questo modo formerebbe solo un'accordo 
economico limitato con il cliente invece di ottenere il controllo esclusivo.

\hypertarget{architettura-del-sistema}{%
\subsection{Architettura del sistema}\label{architettura-del-sistema}}

Uno degli obiettivi principali della nostra architettura è garantire 
che le banche centrali non debbano interagire direttamente con i 
clienti né conservare alcuna informazione su di loro, ma solo tenere 
un elenco delle monete spese. L'autenticazione è delegata alle banche 
commerciali, che dispongono già dell'infrastruttura necessaria. I 
protocolli di prelievo e deposito raggiungono la banca centrale 
tramite una banca commerciale in qualità di intermediaria. Dal punto 
di vista del cliente, il processo è analogo al prelievo di contanti da 
un bancomat. La transazione tra la banca commerciale dell'utente e la 
banca centrale avviene in background. La procedura per il prelievo di 
CBDC è illustrata nel diagramma~\ref{fig:fig1}.

\begin{figure}[h!]
  \includegraphics[width=\textwidth]{diagramma1-it.png}
  \caption{Prelievo di CBDC}
  \label{fig:fig1}
\end{figure}

Il cliente (1) invia i dati di accesso alla propria banca commerciale 
utilizzando le relative procedure di autenticazione e autorizzazione. 
Quindi il telefono (o il computer) del cliente ottiene la chiave di 
valore pubblica $(e, n)$ fornita dalla banca centrale per quel valore; (2) 
calcola quindi una coppia di chiavi per la moneta, con una chiave 
privata $c$ e una chiave pubblica $C$, e sceglie un fattore di accecamento 
$b$. La chiave pubblica della moneta viene quindi sottoposta a hash 
($\to$ $f$) e accecata ($\to$ $f'$). Quindi il dispositivo del cliente (3) 
invia $f'$ insieme all'autorizzazione a prelevare la moneta e ad 
addebitarla dal conto del cliente presso la banca commerciale tramite un 
canale sicuro stabilito. La banca commerciale (4) addebita quindi  
l'importo dal conto deposito del cliente, (5) autorizza digitalmente la 
richiesta utilizzando la firma digitale specifica della propria filiale 
e inoltra la richiesta e la moneta accecata alla banca centrale per la 
firma. La banca centrale (6) sottrae il valore della moneta dal conto 
della banca commerciale, appone la firma cieca sulla moneta 
utilizzando la chiave privata che detiene per il relativo valore e (7) 
restituisce la firma cieca $s'$ alla banca commerciale. La banca 
commerciale (8) inoltra la firma cieca $s'$ al portafoglio elettronico 
del cliente. Infine, il dispositivo del cliente (9) utilizza $b$ per 
rimuovere l'accecamento dalla firma ($\to$ $f$) e salva la moneta appena 
coniata $(c, s)$.

Un cliente e un venditore negoziano un contratto commerciale. Il 
cliente (1) utilizza una moneta elettronica per firmare il contratto o 
l'atto di vendita con la chiave privata $c$ della moneta e trasmette la 
firma al venditore. La firma di una moneta su un contratto con una 
moneta valida è l'istruzione del cliente di pagare il venditore, che è 
identificato dal conto bancario nel contratto. Se una singola moneta 
non fosse sufficiente per coprire l'importo totale, i clienti possono 
firmare il contratto con più monete. Il venditore (2) convalida quindi 
la firma della moneta sul contratto e la firma $s$ della banca centrale 
su $f$, che  corrisponde a quella della moneta $C$ con le rispettive 
chiavi pubbliche, e inoltra la moneta firmata (insieme alle 
informazioni sul conto del venditore) alla banca commerciale del 
venditore. La banca commerciale del venditore (3) conferma che il 
venditore è un suo cliente e inoltra la moneta firmata alla banca 
centrale. La banca centrale (4) verifica le firme e controlla il 
proprio database per accertarsi che la moneta non sia già stata spesa. 
Se tutto è in ordine, la banca centrale (5) aggiunge la moneta 
all'elenco delle monete spese, l'accredita sul conto della banca 
commerciale presso la banca centrale e (6) invia una conferma in tal 
senso alla banca commerciale. Quindi la banca commerciale (7) 
accredita la moneta sul conto del venditore e (8) gli invia una 
notifica. Il venditore (9) consegna il prodotto o servizio al cliente. 
L'intera operazione richiede poche centinaia di millisecondi.

\begin{figure}[h!]
  \includegraphics[width=\textwidth]{diagramma2-it.png}
  \caption{Spendere e depositare CBDC}
  \label{fig:fig2}
\end{figure}

\hypertarget{considerazioni-sulla-sicurezza}{%
\subsection{Considerazioni sulla sicurezza}
\label{considerazioni-sulla-sicurezza}}

Nella nostra proposta, occorre che la banca centrale gestisca un 
database e un servizio online ad alta disponibilità. Poiché le monete 
elettroniche possono essere copiate dagli utenti, solo con i controlli 
online si può prevenire in modo efficace la doppia spesa. Sebbene 
nella teoria esistano soluzioni per identificare a posteriori gli 
utenti che effettuano una doppia spesa~\cite[vedi][]{Chaum1990}, 
queste soluzioni creano rischi economici sia per gli utenti che per la 
banca centrale a causa del ritardo nell'identificazione di 
transazioni fraudolente. Il rilevamento online della doppia spesa 
elimina questo rischio, ma significa anche che sarà impossibile 
effettuare le transazioni se la connessione Internet alla banca 
centrale non è disponibile.

La banca centrale dovrà anche proteggere la riservatezza delle chiavi 
private che utilizza per firmare le monete e altri messaggi di 
protocollo. Se le chiavi di firma della banca centrale dovessero 
essere compromesse, ad esempio da un computer quantistico, da un 
attacco fisico ai \textit{datacenter} o anche da qualche nuovo algoritmo 
imprevisto, è possibile rimborsare gli utenti --- in tutta sicurezza e 
senza compromettere la privacy --- tutte le monete non spese. La banca 
centrale annuncerebbe la revoca della chiave tramite l'\textit{Application 
Programming Interface} (API), che verrebbe rilevata dai portafogli, 
avviando quindi il seguente protocollo di aggiornamento: l'utente 
svela alla banca centrale la chiave pubblica $C$ della moneta, la firma 
$s$ della banca centrale e il fattore di accecamento $b$, consentendo così 
alla banca centrale di verificare il legittimo prelievo dell'utente e 
di rimborsare il valore della moneta non spesa. Per rilevare una 
possibile compromissione della propria chiave, la banca centrale può 
monitorare il database in cerca di depositi che eccedano i prelievi. 

\subsection{Scalabilità e costi}\label{scalabilità-e-costi}

Lo schema che proponiamo sarebbe efficiente ed economico quanto i 
moderni sistemi RTGS attualmente utilizzati dalle banche centrali.

La scalabilità si riferisce al costo di aumentare la potenza di 
calcolo in modo che si possa concludere un numero crescente di 
transazioni in tempi adeguati. Il costo complessivo del sistema può 
essere basso in quanto la CBDC qui proposta si basa interamente su 
software. Le monete spese devono essere conservate fino alla scadenza 
della coppia di chiavi di valore utilizzata per firmare le monete, ad 
esempio tramite un ciclo annuale continuo, che mantiene limitata la 
dimensione del database. La potenza di calcolo e la larghezza di banda 
necessarie aumentano della stessa quantità per ogni transazione, spesa 
o deposito addizionali, dato che le transazioni sono intrinsecamente 
indipendenti l'una dall'altra. Questa ulteriore potenza si ottiene 
semplicemente aggiungendo più hardware, una pratica spesso conosciuta 
come partizionamento o \textit{sharding}. Grazie al cosiddetto 
\textit{consistent hashing}, le aggiunte di hardware non risultano 
dirompenti. Si può anche utilizzare qualsiasi tipo di database.

Più nello specifico, la logica del \textit{front-end} presso la banca 
centrale deve solo eseguire poche operazioni di firma, e un singolo 
processore può eseguirne alcune migliaia al secondo~\cite[vedi][]{Bernstein2020}. 
Se un unico sistema non fosse sufficiente, è facile aggiungere altri 
server \textit{front-end} e invitare le varie banche commerciali a 
bilanciare le loro richieste nella \textit{server farm} o 
utilizzare un sistema di bilanciamento del carico per distribuire le 
richieste all'interno dell'infrastruttura della banca centrale.

I server \textit{front-end} devono comunicare con un database per 
effettuare le transazioni e prevenire la doppia spesa. Un unico server 
di database moderno dovrebbe essere in grado di gestire in modo 
affidabile decine di migliaia di operazioni al secondo. Le operazioni 
possono essere facilmente distribuite su più server di database 
semplicemente assegnando a ciascuno un intervallo di valori da 
gestire. Tale configurazione garantisce che le singole transazioni non 
incrocino mai le partizioni. Pertanto, anche i sistemi \textit{back-end} 
dovrebbero scalare in modo lineare con le risorse di calcolo messe a 
disposizione, partendo sempre da una solida base di riferimento per un 
singolo sistema.

I \textit{front-end} devono anche comunicare con i \textit{back-end} per 
mezzo di un'interconnessione. Queste interconnessioni possono 
supportare un gran numero di transazioni al secondo. La dimensione di 
una singola transazione è in genere di circa 1–10 kilobyte. Pertanto, 
i \textit{datacenter} di oggi, che scambiano informazioni a 400 Gbit/s, 
possono supportare milioni di transazioni al secondo.

Infine, il costo totale del sistema è basso. Probabilmente il costo
principale sia rappresentato dall'archiviazione sicura per 
molti anni di 1–10 kilobyte per transazione. Gli esperimenti su un 
prototipo di GNU Taler che utilizzava i prezzi di \textit{Amazon Web Service} 
hanno stabilito che il costo del sistema (archiviazione, larghezza di 
banda e capacità di calcolo) su larga scala sarebbe inferiore a 
0,0001 USD per transazione (per i dettagli sui dati, si veda~\citet{Dold}).

% In the reference for Dold, the year 2019 should be either not between parentesis 
% or there should be a comma after Dold: Dold, 2019. 

\section{Considerazioni normative e politiche}
    \label{5.-considerazioni-normative-e-politiche}

Nella soluzione che proponiamo, la banca centrale non conosce  
l'identità dei consumatori o dei venditori né l'importo totale delle 
transazioni, ma vede solo il momento in cui le monete elettroniche vengono 
rilasciate e quando vengono riscattate. Le banche commerciali continuano a 
fornire l'autenticazione cruciale di consumatori e venditori e, in particolare, 
custodiscono le informazioni che acquisiscono per la conoscenza dei clienti 
(KYC). Le banche commerciali osservano quando i venditori ricevono fondi e, se 
necessario, possono limitare la quantità di CBDC per transazione che 
un singolo venditore può ricevere. Inoltre, le transazioni sono 
collegate ai relativi contratti con i clienti. La conseguente 
trasparenza del reddito  consente al sistema di soddisfare i requisiti 
delle normative sulla lotta al riciclaggio di denaro e al 
finanziamento del terrorismo (AML e CFT). In caso vengano rilevate 
anomalie nei redditi dei venditori, la banca commerciale e 
l'autorità fiscale o giudiziaria possono ottenere e ispezionare i 
contratti relativi ai pagamenti sospetti al fine di verificarne la 
legittimità. La trasparenza del reddito risultante è anche una forte 
misura contro l'evasione fiscale perché i venditori non possono 
sottodichiarare il proprio reddito o evadere le tasse sulle vendite. 
Nel complesso, il sistema implementa gli approcci \textit{privacy-by-
design} e \textit{privacy-by-default} (come richiesto, ad esempio, 
dal Regolamento generale sulla protezione dei dati dell'UE, GDPR). I 
venditori non apprendono necessariamente l'identità dei propri clienti, 
le banche possiedono solo le informazioni necessarie sulle attività dei 
propri clienti e la banca centrale non ha accesso ai dettagli sulle 
attività dei cittadini.

In alcuni paesi le normative impongono limiti per i prelievi e i 
pagamenti in contanti. Tali restrizioni possono essere implementate 
anche per la CBDC nel progetto proposto. Ad esempio, è possibile 
stabilire una soglia per l'importo giornaliero che i consumatori possono 
prelevare, oppure limitare l'importo totale di CBDC che le banche 
commerciali possono convertire.

La disintermediazione del settore bancario è uno dei rischi di 
instabilità finanziaria spesso sollevato per quanto riguarda la BCDC 
al dettaglio. In particolare, una CBDC al dettaglio potrebbe 
facilitare l'accumulo di ingenti somme di denaro della banca 
centrale, il che potrebbe avere un impatto negativo sul finanziamento 
alle banche mediante depositi perché il pubblico deterrebbe meno 
denaro sotto forma di depositi bancari. Per i paesi le cui valute 
fungono da valute rifugio, ciò potrebbe anche portare ad un aumento 
degli afflussi di capitali durante i periodi globali di avversione al 
rischio, dando luogo ad ulteriori pressioni sui tassi di cambio. 
Quello che quindi potrebbe rappresentare un serio problema nel caso di 
una CBDC basata su conti, lo sarebbe molto meno con una CBDC basata 
su token. Innanzitutto, l'accumulo di una CBDC basata su token comporta 
rischi di furto o perdita simili a quelli legati all'accumulo di 
contanti. Tenere poche centinaia di dollari su uno smartphone è 
probabilmente un rischio accettabile per molti, ma detenere una somma 
molto alta è probabilmente un rischio meno accettabile. Pertanto, non 
ci aspettiamo un accaparramento significativamente maggiore rispetto a 
quello del denaro fisico.

Tuttavia, se l'accumulo o la massiccia conversioni dei depositi 
bancari in CBDC dovessero destare proccupazione, la banca centrale 
avrebbe diverse opzioni. Come si è spiegato, secondo il progetto 
proposto le banche centrali fissano una data di scadenza per tutte le 
chiavi di firma, il che implica che in una data prestabilita le monete 
firmate con quelle chiavi diventano non valide. Alla scadenza delle 
chiavi di valore, i consumatori devono scambiare con monete nuove le 
monete che erano state firmate con le vecchie chiavi; l'autorità di 
regolamentazione può facilmente fissare una soglia di conversione per 
cliente per creare un limite rigido alla quantità di CBDC che ogni 
individuo può accumulare. Inoltre, la banca centrale potrebbe addebitare 
commissioni, se necessario. Una commissione di aggiornamento quando le monete 
stanno per scadere significherebbe nella pratica tassi di interesse negativi 
sulla CBDC per limitare il suo fascino come riserva di valore, come 
suggerisce~\cite{Bindseil}. Si tratterebbe infatti della diretta attuazione 
dell'idea di Silvio Gesell di applicare una tassa di possesso sulla moneta, 
notoriamente citata da~\cite{Keynes} e ripresa da~\cite{Goodfriend}, 
\cite{Buiter}, e~\cite{Agarwal}.

Per quanto riguarda le implicazioni in termini di politica monetaria, 
non dovrebbero esserci cambiamenti reali perché la nostra CBDC è 
progettata per replicare il contante piuttosto che i depositi bancari. 
L'emissione, il prelievo e il deposito della nostra CBCD corrispondono 
esattamente all'emissione, al prelievo e al deposito di banconote. È 
possibile che la velocità di circolazione di una CBDC al dettaglio sia 
diversa da quella del contante fisico, ma questo non dovrebbe 
rappresentare un problema significativo per la politica monetaria.

\hypertarget{lavori-correlati}{%
\section{Lavori correlati}\label{6.-lavori-correlati}}

Come segnalato in precedenza, la CBDC che si propone in questo documento 
si basa su eCash e GNU Taler.\footnote{L'implementazione di eCash 
da parte della società DigiCash negli anni novanta è documentata su 
\url{https://www.chaum.com/ecash}.} A partire dalla proposta originale 
e-Cash di Chaum, la ricerca si è concentrata su tre questioni principali. 
In primo luogo, nella proposta originale di Chaum le monete avevano un 
valore fisso e potevano essere spese solo nella loro totalità. Pagare 
grandi somme con monete denominate in centesimi sarebbe stato poco 
efficiente; quindi~\cite{Okamoto}, \cite{Camenisch2005}, \cite{Canard} 
e~\cite{Dold} idearono modi per affrontare il problema. Queste soluzioni 
comprendono protocolli per dare il resto o rendere divisibili le monete.

Un secondo problema riguarda gli errori nelle transazioni dovuti ad 
interruzioni della rete. In questo caso, il sistema deve garantire che 
i fondi rimangano in possesso del consumatore senza pregiudicare la 
privacy. L'\textit{Endorsed E-Cash} proposto da~\cite{Camenisch2007}, 
così come da~\cite{Dold}, affrontano entrambi questo problema. Molte 
delle soluzioni violano le garanzie sulla privacy per i clienti che 
utilizzano queste funzionalità e tutte, tranne Taler, violano il 
requisito della trasparenza del reddito.

La terza questione importante, spesso trascurata, è la trasparenza del 
reddito e quindi la conformità con i requisiti AML e KYC. \cite{Fuchsbauer} 
hanno deliberatamente progettato il loro sistema di disintermediazione 
per fornire una semantica più simile al contante. Tuttavia, la 
disintermediazione totale è in genere difficile da concialiare con le 
normative AML e KYC dato che diventa impossibile raggiungere qualsiasi 
livello di responsabilità. Un esempio di tale architettura è ZCash, un 
registro distribuito (\textit{ledger}) che nasconde dalla rete le 
informazioni sul pagatore, sul beneficiario e sull'importo della 
transazione, rendendolo quindi il sistema di pagamento perfetto per la 
criminalità online. Solo Taler offre sia una privacy costante per i 
clienti che la trasparenza del reddito, fornendo al contempo un sistema 
di resto efficiente, scambi atomici~\cite[vedi][]{Camenisch2007} e la 
possibilità di ripristinare i portafogli dal backup.

Per quanto riguarda i sistemi di pagamento per le CBDC, \cite{Danezis} 
hanno progettato un \textit{ledger} scalabile per RSCoin. Si tratta 
fondamentalmente di un sistema RTGS che viene protetto utilizzando la 
stessa crittografia che si usa in Bitcoin. Come Taler, il design utilizza 
il \textit{sharding} del database per consentire la scalabilità lineare. 
Tuttavia, la soluzione di Danezis e Meiklejohn non prevede alcuna 
disposizione per la privacy e manca di elementi per l'integrazione 
pratica del design con i sistemi e i processi bancari esistenti.

L'EUROchain della Banca Centrale Europea\cite[vedi][]{ECB} è un altro 
prototipo di CBDC con registro distribuito. Simile all'architettura 
proposta in questo documento, EUROchain utilizza un'architettura a due 
livelli in cui le banche commerciali agiscono come intermediari. Una 
differenza cruciale è il modo in cui i sistemi cercano di combinare 
privacy e conformità con la normativa antiriciclaggio (AML). Mentre nel 
nostro progetto l'autorità di regolamentazione può imporre un limite 
alla somma di denaro elettronico che un titolare di conto bancario può 
prelevare in un determinato periodo di tempo, EUROchain emette un numero 
limitato di «voucher di anonimato» che garantiscono al destinatario un 
numero limitato di transazioni senza controlli AML. Poiché questi voucher 
sembrano essere privi di qualsiasi token di valore, non è chiaro come 
il design possa impedire l'emergere di un mercato nero per i «voucher 
di anonimato». Inoltre, la nozione di anonimato di EUROchain è molto 
diversa, in quanto i loro «voucher di anonimato» eliminano solo alcuni 
controlli AML, preservando la capacità delle banche commerciali di 
sapere in che modo i clienti spendono il denaro elettronico. Laddove chi 
paga utilizzando Taler interagisce direttamente con i venditori per 
spendere il proprio contante elettronico, il sistema EUROchain chiede 
ai pagatori di istruire le proprie banche commerciali per accedere alle 
CBDC. Pertanto, EUROchain non emette direttamente token di valore ai 
consumatori, affida invece ai consumatori il compito di autenticarsi 
presso la propria banca commerciale per accedere alle CBDC che la 
banca centrale detiene effettivamente in deposito a garanzia. Non è 
quindi evidente quali siano i vantaggi di EUROchain in termini di 
privacy, prestazioni o sicurezza rispetto all'attuale denaro in deposito.

\section{Conclusione}\label{7.-conclusione}

Con l'emergere di Bitcoin e valute digitali come Diem (già nota come 
Libra) recentemente proposte dai colossi del web, le banche centrali 
affrontano una crescente concorrenza da parte di operatori privati che 
offrono la propria alternativa digitale al contante fisico. Le decisioni 
delle banche centrali sull'emissione o meno di una CBDC dipendono dalla 
loro valutazione dei benefici e dei rischi di una CBDC. È probabile che 
questi vantaggi e rischi, nonché le circostanze giurisdizionali 
specifiche che definiscono l'ambito di applicazione di una CBDC al 
dettaglio, differiscano da un paese all'altro.

Se una banca centrale decide di emettere una CBDC al dettaglio, 
proponiamo una CBDC basata su token che combina la privacy delle 
transazioni con la conformità alle normative KYC, AML e CFT. Tale CBDC 
non sarebbe in concorrenza con i depositi presso le banche commerciali, 
replicherebbe piuttosto il contante fisico, limitando quindi i rischi di 
stabilità finanziaria e di perturbazione della politica monetaria.

Abbiamo dimostrato che lo schema qui proposto sarebbe efficiente ed 
economico quanto i moderni sistemi RTGS gestiti dalle banche centrali. 
I pagamenti elettronici con la nostra CBDC richiederebbero solo un 
semplice database e minuscole quantità di larghezza di banda per le 
transazioni. L'efficienza e l'economicità di questa soluzione, insieme 
alla maggiore facilità d'uso da parte del consumatore determinata dal 
passaggio dall'autenticazione all'autorizzazione, rendono questo schema 
probabilmente il primo a supportare l'annoso obiettivo dei micropagamenti 
online. Inoltre, l'uso di monete per firmare crittograficamente contratti 
elettronici consente anche l'impiego di contratti intelligenti. Ciò 
potrebbe anche portare all'emergere di applicazioni completamente nuove 
per i sistemi di pagamento. Sebbene il nostro sistema non sia basato su 
DLT, può essere facilmente integrato con tali tecnologie se richiesto 
dalle future infrastrutture del mercato finanziario.

Altrettanto importante, una CBDC al dettaglio deve rimanere, come il 
contante fisico, un bene rispettoso della privacy sotto il controllo 
individuale dei cittadini. Lo schema proposto in questo studio soddisfa 
questo criterio e consente alle banche centrali di evitare gravi sfide 
alla loro politica monetaria e alla stabilità finanziaria sfruttando al 
contempo i vantaggi del passaggio al digitale.

\newpage
\bibliographystyle{agsm}
\bibliography{cbdc}

\end{document}