diff options
Diffstat (limited to 'doc/cbdc-it/cbdc-it.tex')
| -rw-r--r-- | doc/cbdc-it/cbdc-it.tex | 1262 |
1 files changed, 1262 insertions, 0 deletions
diff --git a/doc/cbdc-it/cbdc-it.tex b/doc/cbdc-it/cbdc-it.tex new file mode 100644 index 00000000..e240c336 --- /dev/null +++ b/doc/cbdc-it/cbdc-it.tex @@ -0,0 +1,1262 @@ +% The Spanish pdf looks too crowded. For Italian, maybe bigger font +% and/or extra space between lines/paragraphs? + +%\renewcommand{\abstractname}{Sommario} +%\renewcommand{\refname}{Opere di consultazione} + +\documentclass{article} +\usepackage[T1]{fontenc} +\usepackage{url} +\usepackage{amsmath} +\usepackage{hyperref} +\usepackage{graphicx} +\usepackage{natbib} +\usepackage[italian]{babel} +\title{Come emettere una moneta digitale di banca centrale} +\author{David Chaum\footnote{david@chaum.com} \\ + xx Network \and + Christian Grothoff\footnote{christian.grothoff@bfh.ch} \\ + BFH\footnote{Università di Scienze Applicate di Berna} + \quad e Progetto GNU \and + Thomas Moser\footnote{thomas.moser@snb.ch} \\ + Banca Nazionale Svizzera} +\date{Questa versione: febbraio 2022 \\ + Prima versione: maggio 2020} + +\begin{document} + +\maketitle + +\begin{abstract} +Con l'emergere di Bitcoin e delle criptovalute stabili (per es. Diem, +già nota come Libra) recentemente proposte dai colossi del web, le +banche centrali affrontano una crescente concorrenza da parte di +operatori privati che offrono la propria alternativa digitale al +contante fisico. Non trattiamo qui la questione normativa se una banca +centrale debba emettere o meno una moneta digitale. Contribuiamo invece +all'attuale dibattito di ricerca spiegando in che modo una banca centrale +potrebbe farlo, se lo volesse. Proponiamo un sistema basato su token +senza tecnologia di registro distribuito, e mostriamo che le monete +elettroniche emesse in passato, basate solo su software, possono essere +migliorate per tutelare la privacy nelle transazioni, soddisfare i +requisiti normativi in modo efficace e offrire un livello di protezione +resistente ai computer quantistici contro il rischio sistemico per +la privacy. Né la politica monetaria né la stabilità del sistema +finanziario sarebbero realmente interessate da questo sistema dal +momento che una CBDC emessa in questo modo replicherebbe il contante +fisico anziché i depositi bancari. \\ + +JEL: E42, E51, E52, E58, G2 +\\ + +Parole chiave: monete digitali, banca centrale, CBDC, firma cieca, +criptovalute stabili, \textit{stablecoins} +\end{abstract} + +\vspace{40pt} + +\section*{Ringraziamenti} +Vorremmo ringraziare Michael Barczay, Roman Baumann, Morten Bech, +Nicolas Cuche, Florian Dold, Andreas Fuster, Stefan Kügel, Benjamin +Müller, Dirk Niepelt, Oliver Sigrist, Richard Stallman, Andreas Wehrli +e tre collaboratori anonimi per i loro commenti e suggerimenti. Le +posizioni, le opinioni, i risultati e le conclusioni o raccomandazioni +espresse in questo documento sono strettamente quelle degli autori. +Non riflettono necessariamente le posizioni della Banca nazionale +svizzera (BNS). La BNS declina ogni responsabilità per eventuali +errori, omissioni o inesattezze che dovessero comparire nel documento. + +Traduzione: Dora Scilipoti \& Luca Saiu +\newpage + +%\tableofcontents + +\section{Introduzione}\label{1.-introduzione} + +Dall'avvento dei personal computer negli anni ottanta, e più +specificamente da quando nel 1991 la \textit{National Science +Foundation} revocò le restrizioni sull'uso di Internet per scopi +commerciali, c'è stata una ricerca sulla creazione di moneta digitale +per i pagamenti online. La prima proposta è stata quella +di~\cite{Chaum1983}. Sebbene tali metodi siano stati attuati, non hanno +preso piede; le carte di credito sono invece diventate il metodo più +diffuso per i pagamenti online. La proposta di~\cite{Nakamoto} per una +versione puramente \textit{peer-to-peer} di moneta digitale e il +conseguente lancio di Bitcoin avvenuto con successo hanno inaugurato +una nuova era di ricerca e sviluppo di valute digitali. La piattaforma +CoinMarketCap elenca oltre 5.000 criptovalute. Recentemente le banche +centrali hanno iniziato a considerare, o almeno a studiare, +l'emissione di monete +digitali~\cite[vedi][]{AuerBoehme,AuerCornelli,Boar,Kiff,Mancini-Griffoli}. + +Attualmente le banche centrali emettono due tipi di moneta: (i) +riserve sotto forma di conti di regolamento presso le banche centrali, +destinate solo agli operatori dei mercati finanziari, e (ii) divisa +disponibile per tutti sotto forma di banconote. Di conseguenza, la +letteratura sulla moneta digitale di banca centrale (\textit{Central Bank +Digital Currency} - CBDC) distingue tra (a) CBDC all'ingrosso ad +accesso ristretto e (b) CBDC al dettaglio disponibile per il +pubblico~\cite[si veda, ad esempio,][]{Bech}. +Una CBDC all'ingrosso sarebbe meno destabilizzante per il sistema attuale +dato che le banche e gli operatori dei mercati finanziari hanno già +accesso alla moneta digitale della banca centrale sotto forma di conti +presso questa istituzione, che utilizzano per regolare i pagamenti +interbancari. La domanda qui è se la tokenizzazione della moneta di banca +centrale e la tecnologia di registro distribuito (\textit{Distributed Ledger +Technology} - DLT) offrano vantaggi particolari rispetto ai sistemi con +regolamento lordo in tempo reale (\textit{Real-Time Gross Settlement} - RTGS) +esistenti. Finora la risposta è negativa, almeno per i pagamenti +interbancari nazionali~\cite[vedi][]{Chapman}. + +Una CBDC al dettaglio, che sarebbe una nuova forma di moneta di banca +centrale disponibile per il pubblico, potrebbe essere più destabilizzante +per il sistema attuale, a seconda di come è progettata. Più una CBDC +compete con i depositi delle banche commerciali, maggiore è la minaccia +ai finanziamenti bancari, con effetti potenzialmente negativi sul credito +bancario e sull'attività economica~\cite[vedi][]{Agur}. Tuttavia, una +CBDC al dettaglio potrebbe anche essere vantaggiosa~\cite[vedi][]{Bordo,Berentsen,Bindseil,Niepelt,Riksbank,BoE}. +Mettere a disposizione di tutti una moneta elettronica di banca centrale +esente dal rischio di controparte potrebbe migliorare la stabilità e la +resilienza del sistema di pagamenti al dettaglio. Potrebbe inoltre fornire +un'infrastruttura di pagamento neutrale per incoraggiare la concorrenza, +l'efficienza e l'innovazione. Nel complesso, è probabile che i costi e i +benefici di una CBDC al dettaglio differiscano da un paese all'altro. Per +il punto di vista della Banca nazionale svizzera, che non ha in programma +l'emissione di una CBDC al dettaglio,~\cite[si veda][]{Jordan}. + +Nel presente documento analizziamo la CBDC al dettaglio, ma senza +affrontare la questione se una banca centrale \emph{debba o meno} emetterla. +Ci concentriamo invece sul possibile design di una CBCD. L'interesse +per la progettazione di CBDC è recentemente aumentato +considerevolmente (\cite[si, veda ad esempio,][]{Allen,BoE}). Il design che +proponiamo differisce notevolmente da altre proposte. Il nostro sistema +si basa sulla tecnologia eCash descritta da~\cite{Chaum1983,Chaum1990}, +migliorandola. In particolare, proponiamo una CBDC basata su token, solo +con software e senza tecnologia di registro distribuito. La DLT è +un'architettura interessante in assenza di un operatore centrale o se le +entità che interagiscono non accettano di nominare un operatore centrale +fidato. Questo non è certo il caso di una CBDC al dettaglio emessa da una +\emph{banca centrale}. Distribuire il registro delle transazioni della +banca centrale con una \textit{blockchain} non fa che aumentare i costi +di transazione; non porta alcun vantaggio tangibile nell'implementazione +da parte di una banca centrale. L'utilizzo della DLT per emettere moneta +digitale può essere utile in assenza di una banca centrale (ad esempio, +il progetto Sovereign delle Isole Marshall) o se l'intenzione esplicita +è quella di fare a meno di una banca centrale (ad esempio, +Bitcoin).\footnote{Potrebbero esserci casi opportuni di utilizzo della +DLT per le infrastrutture dei mercati finanziari, come gli scambi digitali, +dove sorge la questione di come incorporare la moneta della banca centrale +all'interno di una struttura DLT per eseguire i regolamenti. Tuttavia, +in tali situazioni i potenziali benefici della DLT, ad esempio costi +inferiori o riconciliazione automatica, non derivano da un'emissione +decentralizzata di moneta di banca centrale.} + +La CBDC basata su token che proponiamo consente anche di preservare +una caratteristica fondamentale del contante fisico: la privacy nelle +transazioni. Spesso si sostiene che l'uso della crittografia per la +tutela della privacy richieda così tanta potenza di calcolo da rendere +impraticabile la sua implementazione su dispositivi +portatili~\cite[vedi][]{Allen}. Sebbene questo possa essere vero nel +caso di una tecnologia di registro distribuito, dove la tracciabilità +delle transazioni è necessaria per prevenire la doppia spesa~\cite{Narayanan}, +non lo è nel caso proposto in questo documento, dove si ha un protocollo +di firma cieca di tipo Chaum e la partecipazione di una banca centrale. +La nostra CBDC, basata su firme cieche e un'architettura a due livelli, +garantisce una tutela della privacy nelle transazioni perfetta e +quanto-resistente, fornendo al contempo protezioni sociali che sono di +fatto più potenti rispetto a quelle delle banconote per la lotta al +riciclaggio di denaro (\textit{Anti-Money Laundering} - AML) e al +finanziamento del terrorismo (\textit{Counter Terrorism Financing} - CFT). + +La privacy nelle transazioni è importante per tre motivi. In primo luogo, +protegge gli utenti dal potenziale abuso di monitoraggio e sorveglianza +da parte dei governi. Anche se si pensa di non avere nulla da nascondere, +i piani di sorveglianza di massa restano problematici, se non altro per +il rischio di errori e abusi, soprattutto se condotti senza trasparenza +e responsabilità~\cite[vedi][]{Solove}. In secondo luogo, la privacy nelle +transazioni protegge gli utenti dallo sfruttamento dei dati da parte dei +fornitori di servizi di pagamento. Infine, salvaguarda gli utenti dalla +controparte nelle transazioni in quanto esclude possibili comportamenti +opportunistici successivi o rischi per la sicurezza dovuti a negligenza +o mancata protezione dei dati dei clienti~\cite[vedi][]{Kahn2005}. + +Questo documento è strutturato come segue: nella Sezione II si spiega +la differenza tra la moneta di banca centrale e altri tipi di moneta. +Nella Sezione III si esaminano i modelli di CBDC tipici e generici prima +di proporre il nostro progetto nella Sezione IV. Si considerano poi +gli aspetti normativi e le politiche (V) e il relativo lavoro (VI). +Infine, si conclude (VII). + + +\section{Cos'è la moneta di banca centrale?} + \label{2.-cos'è-la-moneta-di-banca-centrale} + +La moneta è un attivo che può essere utilizzato per acquistare beni e +servizi. Per essere considerato moneta, l'attivo deve essere accettato +da entità diverse dall'emittente. Ecco perché i voucher, ad esempio, +non sono considerati moneta. La moneta autentica deve essere +\emph{comunemente} accettata come mezzo di scambio. Sebbene la moneta +abbia altre funzioni, ad esempio come unità di conto e riserva di valore, +la sua caratteristica distintiva è la sua funzione di mezzo di scambio. +Normalmente l'unità di conto (cioè come avvengono la fissazione dei +prezzi e la contabilizzazione dei debiti) coincide per ragioni +pratiche con il mezzo di scambio. Una separazione può tuttavia +verificarsi se il valore del mezzo di scambio manca di stabilità +rispetto ai beni e servizi scambiati.\footnote{Ciò può accadere +spontaneamente in un ambito caratterizzato da un'inflazione elevata, +ad esempio quando i prezzi sono quotati in USD ma i pagamenti vengono +effettuati in valuta locale. Lo stesso vale per i pagamenti in Bitcoin, +dove i prezzi sono solitamente fissati in USD o altre valute locali a +causa dell'elevata volatilità del Bitcoin. Una separazione può anche +essere progettata appositamente, come nel caso +dell'\textit{Unidad de Fomento} (UF) in Cile o i Diritti Speciali di +Prelievo (DSP) del Fondo Monetario Internazionale (FMI). Tuttavia, +anche in questi casi lo scopo è quello di avere un'unità di conto più +stabile.} La moneta deve anche essere una riserva di valore per fungere +da mezzo di scambio perché deve preservare il suo potere d'acquisto tra +il momento in cui si riceve e quello in cui si spende. In ogni modo, +ci sono molti altri attivi che fungono da riserva di valore, come azioni, +obbligazioni, metalli preziosi e immobili. Pertanto, la caratteristica +di riserva di valore non è distintiva della moneta. + +In un'economia moderna, il pubblico utilizza due tipi diversi di +moneta: (a) moneta statale e (b) moneta privata. La moneta statale viene +generalmente emessa dalla banca centrale, che agisce in qualità di +agente dello Stato. La moneta della banca centrale è disponibile per +alcune istituzioni finanziarie sotto forma di depositi presso la banca +centrale (riserve) e per il pubblico sotto forma di valuta (banconote e +monete), nota anche come «contante». In una economia moderna con valuta +fiat, tale moneta non ha un valore intrinseco. Legalmente è una passività +della banca centrale, sebbene non sia rimborsabile. Nella maggior parte +dei paesi, la moneta della banca centrale è definita come avente corso +legale, il che significa che deve essere accettata per il pagamento dei +debiti monetari, comprese le tasse e le sanzioni legali. Sebbene ciò +garantisca un certo valore alla moneta della banca centrale, lo status +di corso legale non è sufficiente per mantenere un valore stabile. È la +politica monetaria della banca centrale che mantiene il valore della +moneta. Mantenere la stabilità dei prezzi, vale a dire un valore stabile +della moneta rispetto a quello dei beni e dei servizi scambiati, è +infatti una delle principali responsabilità delle banche centrali. + +La maggior parte dei pagamenti in un'economia moderna vengono effettuati +con moneta privata emessa dalle banche commerciali ed è costituita da +depositi bancari a vista che le persone detengono presso queste banche. +Sono depositi che si posssono utilizzare mediante assegni, carte di +debito, carte di credito e altri mezzi di trasferimento di denaro e +costituiscono una passività della banca commerciale di riferimento. Una +caratteristica fondamentale di questi depositi è che le banche commerciali +garantiscono la convertibilità su richiesta in moneta della banca centrale +ad un prezzo fisso, vale a dire, alla pari. I depositanti possono prelevare +i propri fondi in contante o trasferirli ad un valore fisso di 1:1. Le +banche commerciali mantengono stabile il valore della propria moneta +ancorandola a quella della banca centrale. + +Tuttavia, in un sistema di riserva frazionaria, una banca commerciale, +anche se solvibile, potrebbe non avere liquidità a sufficienza per +onorare la sua promessa di convertire i depositi bancari in moneta +della banca centrale (ad esempio, nel caso di una corsa agli sportelli) +in modo tale che i clienti non possano prelevare i propri soldi. Una +banca può anche diventare insolvente e fallire, e di conseguenza i +clienti possono perdere denaro. Per questo motivo le banche commerciali +sono soggette a regolamentazioni volte a mitigare tali rischi. + +Una differenza notevole tra la moneta di una banca centrale e la +moneta privata emessa da una banca commerciale è, pertanto, che +quest'ultima comporta un rischio di controparte. Una banca centrale +può sempre adempiere ai suoi obblighi utilizzando la propria moneta +non rimborsabile. In un'economia nazionale, la moneta della banca +centrale è l'unico attivo monetario esento da rischi di credito e di +liquidità. È pertanto l'attivo tipicamente preferito per regolare i +pagamenti nelle infrastrutture dei mercati finanziari (si veda, per +esempio, \textit{CPMI-IOSCO Principles for Financial Market +Infrastructures}, 2012). Un'altra differenza risiede nella capacità +della moneta della banca centrale di sostenere il sistema monetario +nazionale fornendo un valore di riferimento con cui la moneta delle +banche commerciali mantiene la piena convertibilità. + +A parte le banche commerciali, altre entità private tentano +occasionalmente di emettere moneta; le criptovalute sono solo il +tentativo più recente. Ma a differenza dei depositi bancari, tale +moneta non è comunemente accettata come mezzo di scambio. Questo vale +anche per Bitcoin, la criptovaluta più ampiamente accettata. Un +ostacolo all'utilità delle criptovalute come mezzo di scambio è l'elevata +volatilità del loro valore. In risposta a questo problema sono emerse +le criptovalute stabili, cosiddette «stablecoins». Le +\textit{stablecoin} generalmente tentano di stabilizzare il proprio +valore in due modi: imitando le banche centrali (\textit{stablecoin} +algoritmiche) o imitando le banche commerciali e strumenti di +investimento (\textit{stablecoin} ancorate ad attivi).\footnote{Per una +tassonomia delle \textit{stablecoin}, si veda~\cite{Bullmann}.} + +Le «\textit{stablecoin} algoritmiche» si basano su algoritmi per regolare +l'offerta della moneta. In altre parole, cercano di stabilizzarne il +prezzo attraverso una «politica monetaria algoritmica». Esistono +esempi di tali \textit{stablecoin} (per es. Nubits), ma finora nessuna è +riuscita a stabilizzare il proprio valore per molto tempo. + +Le \textit{stablecoin} «ancorate ad attivi» differiscono in base al tipo +di attivo che utilizzano e ai diritti concessi ai possessori. I tipi di +attivi generalmente utilizzati sono: valuta (riserve di banche centrali, +banconote o depositi presso banche commerciali), materie prime (come +l'oro), titoli e talvolta altre criptovalute. La capacità di un tale +schema di stabilizzare il valore della moneta rispetto agli attivi +sottostanti dipende in modo cruciale dai diritti legali acquisiti dai +detentori della moneta. Se una \textit{stablecoin} è riscattabile ad un +prezzo fisso (ad esempio, 1 moneta = 1 USD o 1 moneta = 1 oncia d'oro), +la stabilità si può teoricamente ottenere.\footnote{Se possa stabilizzare +il valore della \textit{stablecoin} anche rispetto ai beni e servizi +scambiati dipende essenzialmente da quanto sia stabile il valore degli +attivi su cui poggia rispetto al valore dei beni e servizi.} Tale strategia +riproduce essenzialmente quella delle banche commerciali garantendo la +convertibilità nell'attivo sottostante su richiesta. Tuttavia, a differenza +dei depositi bancari, che in genere sono coperti solo parzialmente dalle +riserve della banca centrale, le \textit{stablecoin} sono spesso +completamente garantite dalle riserve di attivi sottostanti al fine di +evitare il rischio di liquidità, principalmente perché non dispongono di +tutele pubbliche tali come l'assicurazione dei depositi e il prestatore +di ultima istanza che offrono invece le banche regolamentate. + +Le \textit{stablecoin} che utilizzano le valute come attivi sono anche +dette «stablecoin a valuta fiat». Detenere il 100\% delle +garanzie sotto forma di valuta (banconote o depositi bancari) non risulta però +molto redditizio. Di conseguenza, i fornitori di \textit{stablecoin} hanno +un buon motivo per rispiarmiare sugli attivi passando ad un sistema di +riserva frazionaria, proprio come hanno fatto le banche +commerciali.\footnote{L'incertezza sulla garanzia delle +\textit{stablecoin} può essere uno dei motivi per cui vengono scambiate +al di sotto del loro valore nel mercato parallelo~\cite[vedi][]{Lyons}. +Casi simili si sono storicamente verificati anche con le banconote, quando +erano ancora emesse dalle banche commerciali. Le banconote venivano +scambiate a prezzi scontati nel mercato parallelo prima che l'emissione +fosse nazionalizzata e trasferita alle banche centrali come monopolio.} +Ciò comporta la riduzione degli attivi meno redditizi al minimo ritenuto +necessario per soddisfare il requisito di convertibilità e l'aumento +degli attivi liquidi a rendimento più elevato come i titoli di stato. +Questo migliora la redditività ma aumenta nel contempo il livello +di rischio. Tuttavia, anche se una \textit{stablecoin} fosse garantita +interamente da depositi presso le banche commerciali, rimarrebbe comunque +vulnerabile ai rischi di insolvenza del credito e di liquidità della +relativa banca. Tale rischio può essere evitato effettuando i depositi +presso la banca centrale in modo che siano le riserve di quest'ultima a +garantire la \textit{stablecoin}. Tali \textit{stablecoin} sono state +chiamate «CBDC sintetiche»~\cite{Adrian}. È importante sottolineare che +queste \textit{stablecoin} non sono moneta di banca centrale e quindi +non costituiscono una CBDC in quanto non sono registrate come passività +della banca centrale e, pertanto, rimangono soggette al rischio di +controparte, ovvero al rischio di fallimento dell'emittente. + +Se una \textit{stablecoin} non è rimborsabile ad un prezzo fisso, la sua +stabilità rispetto all'attivo sottostante non è garantita. Se la +\textit{stablecoin} rappresenta comunque una quota di proprietà +dell'attivo sottostante, lo schema ricorda quello di un fondo comune di +investimento chiuso o di un fondo indicizzato quotato (\textit{Exchange- +Traded Fund} - ETF) e si applicano i relativi rischi. Il valore +della moneta dipenderà dal valore patrimoniale netto del fondo, ma il +suo valore effettivo può variare. Se ci sono partecipanti autorizzati +a creare e riscattare \textit{stablecoin} e quindi ad agire come +arbitraggisti, come nel caso degli ETF e come previsto per la +Diem~\cite{Libra}, la deviazione si presume minima. + +Nel complesso, le \textit{stablecoin} hanno maggiori possibilità di +diventare moneta rispetto alle criptovalute, soprattutto se +adeguatamente regolamentate, anche se la disponibilità di CBDC +limiterebbe notevolmente la loro utilità. + +\section{Modelli generici di CBDC} \label{3.-modelli-generici-di-cbdc} + +Come abbiamo visto, la CBDC sarebbe una passività della banca +centrale. Due modelli possibili che si trovano nella letteratura +sull'argomento sono (a) CBDC basata su conti e (b) CBDC basata su +token (o sul valore). Questi modelli corrispondono ai due tipi +esistenti di moneta delle banche centrali e ai relativi sistemi di +pagamento (Kahn e Roberds 2008): riserve delle banche centrali +(sistema basato su conti) e banconote (sistema basato su token). Un +pagamento si verifica quando un'attivo monetario viene trasferito da un +pagatore a un beneficiario. In un sistema basato su conti, il +trasferimento avviene addebitando sul conto del pagatore e +accreditando sul conto del beneficiario. In un sistema basato su +token, il trasferimento avviene trasferendo il valore stesso o il +token, ovvero un oggetto che rappresenta l'attivo monetario. Il miglior +esempio di token è il contante (monete o banconote). Pagare in contanti +equivale a consegnare una moneta o una banconota. Non è necessario +registrare il trasferimento, il semplice possesso del token è +sufficiente. Pertanto, le parti non sono tenute a rivelare la propria +identità in nessun momento durante la transazione, entrambe possono +rimanere anonime. Ciononostante, il beneficiario deve essere in grado di +verificare l'autenticità del token. Questo è il motivo per cui le +banche centrali investono notevoli risorse nelle caratteristiche di +sicurezza delle banconote. + +È stato suggerito che la distinzione tra sistemi basati su conti e +quelli basati su token non sia applicabile alle monete digitali~\cite{Garratt}. +Noi al contrario riteniamo che ci sia una differenza significativa. La +differenza essenziale risiede nelle informazioni contenute nell'attivo. +In un sistema basato su conti, gli attivi (i conti) sono riconducìbili +ad una cronologia delle transazioni che include tutte le operazioni di +credito e addebito dei conti. In un sistema basato su token, gli attivi +(i token) contengono solo informazioni sul valore del token e +sull'entità che lo ha emesso. I sistemi basati su token sono quindi +l'unica possibilità per ottenere la stessa privacy nelle transazioni che +offre il contante.\footnote{Sebbene il termine «Bitcoin» suggerisca +l'uso di token, Bitcoin è un sistema basato su conti. L'unica differenza +tra un sistema tradizionale basato su conti e una \textit{blockchain} è +che i conti non sono conservati in un database centrale ma in un +database decentralizzato di solo accodamento.} + +\subsection{CBDC basata su conti}\label{cbdc-basata-su-conti} + +Il modo più semplice per avviare una CBDC sarebbe consentire al +pubblico di detenere conti deposito presso la banca centrale. Ciò +comporta che la banca centrale si facesse responsabile dei controlli per +conoscere i propri clienti (\textit{Know-Your-Customer} - KYC) e di +garantire la conformità con i requisiti per la lotta al riciclaggio di +denaro e al finanziamento del terrorismo. Ciò includerebbe non solo la +gestione del processo iniziale di conoscenza del cliente, ma anche +l'autenticazione dei clienti per le transazioni bancarie, la gestione +delle frodi e delle autenticazioni false positive e false negative. +Data la scarsa presenza fisica delle banche centrali nella società e il +fatto che probabilmente oggi non sono disposte ad eseguire l'autenticazione +dei cittadini su larga scala, qualsiasi CBDC basata su conti richiederebbe +alla banca centrale di delegare questi compiti. Tutti i servizi di +assistenza e manutenzione di tali conti potrebbero essere affidati ad +operatori esterni~\cite{Bindseil}, oppure le banche commerciali potrebbero +essere obbligate per legge ad aprire conti presso la banca centrale per i +propri clienti~\cite{Berentsen}. + +Una CBDC basata su conti darebbe potenzialmente alla banca centrale +l'accesso a molti dati aggiuntivi. Uno dei motivi di preoccupazione è +che i governi potrebbero facilmente mettere in atto una sorveglianza +di massa e imporre sanzioni ai singoli titolari dei conti. La natura +centralizzata di tali interventi li rende poco costosi e facili da +applicare nei confronti di persone o gruppi. Ci sono molti esempi di +sorveglianza abusiva contro critici e oppositori politici, anche nelle +democrazie. Si potrebbe argomentare che le banche centrali indipendenti +siano in grado di salvaguardare tali informazioni dall'intrusione del +governo e dagli abusi politici, ma ciò aprirebbe comunque una nuova +strada alle pressioni politiche che minacciano l'indipendenza delle +banche centrali. Inoltre, un database centrale sarebbe un obiettivo +cospicuo per gli attacchi: anche l'accesso in sola lettura ad una parte +del database potrebbe creare rischi significativi per le persone i cui +dati sarebbero esposti. + +Se dovessero forniri conti bancari per il pubblico, le banche centrali +entrerebbero in diretta concorrenza con le banche commerciali, competizione +che comporterebbe due rischi. In primo luogo, potrebbe minacciare la base +dei depositi delle banche e, all'estremo, portare alla disintermediazione +bancaria. Ciò potrebbe influire negativamente sulla disponibilità di +credito per il settore privato e, di conseguenza, sull'attività +economica~\cite{Agur}. La disintermediazione delle banche potrebbe anche +condurre alla centralizzazione dell'allocazione del credito all'interno +della banca centrale, con ripercussioni negative sulla produttività e +sulla crescita economica. In secondo luogo, la possibilità per le persone +di trasferire i propri depositi nel porto sicuro di una banca centrale +potrebbe accelerare le corse agli sportelli nei periodi di crisi economica. + +Vi sono però argomentazioni contrarie. \cite{Brunnermeier} +sostengono che i trasferimenti di fondi dai depositi ai conti +CBDC porterebbero alla sostituzione automatica del finanziamento +mediante depositi con il finanziamento tramite la banca centrale, il +che andrebbe ad esplicitare la garanzia finora implicita di prestatore +di ultima istanza delle banche centrali. \cite{Berentsen} +sostengono che la concorrenza delle banche centrali potrebbe persino +avere un effetto disciplinare sulle banche commerciali e quindi +aumentare la stabilità del sistema finanziario, dato che queste ultime +sarebbero costrette a consolidare la sicurezza dei propri modelli +economici per eviatare corse agli sportelli. + +Esistono anche proposte per ridurre il rischio di disintermediazione +restringendo o scoraggiando l'uso della CBDC come riserva di valore. Una +delle proposte è di limitare la quantità di CBDC che si può possedere. +Una seconda proposta consiste nell'applicare un tasso di interesse +variabile ai conti in CBDC, in modo che il rendimento sia sempre +sufficientemente inferiore a quello dei conti nelle banche commerciali, +arrivando eventualmente fino a tassi negativi, in modo da rendere la CBDC +meno attraente come riserva di valore~\cite{Kumhof,Bindseil}. Oltre a ciò, +per evitare le corse agli sportelli \cite{Kumhof} suggeriscono che la +CBDC non dovrebbe essere emessa a fronte di depositi bancari ma solo a +fronte di obbligazioni come i titoli di stato. Nel complesso, una CBDC +basata su conti richiederebbe un'analisi più approfondita di queste +problematiche. + +\subsection{CBDC Basata su token e legata al hardware} +\label{cbdc-basata-su-token-e-legata-al-hardware} + +In alternativa ai conti deposito, una banca centrale potrebbe emettere +token elettronici. Tecnicamente ciò richiede un sistema per garantire che +i token elettronici non possano essere copiati facilmente. Le funzioni +fisicamente non clonabili~\cite[vedi][]{Katzenbeisser} e le aree +sicure nell'hardware~\cite[vedi][]{Alves,Pinto} sono due tecnologie +possibili per la prevenzione della copia digitale. Le funzioni +fisicamente non clonabili, tuttavia, non possono essere scambiate su +Internet (eliminando di fatto l'uso principale delle CBDC) e le precedenti +funzionalità di sicurezza nell'hardware per la prevenzione della copia +sono state ripetutamente compromesse~\cite[si veda, ad esempio,][]{Wojtczuk,Johnston,Lapid}. + +Un vantaggio fondamentale delle CBDC basate su token rispetto a quelle +basate su conti è che i sistemi tokenizzati funzionerebbero offline, +ovvero, gli utenti potrebbero scambiare token (\textit{peer-to-peer}) +senza coinvolgere la banca centrale, proteggendo così la privacy e la +libertà delle persone. Tuttavia, la disintermediazione che si verifica +quando gli utenti possono scambiare token elettronici senza +intermediari bancari che eseguano i controlli per la conoscenza dei +clienti e le procedure per la lotta al riciclaggio di denaro e al +finanziamento del terrorismo renderebbe difficile la lotta alla +criminalità. + +Le schede SIM sono oggi il mezzo più ampiamente disponibile per un +sistema di pagamento sicuro basato su hardware, ma comportano anche +dei rischi. L'esperienza~\cite[si veda, ad esempio,][]{Soukup,Garcia,Kasper,CCC} +suggerisce che qualsiasi dispositivo economicamente riproducibile in grado +di memorizzare token con valore monetario, che una persona possa possedere +e che consenta transazioni offline --- e quindi il furto mediante +clonazione delle informazioni in esso contenute --- sarà l'obiettivo di +attacchi di contraffazione riusciti non appena il valore economico +dell'attacco risulti sostanziale. Tali attacchi provengono anche da +utenti che forzano il proprio hardware ~\cite[si veda anche]{Allen}. Per +limitare l'impatto di una compromissione, i sistemi con carte di pagamento +che sono stati precedentemente implementati dependono dalla resistenza +alle manomissioni in combinazione con il rilevamento delle frodi. +Tuttavia, il rilevamento delle frodi richiede la capacità di identificare +i pagatori e tenere traccia dei clienti, il che non è compatibile con la +privacy nelle transazioni. + +\section{Una CBDC basata su token progettata per tutelare la privacy} +\label{4.-una-cbdc-basata-su-token-progettata-per-tutelare-la-privacy} + +La CBDC qui proposta è di tipo «solo software», semplicemente +un'applicazione per smartphone che non richiede alcun hardware aggiuntivo. +Il design fa affidamento su eCash e GNU Taler. Taler fa parte del progetto +GNU, il cui fondatore, Richard Stallman, ha coniato il termine +«\emph{Software Libero}», ora spesso indicato come \textit{Free/Libre +and Open Source Software} (FLOSS).\footnote{Per ulteriori informazioni +su GNU, si veda \url{https://www.gnu.org} e \cite{Stallman}. GNU Taler +è rilasciato sotto la licenza libera \textit{GNU Affero General Public +License} del Progetto GNU. Altri programmi del progetto GNU noti tra gli +economisti sono \textit{R} e \textit{GNU Regression, Econometrics and +Time-series Library} (GRETL). Per un'analisi dei vantaggi del FLOSS +rispetto al software proprietario nel campo della ricerca, si veda~\cite{Baiocchi}, \cite{Yalta2008} e \cite{Yalta2010}. +Sulle licenze libere e open source, si veda~\cite{Lerner}.} Il software +è considerato libero se la sua licenza concede agli utenti quattro libertà +essenziali: la libertà di eseguire il programma come si desidera, la +libertà di studiare il programma e modificarlo, la libertà di ridistribuire +copie del programma e la libertà di distribuire copie delle versioni +modificate del programma. Il software libero non impedisce la +commercializzazione; fornire supporto tecnico per il software è un modello +di business standard per il FLOSS. + +Dato il gran numero di parti interessate coinvolte in una CBDC al +dettaglio (la banca centrale, il settore finanziario, i venditori e +i clienti) e l'importanza critica dell'infrastruttura, una CBDC al +dettaglio deve essere basata sul FLOSS. Imporre una soluzione +proprietaria, che comporta la dipendenza da un fornitore specifico, +sarebbe probabilmente un ostacolo all'adozione fin dall'inizio. Con il +FLOSS, tutte le parti interessate hanno accesso a ogni dettaglio della +soluzione e il diritto di adattare il software alle proprie esigenze. +Ciò facilita l'integrazione e migliora l'interoperabilità e la +concorrenza tra i fornitori.\footnote{Tuttavia, l'hardware privato +potrebbe avere un ruolo da svolgere. La protezione degli archivi delle +chiavi e di alcune funzioni di controllo, ad esempio, può essere un'area +dove l'hardware dedicato valutato solo da un numero limitato di esperti +può presentare dei vantaggi, nella misura in cui tale sicurezza sia solo +additiva.} Consente inoltre alla banca centrale di soddisfare i requisiti +di trasparenza e responsabilità. I vantaggi del FLOSS riguardo la +sicurezza sono anche ampiamente riconosciuti. La disponibilità del codice +sorgente e la libertà di modificarlo facilitano l'identificazione degli +errori e la loro rapida correzione. \footnote{Ad esempio, un bollettino +sulla sicurezza informatica emesso dall'Agenzia per la sicurezza nazionale +degli Stati Uniti (NSA) nell'aprile 2020 esorta gli utenti a dare la +priorità al software libero nella scelta e nell'utilizzo dei servizi +collaborativi per le comunicazioni su Internet: «Lo sviluppo open source +garantisce trasparenza sulla robustezza del codice e la sua conformità +alle migliori pratiche di programmazione, evitando l'introduzione di +vulnerabilità o punti deboli che potrebbero mettere a rischio utenti e +dati» (U/OO/134598-20).} + +Nell'architettura che proponiamo, tutte le interazioni tra consumatori +e venditori si fanno con le banche commerciali, ma la creazione di moneta +e il database sono forniti esclusivamente dalla banca centrale. Le banche +commerciali autenticano i clienti quando ritirano CBDC così come i +venditori o beneficiari quando le ricevono. Quando spendono CBDC, +invece, i clienti o pagatori devono solo autorizzare le transazioni senza +bisogno di identificarsi. I pagamenti risultano più economici, più facili +e più veloci, evitando al contempo interferenze con la privacy~\cite{Dold}. +L'autenticazione dei clienti quando ritirano CBDC, nonché dei venditori +o beneficiari quando le ricevono, consente altresì di adempire alle +normative sulla conoscenza dei clienti e sulla lotta al riciclaggio di +denaro e al finanziamento del terrorismo. + +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. \cite{Dold} fornisce ulteriori +dettagli. + +\subsection{Componenti fondamentali}\label{componenti-fondamentali} + +Di seguito si descrivono i componenti principali del protocollo, comprese +le basi matematiche per una delle possibili rappresentazioni delle +primitive crittografiche utilizzate, allo scopo di illustrare in +che modo potrebbe funzionare un'implementazione. Considerando che +esistono altri modelli matematici equivalenti per ciascun componente, +presentiamo solo la più semplice delle soluzioni sicure a noi note. + +\emph{Firme digitali.} L'idea che sta alla base delle firme digitali in +uno schema di firma a chiave pubblica è quella di garantire che il +titolare della chiave privata sia l'unico in grado di firmare un +messaggio, mentre la chiave pubblica consente a chiunque di verificare +la validità della firma.\footnote{La crittografia a chiave pubblica è +stata introdotta da~\cite{Diffie} e le prime implementazioni di firme +digitali sono state quelle di~\cite{Rivest}.} Il risultato della funzione +di verifica della firma è la dichiarazione binaria «vero» o «falso». Se +il messaggio è firmato con la chiave privata che appartiene alla chiave +pubblica di verifica, il risultato è «vero», altrimenti è «falso». +Nella nostra proposta il messaggio è una moneta o una banconota con un +numero di serie, e la firma della banca centrale ne attesta la +validità. Sebbene GNU Taler utilizzi per impostazione predefinita le +moderne firme EdDSA~\cite[vedi][]{Bernstein2012}, qui presentiamo un +semplice schema di firma crittografica basato su RSA~\cite{Rivest}, un +sistema crittografico ben studiato.\footnote{Per un'analisi della +lunga storia del crittosistema RSA e uno studio degli attacchi a questo +sistema, si veda~\cite{Boneh}.} Tuttavia, in linea di principio, è +possibile utilizzare qualsiasi tecnologia di firma crittografica +(DSA, ECDSA, EdDSA, RSA, ecc.) + +Per generare una chiave RSA, il firmatario prende prima due grandi +numeri primi indipendenti $p$ e $q$ e calcola $n = \emph{pq}$, +nonché la funzione phi di Eulero +$\phi(n) = (p - 1)(q - 1)$. +Quindi, si può utilizzare qualsiasi $e$ con $1 < e < \phi(n)$ e +$\gcd(e, \phi(n)) = 1$ per definire una chiave pubblica $(e,n)$. +La condizione che il massimo comune denominatore ($\texttt{MCD}$) di $e$ e +$\phi(n)$ debba essere 1 (cioè, che devono essere +primi tra loro) assicura che l'inverso di +$e \mod \phi(n)$ esista. +Questo inverso è la +corrispondente chiave privata $d$. Data $\phi(n)$, la chiave +privata $d$ può essere calcolata mediante l'algoritmo esteso +di Euclide tale che +$d \cdot e \equiv 1 \mod \phi(n)$. + +Data la chiave privata $d$ e la chiave pubblica $(e, n)$, una semplice +firma RSA +$s$ su un messaggio $m$ è +$s \equiv m^{d} \mod n$. +Per verificare la firma si calcola +$m' \equiv s^{e} \mod n$. +Se $m'$ e $m$ corrispondono, la firma è valida e dimostra che il +messaggio è stato firmato con la chiave privata che corrisponde alla +chiave pubblica di verifica (autenticazione del messaggio) e che il +messaggio non è stato modificato durante il transito (integrità del +messaggio). In pratica, le firme vengono poste sull'hash dei messaggi +piuttosto che sui messaggi stessi. Le funzioni di hash calcolano le +impronte digitali dei messaggi (\textit{digest}), che sono identificatori +univoci e brevi per i messaggi. Firmare un hash breve è molto più veloce +che firmare un messaggio di grandi dimensioni, e la maggior parte degli +algoritmi di firma funzionano solo su input relativamente brevi.\footnote{Nel +caso del crittosistema RSA, il limite di lunghezza è di +$\log_{2}n$ bit.} + +\emph{Firme cieche.} Utilizziamo le firme cieche introdotte +da~\cite{Chaum1983} per tutelare la privacy degli acquirenti. Una firma +cieca viene utilizzata per creare una firma crittografica per un messaggio +senza rivelare al firmatario il contenuto del messaggio. Nella nostra proposta, +ciò impedisce alle banche commerciali e alla banca centrale di poter risalire +all'acquirente tracciando gli acquisti. In linea di principio, la nostra +proposta funziona con qualsiasi sistema di firma cieca, ma la soluzione migliore +rimane la variante basata su RSA descritta da~\cite{Chaum1983}. + +L'accecamento viene eseguito dai clienti, che accecano le proprie +monete prima di trasmetterle alla banca centrale per la firma. I +clienti non devono quindi affidare alla banca centrale la tutela della +propria privacy. Inoltre, l'accecamento con RSA fornirebbe protezione +della privacy anche contro gli attacchi informatici quantistici. La +banca centrale, dal canto suo, predispone più coppie di chiavi di +valore per apporre la firma cieca su monete di diverso valore +unitario, e fornisce le corrispondenti chiavi pubbliche +$(e, n)$ per tali valori. + +Sia $f$ il valore di hash di una moneta e quindi l'identificatore +univoco per questa moneta. Il cliente che preleva la moneta prima +genera un fattore di accecamento casuale $b$ e calcola +$f' \equiv fb^{e} \mod n$ +con la chiave pubblica della banca centrale per quel valore. +La moneta accecata $f'$ viene quindi trasmessa alla banca centrale per +la firma. La banca centrale firma $f'$ con la sua chiave +privata $d$ calcolando la firma cieca +$s' \equiv \left(f' \right)^{d} \mod n$, appone +la firma $s'$ alla moneta accecata $f'$ e restituisce la coppia +$(s',f')$ al cliente. Il cliente può quindi rimuovere l'accecamento +della firma calcolando +$s \equiv s'b^{- 1} \mod n$. +Ciò è possibile perché +$\left( f' \right)^d = f^db^{ed} = f^db$, e quindi +moltiplicando $s'$ con $b^{- 1}$ si ottiene $f^d$, che è una firma RSA +valida su $f$ come prima: +$s^e \equiv f^{de} \equiv f \mod n$. + +Nella proposta originale di Chaum, le monete erano dei semplici +gettoni. Quel che vogliamo, invece, è che i consumatori possano +utilizzare le firme digitali per stipulare contratti. A tal fine, ogni +volta che un portafoglio digitale preleva una moneta, in primo luogo +crea per la moneta una chiave privata casuale $c$ e calcola la +corrispondente chiave pubblica $C$ per creare firme digitali con i +normali sistemi di firma crittografica (come DSA, ECDSA, EdDSA e +RSA). Quindi si deriva $f$ mediante una funzione di hash crittografica +dalla chiave pubblica $C$, prima che la banca centrale ne apponga la +firma cieca (utilizzando un nuovo fattore di accecamento casuale per +ciascuna moneta). Ora il cliente può utilizzare $c$ per firmare +elettronicamente gli acquisti, spendendo così la moneta. + +Come visto sopra, la banca centrale andrebbe a predisporre coppie di +chiavi diverse per ogni valore unitario di moneta e pubblicherebbe le +chiavi pubbliche che i clienti userebbero per prelevare denaro. Queste +chiavi di valore, e quindi le monete, avrebbero una data di scadenza +prima della quale dovrebbero essere spese o scambiate con monete +nuove. Ai clienti verrebbe concesso un certo periodo di tempo per +scambiare le monete. Un processo simile esiste per le banconote +fisiche, dove le serie di banconote vengono regolarmente rinnovate per +essere dotate delle più recenti caratteristiche di sicurezza, tranne +per il fatto che le banconote generalmente rimangono in circolazione +per decenni anziché per pochi anni o mesi.\footnote{In Svizzera, +ad esempio, la Banca nazionale svizzera ha iniziato a ritirare dalla +circolazione l'ottava serie di banconote nell'aprile 2016. Questa serie +era stata messa in circolazione alla fine degli anni novanta. Dal 1 +gennaio 2020, tuttavia, tutte le banconote a partire dalla sesta serie +(emesse nel 1976) fino alle serie future restano valide e possono essere +scambiate a tempo indeterminato con banconote correnti.} + +Da un punto di vista tecnico, una data di scadenza offre due vantaggi. +In primo luogo, migliora l'efficienza del sistema perché la banca +centrale può cancellare i dati scaduti, evitando così di dover +archiviare e poi cercare in un elenco sempre crescente di monete +(spese) per rilevare una doppia spesa. In secondo luogo, riduce i +rischi per la sicurezza dato che la banca centrale non deve +preoccuparsi di attacchi alle proprie chiavi (private) di valore ($d$) +scadute. Inoltre, anche se una chiave privata venisse compromessa, il +periodo durante il quale l'attaccante può utilizzarla è breve. In aggiunta, +l'addebito di una commissione di cambio consentirebbe alla banca centrale di +applicare tassi di interesse negativi, se ritenuto necessario. La banca centrale +potrebbe anche, se lo desidera, fissare un limite di conversione per cliente in +considerazione dell'antiriciclaggio e l'antiterrorismo (soglia di «contante») o +per motivi di stabilità finanziaria (per prevenire accaparramenti e corse agli +sportelli). + +\emph{Protocollo di scambio di chiavi.} GNU Taler utilizza un protocollo +di scambio di chiavi in un modo particolare per fornire un collegamento +tra la moneta originale e il resto reso per quella stessa moneta. Ciò +garantisce che il resto possa sempre essere reso senza compromettere +la trasparenza del reddito e la privacy dei consumatori. Lo stesso +meccanismo si può utilizzare per i rimborsi anonimi ai clienti. Il +protocollo gestisce anche i guasti alla rete e ai componenti, +assicurando che i pagamenti siano andati a buon fine o siano stati +definitivamente annullati e che tutte le parti abbiano una prova +crittografica dell'esito. Questo corrisponde all'incirca agli scambi +atomici nei protocolli \textit{interledger} o allo scambio equo nei +tradizionali sistemi \textit{e-cash}. + +La costruzione matematica più comune per un protocollo di scambio di +chiavi è la costruzione Diffie-Hellman(~\cite{Diffie}), che +consente a due parti di derivare una chiave segreta condivisa. A tale +scopo, condividono due parametri di dominio $p$ e $g$, che possono +essere pubblici, dove $p$ è un numero primo grande e $g$ è una radice +primitiva modulo $p$.\footnote{Un intero $g$ è una radice primitiva +modulo $p$ se per ogni intero $a$ coprimo a $p$ esiste un intero $k$ +per il quale +$g^k \equiv a \mod p$. +In pratica, $g$ dovrebbe essere una radice primitiva $(p-1)$-esima, detta +anche generatore, al fine di prevenire attacchi a sottogruppi come quelli +Pohlig-Hellman~\cite[vedi][]{Lim}.} Ora, le due parti scelgono le loro +chiavi private \emph{a} e \emph{b}, che sono due numeri interi grandi. +Con queste chiavi private e i parametri di dominio, generano le +rispettive chiavi pubbliche +$A \equiv g^{a} \mod p$ e $B \equiv g^{b} \mod p$. +Ciascuna parte può ora utilizzare la propria chiave privata e la chiave +pubblica dell'altra parte per calcolare la chiave segreta condivisa +$k \equiv \left( g^b \right)^{a} \equiv \left( g^{a} \right)^{b} \equiv g^{\text{ab}} \mod p$.\footnote{ +Lo stesso meccanismo potrebbe essere utilizzato per garantire +che le monete non vengano trasferite a terzi durante il prelievo. A +questo scopo, gli utenti devono salvaguardare una chiave di identità a +lungo termine. Il processo di prelievo potrebbe quindi essere +costruito allo stesso modo di quello utilizzato da GNU Taler per dare +il resto, tranne per il fatto che quando si preleva dal conto bancario +del cliente verrebbe utilizzata la chiave d'identità a lungo termine +del cliente al posto della moneta originale. Tuttavia, le garanzie +sulla privacy potrebbero decadere se il cliente non protegge la chiave +d'identità a lungo termine, con il conseguente rischio di furto di +tutte le monete residue. Dato che il rischio nei trasferimenti a terzi +quando si prelevano monete è basso, non è chiaro se questa riduzione +del rischio possa essere un buon compromesso.} + +Per ottenere il resto, il cliente parte dalla chiave privata della +moneta parzialmente spesa $c$. Sia $C$ la chiave pubblica corrispondente, +per esempio +$C = g^{c} \mod p$. +Quando la moneta fu parzialmente spesa in precedenza, la banca centrale +registrò la transazione relativa a $C$ nel proprio database. Per +semplicità, assumiamo che esista un valore unitario che corrisponda +esattamente a questo valore residuo. In caso contrario, il protocollo si +riavvia finché non viene reso tutto il resto. Sia $(e,n)$ la +chiave di valore per il resto da rendere. + +Per ottenere il resto, l'acquirente crea prima $\kappa$ chiavi di +trasferimento private $t_{i}$ per +$i \in \left\{ 1,\ldots,\kappa \right\}$ e calcola le +corrispondenti chiavi pubbliche $T_{i}$. Queste chiavi di +trasferimento $\kappa$ sono semplicemente coppie di chiavi +pubbliche-private che consentono al cliente di eseguire localmente il +protocollo di scambio di chiavi, con il cliente che gioca su entrambi +i lati del processo, $\kappa$ volte tra $c$ e ogni $t_{i}$. +Se si usa Diffie-Hellman come protocollo per lo scambio di chiavi, si +ottiene +$T_{i} \equiv g^{t_{i}} \mod p$. + +Il risultato sono tre trasferimenti +$K_{i} \equiv \emph{KX}(c,t_{i})$. Il protocollo di scambio di chiavi +può essere utilizzato in diversi modi per ottenere lo stesso valore +$K_{i} \equiv \emph{KX}(C,t_{i}) = \emph{KX}(c,T_{i})$. +Data $K_{i}$, il cliente utilizza una funzione crittografica hash $H$ +per ricavare i valori +$(b_{i},c_{i}) \equiv H(K_{i})$, dove +$b_{i}$ è un fattore di accecamento valido per la chiave di valore +$(e,n)$ e $c_{i}$ +è una chiave privata per la nuova moneta da ottenere come resto. +$c_{i}$ deve essere adatta sia per creare firme crittografiche sia per +un uso futuro con il protocollo di scambio di chiavi +(come $c$, per ottenere resto a partire dal resto). +Sia $C_{i}$ la chiave pubblica corrispondente a $c_{i}$. +Il cliente chiede quindi alla banca centrale di creare una firma cieca su +$C_{i}$ per $i \in \{ 1,\ldots,\kappa\}$.\footnote{Se dovesse essere +utilizzato il crittosistema RSA per le firme cieche, useremmo +$f \equiv \emph{FDH}_{n}(C_{i})$, dove +$\emph{FDH}_{n}()$ +è l'hash del dominio completo sul dominio $n$.} In questa richiesta, il +cliente si impegna anche con le chiavi pubbliche +$T_{i}$. +La richiesta è autorizzata mediante una firma effettuata con la chiave +privata $c$. + +Invece di restituire direttamente la firma cieca, la banca centrale +chiede prima al cliente di dimostrare che ha utilizzato correttamente la +costruzione di cui sopra fornendo +$\gamma \in \left\{ 1,\ldots,\kappa \right\}$. +Il cliente deve quindi mostrare alla banca centrale la +$t_{i}$ per $i \neq \gamma$. +La banca centrale può quindi calcolare +$K_{i} \equiv \emph{KX}(C,t_{i})$ e ricavare i valori +$(b_{i},c_{i})$. Se per tutte le +$i \neq \gamma$ la $t_{i}$ fornita dimostra che il cliente ha utilizzato +correttamente la costruzione, la banca centrale restituisce la firma +cieca su $C_{\gamma}$. +Se il cliente non fornisce una prova corretta, il valore residuo della +moneta originale viene perso. Questo penalizza efficacemente coloro che +tentano di eludere la trasparenza del reddito con un'aliquota fiscale +stimata di $1 - \frac{1}{\kappa}$. + +Per evitare che un cliente cospiri con un venditore che sta tentando di +evadere il fisco, la banca centrale consente a chiunque +conosca $C$ di ottenere, in qualsiasi momento, i valori di +$T_{\gamma}$ +e le firme cieche di tutte le monete collegate alla moneta originaria $C$. +Ciò permette al possessore della moneta originaria, che conosce $c$, di +calcolare +$K_{\gamma} \equiv \emph{KX}( c,T_{\gamma})$ +e da lì ricavare +$(b_{i},c_{i})$ +per, infine, rimuovere la firma cieca. Di conseguenza, un venditore che +nasconde il proprio reddito in questo modo formerebbe solo un'accordo +economico limitato con il cliente invece di ottenere il controllo esclusivo. + +\hypertarget{architettura-del-sistema}{% +\subsection{Architettura del sistema}\label{architettura-del-sistema}} + +Uno degli obiettivi principali della nostra architettura è garantire +che le banche centrali non debbano interagire direttamente con i +clienti né conservare alcuna informazione su di loro, ma solo tenere +un elenco delle monete spese. L'autenticazione è delegata alle banche +commerciali, che dispongono già dell'infrastruttura necessaria. I +protocolli di prelievo e deposito raggiungono la banca centrale +tramite una banca commerciale in qualità di intermediaria. Dal punto +di vista del cliente, il processo è analogo al prelievo di contanti da +un bancomat. La transazione tra la banca commerciale dell'utente e la +banca centrale avviene in background. La procedura per il prelievo di +CBDC è illustrata nel diagramma~\ref{fig:fig1}. + +\begin{figure}[h!] + \includegraphics[width=\textwidth]{diagramma1-it.png} + \caption{Prelievo di CBDC} + \label{fig:fig1} +\end{figure} + +Il cliente (1) invia i dati di accesso alla propria banca commerciale +utilizzando le relative procedure di autenticazione e autorizzazione. +Quindi il telefono (o il computer) del cliente ottiene la chiave di +valore pubblica $(e, n)$ fornita dalla banca centrale per quel valore; (2) +calcola quindi una coppia di chiavi per la moneta, con una chiave +privata $c$ e una chiave pubblica $C$, e sceglie un fattore di accecamento +$b$. La chiave pubblica della moneta viene quindi sottoposta a hash +($\to$ $f$) e accecata ($\to$ $f'$). Quindi il dispositivo del cliente (3) +invia $f'$ insieme all'autorizzazione a prelevare la moneta e ad +addebitarla dal conto del cliente presso la banca commerciale tramite un +canale sicuro stabilito. La banca commerciale (4) addebita quindi +l'importo dal conto deposito del cliente, (5) autorizza digitalmente la +richiesta utilizzando la firma digitale specifica della propria filiale +e inoltra la richiesta e la moneta accecata alla banca centrale per la +firma. La banca centrale (6) sottrae il valore della moneta dal conto +della banca commerciale, appone la firma cieca sulla moneta +utilizzando la chiave privata che detiene per il relativo valore e (7) +restituisce la firma cieca $s'$ alla banca commerciale. La banca +commerciale (8) inoltra la firma cieca $s'$ al portafoglio elettronico +del cliente. Infine, il dispositivo del cliente (9) utilizza $b$ per +rimuovere l'accecamento dalla firma ($\to$ $f$) e salva la moneta appena +coniata $(c, s)$. + +Un cliente e un venditore negoziano un contratto commerciale. Il +cliente (1) utilizza una moneta elettronica per firmare il contratto o +l'atto di vendita con la chiave privata $c$ della moneta e trasmette la +firma al venditore. La firma di una moneta su un contratto con una +moneta valida è l'istruzione del cliente di pagare il venditore, che è +identificato dal conto bancario nel contratto. Se una singola moneta +non fosse sufficiente per coprire l'importo totale, i clienti possono +firmare il contratto con più monete. Il venditore (2) convalida quindi +la firma della moneta sul contratto e la firma $s$ della banca centrale +su $f$, che corrisponde a quella della moneta $C$ con le rispettive +chiavi pubbliche, e inoltra la moneta firmata (insieme alle +informazioni sul conto del venditore) alla banca commerciale del +venditore. La banca commerciale del venditore (3) conferma che il +venditore è un suo cliente e inoltra la moneta firmata alla banca +centrale. La banca centrale (4) verifica le firme e controlla il +proprio database per accertarsi che la moneta non sia già stata spesa. +Se tutto è in ordine, la banca centrale (5) aggiunge la moneta +all'elenco delle monete spese, l'accredita sul conto della banca +commerciale presso la banca centrale e (6) invia una conferma in tal +senso alla banca commerciale. Quindi la banca commerciale (7) +accredita la moneta sul conto del venditore e (8) gli invia una +notifica. Il venditore (9) consegna il prodotto o servizio al cliente. +L'intera operazione richiede poche centinaia di millisecondi. + +\begin{figure}[h!] + \includegraphics[width=\textwidth]{diagramma2-it.png} + \caption{Spendere e depositare CBDC} + \label{fig:fig2} +\end{figure} + +\hypertarget{considerazioni-sulla-sicurezza}{% +\subsection{Considerazioni sulla sicurezza} +\label{considerazioni-sulla-sicurezza}} + +Nella nostra proposta, occorre che la banca centrale gestisca un +database e un servizio online ad alta disponibilità. Poiché le monete +elettroniche possono essere copiate dagli utenti, solo con i controlli +online si può prevenire in modo efficace la doppia spesa. Sebbene +nella teoria esistano soluzioni per identificare a posteriori gli +utenti che effettuano una doppia spesa~\cite[vedi][]{Chaum1990}, +queste soluzioni creano rischi economici sia per gli utenti che per la +banca centrale a causa del ritardo nell'identificazione di +transazioni fraudolente. Il rilevamento online della doppia spesa +elimina questo rischio, ma significa anche che sarà impossibile +effettuare le transazioni se la connessione Internet alla banca +centrale non è disponibile. + +La banca centrale dovrà anche proteggere la riservatezza delle chiavi +private che utilizza per firmare le monete e altri messaggi di +protocollo. Se le chiavi di firma della banca centrale dovessero +essere compromesse, ad esempio da un computer quantistico, da un +attacco fisico ai \textit{datacenter} o anche da qualche nuovo algoritmo +imprevisto, è possibile rimborsare gli utenti --- in tutta sicurezza e +senza compromettere la privacy --- tutte le monete non spese. La banca +centrale annuncerebbe la revoca della chiave tramite l'\textit{Application +Programming Interface} (API), che verrebbe rilevata dai portafogli, +avviando quindi il seguente protocollo di aggiornamento: l'utente +svela alla banca centrale la chiave pubblica $C$ della moneta, la firma +$s$ della banca centrale e il fattore di accecamento $b$, consentendo così +alla banca centrale di verificare il legittimo prelievo dell'utente e +di rimborsare il valore della moneta non spesa. Per rilevare una +possibile compromissione della propria chiave, la banca centrale può +monitorare il database in cerca di depositi che eccedano i prelievi. + +\subsection{Scalabilità e costi}\label{scalabilità-e-costi} + +Lo schema che proponiamo sarebbe efficiente ed economico quanto i +moderni sistemi RTGS attualmente utilizzati dalle banche centrali. + +La scalabilità si riferisce al costo di aumentare la potenza di +calcolo in modo che si possa concludere un numero crescente di +transazioni in tempi adeguati. Il costo complessivo del sistema può +essere basso in quanto la CBDC qui proposta si basa interamente su +software. Le monete spese devono essere conservate fino alla scadenza +della coppia di chiavi di valore utilizzata per firmare le monete, ad +esempio tramite un ciclo annuale continuo, che mantiene limitata la +dimensione del database. La potenza di calcolo e la larghezza di banda +necessarie aumentano della stessa quantità per ogni transazione, spesa +o deposito addizionali, dato che le transazioni sono intrinsecamente +indipendenti l'una dall'altra. Questa ulteriore potenza si ottiene +semplicemente aggiungendo più hardware, una pratica spesso conosciuta +come partizionamento o \textit{sharding}. Grazie al cosiddetto +\textit{consistent hashing}, le aggiunte di hardware non risultano +dirompenti. Si può anche utilizzare qualsiasi tipo di database. + +Più nello specifico, la logica del \textit{front-end} presso la banca +centrale deve solo eseguire poche operazioni di firma, e un singolo +processore può eseguirne alcune migliaia al secondo~\cite[vedi][]{Bernstein2020}. +Se un unico sistema non fosse sufficiente, è facile aggiungere altri +server \textit{front-end} e invitare le varie banche commerciali a +bilanciare le loro richieste nella \textit{server farm} o +utilizzare un sistema di bilanciamento del carico per distribuire le +richieste all'interno dell'infrastruttura della banca centrale. + +I server \textit{front-end} devono comunicare con un database per +effettuare le transazioni e prevenire la doppia spesa. Un unico server +di database moderno dovrebbe essere in grado di gestire in modo +affidabile decine di migliaia di operazioni al secondo. Le operazioni +possono essere facilmente distribuite su più server di database +semplicemente assegnando a ciascuno un intervallo di valori da +gestire. Tale configurazione garantisce che le singole transazioni non +incrocino mai le partizioni. Pertanto, anche i sistemi \textit{back-end} +dovrebbero scalare in modo lineare con le risorse di calcolo messe a +disposizione, partendo sempre da una solida base di riferimento per un +singolo sistema. + +I \textit{front-end} devono anche comunicare con i \textit{back-end} per +mezzo di un'interconnessione. Queste interconnessioni possono +supportare un gran numero di transazioni al secondo. La dimensione di +una singola transazione è in genere di circa 1–10 kilobyte. Pertanto, +i \textit{datacenter} di oggi, che scambiano informazioni a 400 Gbit/s, +possono supportare milioni di transazioni al secondo. + +Infine, il costo totale del sistema è basso. Probabilmente il costo +principale sia rappresentato dall'archiviazione sicura per +molti anni di 1–10 kilobyte per transazione. Gli esperimenti su un +prototipo di GNU Taler che utilizzava i prezzi di \textit{Amazon Web Service} +hanno stabilito che il costo del sistema (archiviazione, larghezza di +banda e capacità di calcolo) su larga scala sarebbe inferiore a +0,0001 USD per transazione (per i dettagli sui dati, si veda~\cite{Dold})). + +\section{Considerazioni normative e politiche} + \label{5.-considerazioni-normative-e-politiche} + +Nella soluzione che proponiamo, la banca centrale non conosce +l'identità dei consumatori o dei venditori né l'importo totale delle +transazioni, ma vede solo il momento in cui le monete elettroniche vengono +rilasciate e quando vengono riscattate. Le banche commerciali continuano a +fornire l'autenticazione cruciale di consumatori e venditori e, in particolare, +custodiscono le informazioni che acquisiscono per la conoscenza dei clienti +(KYC). Le banche commerciali osservano quando i venditori ricevono fondi e, se +necessario, possono limitare la quantità di CBDC per transazione che +un singolo venditore può ricevere. Inoltre, le transazioni sono +collegate ai relativi contratti con i clienti. La conseguente +trasparenza del reddito consente al sistema di soddisfare i requisiti +delle normative sulla lotta al riciclaggio di denaro e al +finanziamento del terrorismo (AML e CFT). In caso vengano rilevate +anomalie nei redditi dei venditori, la banca commerciale e +l'autorità fiscale o giudiziaria possono ottenere e ispezionare i +contratti relativi ai pagamenti sospetti al fine di verificarne la +legittimità. La trasparenza del reddito risultante è anche una forte +misura contro l'evasione fiscale perché i venditori non possono +sottodichiarare il proprio reddito o evadere le tasse sulle vendite. +Nel complesso, il sistema implementa gli approcci \textit{privacy-by- +design} e \textit{privacy-by-default} (come richiesto, ad esempio, +dal Regolamento generale sulla protezione dei dati dell'UE, GDPR). I +venditori non apprendono necessariamente l'identità dei propri clienti, +le banche possiedono solo le informazioni necessarie sulle attività dei +propri clienti e la banca centrale non ha accesso ai dettagli sulle +attività dei cittadini. + +In alcuni paesi le normative impongono limiti per i prelievi e i +pagamenti in contanti. Tali restrizioni possono essere implementate +anche per la CBDC nel progetto proposto. Ad esempio, è possibile +stabilire una soglia per l'importo giornaliero che i consumatori possono +prelevare, oppure limitare l'importo totale di CBDC che le banche +commerciali possono convertire. + +La disintermediazione del settore bancario è uno dei rischi di +instabilità finanziaria spesso sollevato per quanto riguarda la BCDC +al dettaglio. In particolare, una CBDC al dettaglio potrebbe +facilitare l'accumulo di ingenti somme di denaro della banca +centrale, il che potrebbe avere un impatto negativo sul finanziamento +alle banche mediante depositi perché il pubblico deterrebbe meno +denaro sotto forma di depositi bancari. Per i paesi le cui valute +fungono da valute rifugio, ciò potrebbe anche portare ad un aumento +degli afflussi di capitali durante i periodi globali di avversione al +rischio, dando luogo ad ulteriori pressioni sui tassi di cambio. +Quello che quindi potrebbe rappresentare un serio problema nel caso di +una CBDC basata su conti, lo sarebbe molto meno con una CBDC basata +su token. Innanzitutto, l'accumulo di una CBDC basata su token comporta +rischi di furto o perdita simili a quelli legati all'accumulo di +contanti. Tenere poche centinaia di dollari su uno smartphone è +probabilmente un rischio accettabile per molti, ma detenere una somma +molto alta è probabilmente un rischio meno accettabile. Pertanto, non +ci aspettiamo un accaparramento significativamente maggiore rispetto a +quello del denaro fisico. + +Tuttavia, se l'accumulo o la massiccia conversioni dei depositi +bancari in CBDC dovessero destare proccupazione, la banca centrale +avrebbe diverse opzioni. Come si è spiegato, secondo il progetto +proposto le banche centrali fissano una data di scadenza per tutte le +chiavi di firma, il che implica che in una data prestabilita le monete +firmate con quelle chiavi diventano non valide. Alla scadenza delle +chiavi di valore, i consumatori devono scambiare con monete nuove le +monete che erano state firmate con le vecchie chiavi; l'autorità di +regolamentazione può facilmente fissare una soglia di conversione per +cliente per creare un limite rigido alla quantità di CBDC che ogni +individuo può accumulare. Inoltre, la banca centrale potrebbe addebitare +commissioni, se necessario. Una commissione di aggiornamento quando le monete +stanno per scadere significherebbe nella pratica tassi di interesse negativi +sulla CBDC per limitare il suo fascino come riserva di valore, come +suggerisce~\cite{Bindseil}. Si tratterebbe infatti della diretta attuazione +dell'idea di Silvio Gesell di applicare una tassa di possesso sulla moneta, +notoriamente citata da~\cite{Keynes} e ripresa da~\cite{Goodfriend}, +\cite{Buiter}, e~\cite{Agarwal}. + +Per quanto riguarda le implicazioni in termini di politica monetaria, +non dovrebbero esserci cambiamenti reali perché la nostra CBDC è +progettata per replicare il contante piuttosto che i depositi bancari. +L'emissione, il prelievo e il deposito della nostra CBCD corrispondono +esattamente all'emissione, al prelievo e al deposito di banconote. È +possibile che la velocità di circolazione di una CBDC al dettaglio sia +diversa da quella del contante fisico, ma questo non dovrebbe +rappresentare un problema significativo per la politica monetaria. + +\hypertarget{lavori-correlati}{% +\section{Lavori correlati}\label{6.-lavori-correlati}} + +Come segnalato in precedenza, la CBDC che si propone in questo documento +si basa su eCash e GNU Taler.\footnote{L'implementazione di eCash +da parte della società DigiCash negli anni novanta è documentata su +\url{https://www.chaum.com/ecash}.} A partire dalla proposta originale +e-Cash di Chaum, la ricerca si è concentrata su tre questioni principali. +In primo luogo, nella proposta originale di Chaum le monete avevano un +valore fisso e potevano essere spese solo nella loro totalità. Pagare +grandi somme con monete denominate in centesimi sarebbe stato poco +efficiente; quindi~\cite{Okamoto}, \cite{Camenisch2005}, \cite{Canard} +e~\cite{Dold} idearono modi per affrontare il problema. Queste soluzioni +comprendono protocolli per dare il resto o rendere divisibili le monete. + +Un secondo problema riguarda gli errori nelle transazioni dovuti ad +interruzioni della rete. In questo caso, il sistema deve garantire che +i fondi rimangano in possesso del consumatore senza pregiudicare la +privacy. L'\textit{Endorsed E-Cash} proposto da\cite{Camenisch2007}, +così come da~\cite{Dold}, affrontano entrambi questo problema. Molte +delle soluzioni violano le garanzie sulla privacy per i clienti che +utilizzano queste funzionalità e tutte, tranne Taler, violano il +requisito della trasparenza del reddito. + +La terza questione importante, spesso trascurata, è la trasparenza del +reddito e quindi la conformità con i requisiti AML e KYC. \cite{Fuchsbauer} +hanno deliberatamente progettato il loro sistema di disintermediazione +per fornire una semantica più simile al contante. Tuttavia, la +disintermediazione totale è in genere difficile da concialiare con le +normative AML e KYC dato che diventa impossibile raggiungere qualsiasi +livello di responsabilità. Un esempio di tale architettura è ZCash, un +registro distribuito (\textit{ledger}) che nasconde dalla rete le +informazioni sul pagatore, sul beneficiario e sull'importo della +transazione, rendendolo quindi il sistema di pagamento perfetto per la +criminalità online. Solo Taler offre sia una privacy costante per i +clienti che la trasparenza del reddito, fornendo al contempo un sistema +di resto efficiente, scambi atomici~\cite[vedi][]{Camenisch2007} e la +possibilità di ripristinare i portafogli dal backup. + +Per quanto riguarda i sistemi di pagamento per le CBDC, \cite{Danezis} +hanno progettato un \textit{ledger} scalabile per RSCoin. Si tratta +fondamentalmente di un sistema RTGS che viene protetto utilizzando la +stessa crittografia che si usa in Bitcoin. Come Taler, il design utilizza +il \textit{sharding} del database per consentire la scalabilità lineare. +Tuttavia, la soluzione di Danezis e Meiklejohn non prevede alcuna +disposizione per la privacy e manca di elementi per l'integrazione +pratica del design con i sistemi e i processi bancari esistenti. + +L'EUROchain della Banca Centrale Europea\cite[vedi][]{ECB} è un altro +prototipo di CBDC con registro distribuito. Simile all'architettura +proposta in questo documento, EUROchain utilizza un'architettura a due +livelli in cui le banche commerciali agiscono come intermediari. Una +differenza cruciale è il modo in cui i sistemi cercano di combinare +privacy e conformità con la normativa antiriciclaggio (AML). Mentre nel +nostro progetto l'autorità di regolamentazione può imporre un limite +alla somma di denaro elettronico che un titolare di conto bancario può +prelevare in un determinato periodo di tempo, EUROchain emette un numero +limitato di «voucher di anonimato» che garantiscono al destinatario un +numero limitato di transazioni senza controlli AML. Poiché questi voucher +sembrano essere privi di qualsiasi token di valore, non è chiaro come +il design possa impedire l'emergere di un mercato nero per i «voucher +di anonimato». Inoltre, la nozione di anonimato di EUROchain è molto +diversa, in quanto i loro «voucher di anonimato» eliminano solo alcuni +controlli AML, preservando la capacità delle banche commerciali di +sapere in che modo i clienti spendono il denaro elettronico. Laddove chi +paga utilizzando Taler interagisce direttamente con i venditori per +spendere il proprio contante elettronico, il sistema EUROchain chiede +ai pagatori di istruire le proprie banche commerciali per accedere alle +CBDC. Pertanto, EUROchain non emette direttamente token di valore ai +consumatori, affida invece ai consumatori il compito di autenticarsi +presso la propria banca commerciale per accedere alle CBDC che la +banca centrale detiene effettivamente in deposito a garanzia. Non è +quindi evidente quali siano i vantaggi di EUROchain in termini di +privacy, prestazioni o sicurezza rispetto all'attuale denaro in deposito. + +\section{Conclusione}\label{7.-conclusione} + +Con l'emergere di Bitcoin e valute digitali come Diem (già nota come +Libra) recentemente proposte dai colossi del web, le banche centrali +affrontano una crescente concorrenza da parte di operatori privati che +offrono la propria alternativa digitale al contante fisico. Le decisioni +delle banche centrali sull'emissione o meno di una CBDC dipendono dalla +loro valutazione dei benefici e dei rischi di una CBDC. È probabile che +questi vantaggi e rischi, nonché le circostanze giurisdizionali +specifiche che definiscono l'ambito di applicazione di una CBDC al +dettaglio, differiscano da un paese all'altro. + +Se una banca centrale decide di emettere una CBDC al dettaglio, +proponiamo una CBDC basata su token che combina la privacy delle +transazioni con la conformità alle normative KYC, AML e CFT. Tale CBDC +non sarebbe in concorrenza con i depositi presso le banche commerciali, +replicherebbe piuttosto il contante fisico, limitando quindi i rischi di +stabilità finanziaria e di perturbazione della politica monetaria. + +Abbiamo dimostrato che lo schema qui proposto sarebbe efficiente ed +economico quanto i moderni sistemi RTGS gestiti dalle banche centrali. +I pagamenti elettronici con la nostra CBDC richiederebbero solo un +semplice database e minuscole quantità di larghezza di banda per le +transazioni. L'efficienza e l'economicità di questa soluzione, insieme +alla maggiore facilità d'uso da parte del consumatore determinata dal +passaggio dall'autenticazione all'autorizzazione, rendono questo schema +probabilmente il primo a supportare l'annoso obiettivo dei micropagamenti +online. Inoltre, l'uso di monete per firmare crittograficamente contratti +elettronici consente anche l'impiego di contratti intelligenti. Ciò +potrebbe anche portare all'emergere di applicazioni completamente nuove +per i sistemi di pagamento. Sebbene il nostro sistema non sia basato su +DLT, può essere facilmente integrato con tali tecnologie se richiesto +dalle future infrastrutture del mercato finanziario. + +Altrettanto importante, una CBDC al dettaglio deve rimanere, come il +contante fisico, un bene rispettoso della privacy sotto il controllo +individuale dei cittadini. Lo schema proposto in questo studio soddisfa +questo criterio e consente alle banche centrali di evitare gravi sfide +alla loro politica monetaria e alla stabilità finanziaria sfruttando al +contempo i vantaggi del passaggio al digitale. + +\newpage +\bibliographystyle{agsm} +\bibliography{cbdc} + +\end{document} |