-corrections from Dora

1 files changed, 1024 insertions, 1032 deletions

diff --git a/doc/cbdc-it/cbdc-it.tex b/doc/cbdc-it/cbdc-it.tex
index a6bc0c5ac..693dc3070 100644
--- a/doc/cbdc-it/cbdc-it.tex
+++ b/doc/cbdc-it/cbdc-it.tex
@@ -1,4 +1,4 @@
-% The Spanish pdf looks too crowded. For Italian, maybe bigger font 
+% The Spanish pdf looks too crowded. For Italian, maybe bigger font
 % and/or extra space between lines/paragraphs?
 
 %\renewcommand{\abstractname}{Sommario}
@@ -17,53 +17,55 @@
   xx Network \and
   Christian Grothoff\footnote{christian.grothoff@bfh.ch} \\
   BFH\footnote{Università di Scienze Applicate di Berna}
-  \quad e Progetto GNU \and
+  \ 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 
+\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, 
+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 
+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
@@ -73,854 +75,844 @@ Traduzione: Dora Scilipoti \& Luca Saiu
 
 \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 
+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 
+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 
+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 
+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 
+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 
+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). 
+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 
+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, è 
+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 
+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 
+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 
+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 
+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 è 
+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 
+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 
+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 
+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 
+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 
+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 
+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 
+È 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 
+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 
+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 
+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 
+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 
+% References to Kumhof, Bindseil below should render like this:
+% valore (Kumhof & Noone, 2018 e Bindseil, 2020).
+\bibpunct{(}{)}{ e }{a}{}{,}
+
+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).
+% Back to default style.
+\bibpunct{(}{)}{ e }{,}{}{,}
 
-% 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 
+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 
+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 
+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 
+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 
+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 
+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 
+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 
+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, 
+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 
+\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 
+
+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 
+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 
+\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: 
+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 
+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 
+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 
+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 
+\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 
+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 
+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 
+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 
+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 
+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 
+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 
+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 
+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!]
@@ -929,51 +921,51 @@ CBDC è illustrata nel diagramma~\ref{fig:fig1}.
   \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 
+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. 
+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!]
@@ -986,295 +978,295 @@ L'intera operazione richiede poche centinaia di millisecondi.
 \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 
+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. 
+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 
+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 
+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 
+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 
+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, 
+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 
+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. 
+% 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. 
+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 
+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 
+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 
+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}, 
+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 
+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 
+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 
+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 
+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 
+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 
+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 
+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 
+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 
+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 
+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