diff options
Diffstat (limited to 'doc/cbdc-it/cbdc-it.tex')
| -rw-r--r-- | doc/cbdc-it/cbdc-it.tex | 2056 |
1 files changed, 1024 insertions, 1032 deletions
diff --git a/doc/cbdc-it/cbdc-it.tex b/doc/cbdc-it/cbdc-it.tex index a6bc0c5a..693dc307 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 |