1263 lines
74 KiB
TeX
1263 lines
74 KiB
TeX
% 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}
|