1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
|
% The Spanish pdf looks too crowded. For Italian, maybe bigger font
% and/or extra space between lines/paragraphs?
%\renewcommand{\abstractname}{Sommario}
%\renewcommand{\refname}{Riferimenti bibliografici}
\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage{url}
\usepackage{amsmath}
\usepackage{hyperref}
\usepackage{graphicx}
\usepackage{natbib}
\usepackage[italian]{babel}
\title{Come emettere una moneta digitale di banca centrale}
\author{David Chaum\footnote{david@chaum.com} \\
xx Network \and
Christian Grothoff\footnote{christian.grothoff@bfh.ch} \\
BFH\footnote{Università di Scienze Applicate di Berna}
\ e Progetto GNU \and
Thomas Moser\footnote{thomas.moser@snb.ch} \\
Banca Nazionale Svizzera}
\date{Questa versione: febbraio 2022 \\
Prima versione: maggio 2020}
\begin{document}
\maketitle
\begin{abstract}
Con l'emergere di Bitcoin e delle criptovalute stabili (per es. Diem,
già nota come Libra) recentemente proposte dai colossi del web, le
banche centrali affrontano una crescente concorrenza da parte di
operatori privati che offrono la propria alternativa digitale al
contante fisico. Non trattiamo qui la questione normativa se una banca
centrale debba emettere o meno una moneta digitale. Contribuiamo invece
all'attuale dibattito di ricerca spiegando in che modo una banca centrale
potrebbe farlo, se lo volesse. Proponiamo un sistema basato su token
senza tecnologia di registro distribuito, e mostriamo che le monete
elettroniche emesse in passato, basate solo su software, possono essere
migliorate per tutelare la privacy nelle transazioni, soddisfare i
requisiti normativi in modo efficace e offrire un livello di protezione
resistente ai computer quantistici contro il rischio sistemico per
la privacy. Né la politica monetaria né la stabilità del sistema
finanziario sarebbero realmente interessate da questo sistema dal
momento che una CBDC emessa in questo modo replicherebbe il contante
fisico anziché i depositi bancari. \\
JEL: E42, E51, E52, E58, G2
\\
Parole chiave: monete digitali, banca centrale, CBDC, firma cieca,
criptovalute stabili, \textit{stablecoins}
\end{abstract}
\vspace{40pt}
\section*{Ringraziamenti}
Vorremmo ringraziare Michael Barczay, Roman Baumann, Morten Bech,
Nicolas Cuche, Florian Dold, Andreas Fuster, Stefan Kügel, Benjamin
Müller, Dirk Niepelt, Oliver Sigrist, Richard Stallman, Andreas Wehrli
e tre collaboratori anonimi per i loro commenti e suggerimenti. Le
posizioni, le opinioni, i risultati e le conclusioni o raccomandazioni
espresse in questo documento sono strettamente quelle degli autori.
Non riflettono necessariamente le posizioni della Banca nazionale
svizzera (BNS). La BNS declina ogni responsabilità per eventuali
errori, omissioni o inesattezze che dovessero comparire nel documento.
Traduzione: Dora Scilipoti \& Luca Saiu
\newpage
%\tableofcontents
\section{Introduzione}\label{1.-introduzione}
Dall'avvento dei personal computer negli anni ottanta, e più
specificamente da quando nel 1991 la \textit{National Science
Foundation} revocò le restrizioni sull'uso di Internet per scopi
commerciali, c'è stata una ricerca sulla creazione di moneta digitale
per i pagamenti online. La prima proposta è stata quella
di~\cite{Chaum1983}. Sebbene tali metodi siano stati attuati, non hanno
preso piede; le carte di credito sono invece diventate il metodo più
diffuso per i pagamenti online. La proposta di~\cite{Nakamoto} per una
versione puramente \textit{peer-to-peer} di moneta digitale e il
conseguente lancio di Bitcoin avvenuto con successo hanno inaugurato
una nuova era di ricerca e sviluppo di valute digitali. La piattaforma
CoinMarketCap elenca oltre 5.000 criptovalute. Recentemente le banche
centrali hanno iniziato a considerare, o almeno a studiare,
l'emissione di monete
digitali~\cite[vedi][]{AuerBoehme,AuerCornelli,Boar,Kiff,Mancini-Griffoli}.
Attualmente le banche centrali emettono due tipi di moneta: (i)
riserve sotto forma di conti di regolamento presso le banche centrali,
destinate solo agli operatori dei mercati finanziari, e (ii) divisa
disponibile per tutti sotto forma di banconote. Di conseguenza, la
letteratura sulla moneta digitale di banca centrale (\textit{Central Bank
Digital Currency} - CBDC) distingue tra (a) CBDC all'ingrosso ad
accesso ristretto e (b) CBDC al dettaglio disponibile per il
pubblico~\cite[si veda, ad esempio,][]{Bech}.
Una CBDC all'ingrosso sarebbe meno destabilizzante per il sistema attuale
dato che le banche e gli operatori dei mercati finanziari hanno già
accesso alla moneta digitale della banca centrale sotto forma di conti
presso questa istituzione, che utilizzano per regolare i pagamenti
interbancari. La domanda qui è se la tokenizzazione della moneta di banca
centrale e la tecnologia di registro distribuito (\textit{Distributed Ledger
Technology} - DLT) offrano vantaggi particolari rispetto ai sistemi con
regolamento lordo in tempo reale (\textit{Real-Time Gross Settlement} - RTGS)
esistenti. Finora la risposta è negativa, almeno per i pagamenti
interbancari nazionali~\cite[vedi][]{Chapman}.
Una CBDC al dettaglio, che sarebbe una nuova forma di moneta di banca
centrale disponibile per il pubblico, potrebbe essere più destabilizzante
per il sistema attuale, a seconda di come è progettata. Più una CBDC
compete con i depositi delle banche commerciali, maggiore è la minaccia
ai finanziamenti bancari, con effetti potenzialmente negativi sul credito
bancario e sull'attività economica~\cite[vedi][]{Agur}. Tuttavia, una
CBDC al dettaglio potrebbe anche essere vantaggiosa~\cite[vedi][]{Bordo,Berentsen,Bindseil,Niepelt,Riksbank,BoE}.
Mettere a disposizione di tutti una moneta elettronica di banca centrale
esente dal rischio di controparte potrebbe migliorare la stabilità e la
resilienza del sistema di pagamenti al dettaglio. Potrebbe inoltre fornire
un'infrastruttura di pagamento neutrale per incoraggiare la concorrenza,
l'efficienza e l'innovazione. Nel complesso, è probabile che i costi e i
benefici di una CBDC al dettaglio differiscano da un paese all'altro. Per
il punto di vista della Banca nazionale svizzera, che non ha in programma
l'emissione di una CBDC al dettaglio, si veda~\cite{Jordan}.
Nel presente documento analizziamo la CBDC al dettaglio, ma senza
affrontare la questione se una banca centrale \emph{debba o meno} emetterla.
Ci concentriamo invece sul possibile design di una CBCD. L'interesse
per la progettazione di CBDC è recentemente aumentato
considerevolmente~\cite[si, veda ad esempio,][]{Allen,BoE}. Il design che
proponiamo differisce notevolmente da altre proposte. Il nostro sistema
si basa sulla tecnologia eCash descritta da~\cite{Chaum1983,Chaum1990},
migliorandola. In particolare, proponiamo una CBDC basata su token, solo
con software e senza tecnologia di registro distribuito. La DLT è
un'architettura interessante in assenza di un operatore centrale o se le
entità che interagiscono non accettano di nominare un operatore centrale
fidato. Questo non è certo il caso di una CBDC al dettaglio emessa da una
\emph{banca centrale}. Distribuire il registro delle transazioni della
banca centrale con una \textit{blockchain} non fa che aumentare i costi
di transazione; non porta alcun vantaggio tangibile nell'implementazione
da parte di una banca centrale. L'utilizzo della DLT per emettere moneta
digitale può essere utile in assenza di una banca centrale (ad esempio,
il progetto Sovereign delle Isole Marshall) o se l'intenzione esplicita
è quella di fare a meno di una banca centrale (ad esempio,
Bitcoin).\footnote{Potrebbero esserci casi opportuni di utilizzo della
DLT per le infrastrutture dei mercati finanziari, come gli scambi digitali,
dove sorge la questione di come incorporare la moneta della banca centrale
all'interno di una struttura DLT per eseguire i regolamenti. Tuttavia,
in tali situazioni i potenziali benefici della DLT, ad esempio costi
inferiori o riconciliazione automatica, non derivano da un'emissione
decentralizzata di moneta di banca centrale.}
La CBDC basata su token che proponiamo consente anche di preservare
una caratteristica fondamentale del contante fisico: la privacy nelle
transazioni. Spesso si sostiene che l'uso della crittografia per la
tutela della privacy richieda così tanta potenza di calcolo da rendere
impraticabile la sua implementazione su dispositivi
portatili~\cite[vedi][]{Allen}. Sebbene questo possa essere vero nel
caso di una tecnologia di registro distribuito, dove la tracciabilità
delle transazioni è necessaria per prevenire la doppia spesa~\citet{Narayanan},
non lo è nel caso proposto in questo documento, dove si ha un protocollo
di firma cieca di tipo Chaum e la partecipazione di una banca centrale.
La nostra CBDC, basata su firme cieche e un'architettura a due livelli,
garantisce una tutela della privacy nelle transazioni perfetta e
quanto-resistente, fornendo al contempo protezioni sociali che sono di
fatto più potenti rispetto a quelle delle banconote per la lotta al
riciclaggio di denaro (\textit{Anti-Money Laundering} - AML) e al
finanziamento del terrorismo (\textit{Counter Terrorism Financing} - CFT).
La privacy nelle transazioni è importante per tre motivi. In primo luogo,
protegge gli utenti dal potenziale abuso di monitoraggio e sorveglianza
da parte dei governi. Anche se si pensa di non avere nulla da nascondere,
i piani di sorveglianza di massa restano problematici, se non altro per
il rischio di errori e abusi, soprattutto se condotti senza trasparenza
e responsabilità~\cite[vedi][]{Solove}. In secondo luogo, la privacy nelle
transazioni protegge gli utenti dallo sfruttamento dei dati da parte dei
fornitori di servizi di pagamento. Infine, salvaguarda gli utenti dalla
controparte nelle transazioni in quanto esclude possibili comportamenti
opportunistici successivi o rischi per la sicurezza dovuti a negligenza
o mancata protezione dei dati dei clienti~\cite[vedi][]{Kahn2005}.
Questo documento è strutturato come segue: nella Sezione II si spiega
la differenza tra la moneta di banca centrale e altri tipi di moneta.
Nella Sezione III si esaminano i modelli di CBDC tipici e generici prima
di proporre il nostro progetto nella Sezione IV. Si considerano poi
gli aspetti normativi e le politiche (V) e il relativo lavoro (VI).
Infine, si conclude (VII).
\section{Cos'è la moneta di banca centrale?}
\label{2.-cos'è-la-moneta-di-banca-centrale}
La moneta è un attivo che può essere utilizzato per acquistare beni e
servizi. Per essere considerato moneta, l'attivo deve essere accettato
da entità diverse dall'emittente. Ecco perché i voucher, ad esempio,
non sono considerati moneta. La moneta autentica deve essere
\emph{comunemente} accettata come mezzo di scambio. Sebbene la moneta
abbia altre funzioni, ad esempio come unità di conto e riserva di valore,
la sua caratteristica distintiva è la sua funzione di mezzo di scambio.
Normalmente l'unità di conto (cioè come avvengono la fissazione dei
prezzi e la contabilizzazione dei debiti) coincide per ragioni
pratiche con il mezzo di scambio. Una separazione può tuttavia
verificarsi se il valore del mezzo di scambio manca di stabilità
rispetto ai beni e servizi scambiati.\footnote{Ciò può accadere
spontaneamente in un ambito caratterizzato da un'inflazione elevata,
ad esempio quando i prezzi sono quotati in USD ma i pagamenti vengono
effettuati in valuta locale. Lo stesso vale per i pagamenti in Bitcoin,
dove i prezzi sono solitamente fissati in USD o altre valute locali a
causa dell'elevata volatilità del Bitcoin. Una separazione può anche
essere progettata appositamente, come nel caso
dell'\textit{Unidad de Fomento} (UF) in Cile o i Diritti Speciali di
Prelievo (DSP) del Fondo Monetario Internazionale (FMI). Tuttavia,
anche in questi casi lo scopo è quello di avere un'unità di conto più
stabile.} La moneta deve anche essere una riserva di valore per fungere
da mezzo di scambio perché deve preservare il suo potere d'acquisto tra
il momento in cui si riceve e quello in cui si spende. In ogni modo,
ci sono molti altri attivi che fungono da riserva di valore, come azioni,
obbligazioni, metalli preziosi e immobili. Pertanto, la caratteristica
di riserva di valore non è distintiva della moneta.
In un'economia moderna, il pubblico utilizza due tipi diversi di
moneta: (a) moneta statale e (b) moneta privata. La moneta statale viene
generalmente emessa dalla banca centrale, che agisce in qualità di
agente dello Stato. La moneta della banca centrale è disponibile per
alcune istituzioni finanziarie sotto forma di depositi presso la banca
centrale (riserve) e per il pubblico sotto forma di valuta (banconote e
monete), nota anche come «contante». In una economia moderna con valuta
fiat, tale moneta non ha un valore intrinseco. Legalmente è una passività
della banca centrale, sebbene non sia rimborsabile. Nella maggior parte
dei paesi, la moneta della banca centrale è definita come avente corso
legale, il che significa che deve essere accettata per il pagamento dei
debiti monetari, comprese le tasse e le sanzioni legali. Sebbene ciò
garantisca un certo valore alla moneta della banca centrale, lo status
di corso legale non è sufficiente per mantenere un valore stabile. È la
politica monetaria della banca centrale che mantiene il valore della
moneta. Mantenere la stabilità dei prezzi, vale a dire un valore stabile
della moneta rispetto a quello dei beni e dei servizi scambiati, è
infatti una delle principali responsabilità delle banche centrali.
La maggior parte dei pagamenti in un'economia moderna vengono effettuati
con moneta privata emessa dalle banche commerciali ed è costituita da
depositi bancari a vista che le persone detengono presso queste banche.
Sono depositi che si posssono utilizzare mediante assegni, carte di
debito, carte di credito e altri mezzi di trasferimento di denaro e
costituiscono una passività della banca commerciale di riferimento. Una
caratteristica fondamentale di questi depositi è che le banche commerciali
garantiscono la convertibilità su richiesta in moneta della banca centrale
ad un prezzo fisso, vale a dire, alla pari. I depositanti possono prelevare
i propri fondi in contante o trasferirli ad un valore fisso di 1:1. Le
banche commerciali mantengono stabile il valore della propria moneta
ancorandola a quella della banca centrale.
Tuttavia, in un sistema di riserva frazionaria, una banca commerciale,
anche se solvibile, potrebbe non avere liquidità a sufficienza per
onorare la sua promessa di convertire i depositi bancari in moneta
della banca centrale (ad esempio, nel caso di una corsa agli sportelli)
in modo tale che i clienti non possano prelevare i propri soldi. Una
banca può anche diventare insolvente e fallire, e di conseguenza i
clienti possono perdere denaro. Per questo motivo le banche commerciali
sono soggette a regolamentazioni volte a mitigare tali rischi.
Una differenza notevole tra la moneta di una banca centrale e la
moneta privata emessa da una banca commerciale è, pertanto, che
quest'ultima comporta un rischio di controparte. Una banca centrale
può sempre adempiere ai suoi obblighi utilizzando la propria moneta
non rimborsabile. In un'economia nazionale, la moneta della banca
centrale è l'unico attivo monetario esento da rischi di credito e di
liquidità. È pertanto l'attivo tipicamente preferito per regolare i
pagamenti nelle infrastrutture dei mercati finanziari (si veda, per
esempio, \textit{CPMI-IOSCO Principles for Financial Market
Infrastructures}, 2012). Un'altra differenza risiede nella capacità
della moneta della banca centrale di sostenere il sistema monetario
nazionale fornendo un valore di riferimento con cui la moneta delle
banche commerciali mantiene la piena convertibilità.
A parte le banche commerciali, altre entità private tentano
occasionalmente di emettere moneta; le criptovalute sono solo il
tentativo più recente. Ma a differenza dei depositi bancari, tale
moneta non è comunemente accettata come mezzo di scambio. Questo vale
anche per Bitcoin, la criptovaluta più ampiamente accettata. Un
ostacolo all'utilità delle criptovalute come mezzo di scambio è l'elevata
volatilità del loro valore. In risposta a questo problema sono emerse
le criptovalute stabili, cosiddette «stablecoins». Le
\textit{stablecoin} generalmente tentano di stabilizzare il proprio
valore in due modi: imitando le banche centrali (\textit{stablecoin}
algoritmiche) o imitando le banche commerciali e strumenti di
investimento (\textit{stablecoin} ancorate ad attivi).\footnote{Per una
tassonomia delle \textit{stablecoin}, si veda~\cite{Bullmann}.}
Le «\textit{stablecoin} algoritmiche» si basano su algoritmi per regolare
l'offerta della moneta. In altre parole, cercano di stabilizzarne il
prezzo attraverso una «politica monetaria algoritmica». Esistono
esempi di tali \textit{stablecoin} (per es. Nubits), ma finora nessuna è
riuscita a stabilizzare il proprio valore per molto tempo.
Le \textit{stablecoin} «ancorate ad attivi» differiscono in base al tipo
di attivo che utilizzano e ai diritti concessi ai possessori. I tipi di
attivi generalmente utilizzati sono: valuta (riserve di banche centrali,
banconote o depositi presso banche commerciali), materie prime (come
l'oro), titoli e talvolta altre criptovalute. La capacità di un tale
schema di stabilizzare il valore della moneta rispetto agli attivi
sottostanti dipende in modo cruciale dai diritti legali acquisiti dai
detentori della moneta. Se una \textit{stablecoin} è riscattabile ad un
prezzo fisso (ad esempio, 1 moneta = 1 USD o 1 moneta = 1 oncia d'oro),
la stabilità si può teoricamente ottenere.\footnote{Se possa stabilizzare
il valore della \textit{stablecoin} anche rispetto ai beni e servizi
scambiati dipende essenzialmente da quanto sia stabile il valore degli
attivi su cui poggia rispetto al valore dei beni e servizi.} Tale strategia
riproduce essenzialmente quella delle banche commerciali garantendo la
convertibilità nell'attivo sottostante su richiesta. Tuttavia, a differenza
dei depositi bancari, che in genere sono coperti solo parzialmente dalle
riserve della banca centrale, le \textit{stablecoin} sono spesso
completamente garantite dalle riserve di attivi sottostanti al fine di
evitare il rischio di liquidità, principalmente perché non dispongono di
tutele pubbliche tali come l'assicurazione dei depositi e il prestatore
di ultima istanza che offrono invece le banche regolamentate.
Le \textit{stablecoin} che utilizzano le valute come attivi sono anche
dette «stablecoin a valuta fiat». Detenere il 100\% delle
garanzie sotto forma di valuta (banconote o depositi bancari) non risulta però
molto redditizio. Di conseguenza, i fornitori di \textit{stablecoin} hanno
un buon motivo per rispiarmiare sugli attivi passando ad un sistema di
riserva frazionaria, proprio come hanno fatto le banche
commerciali.\footnote{L'incertezza sulla garanzia delle
\textit{stablecoin} può essere uno dei motivi per cui vengono scambiate
al di sotto del loro valore nel mercato parallelo~\cite[vedi][]{Lyons}.
Casi simili si sono storicamente verificati anche con le banconote, quando
erano ancora emesse dalle banche commerciali. Le banconote venivano
scambiate a prezzi scontati nel mercato parallelo prima che l'emissione
fosse nazionalizzata e trasferita alle banche centrali come monopolio.}
Ciò comporta la riduzione degli attivi meno redditizi al minimo ritenuto
necessario per soddisfare il requisito di convertibilità e l'aumento
degli attivi liquidi a rendimento più elevato come i titoli di stato.
Questo migliora la redditività ma aumenta nel contempo il livello
di rischio. Tuttavia, anche se una \textit{stablecoin} fosse garantita
interamente da depositi presso le banche commerciali, rimarrebbe comunque
vulnerabile ai rischi di insolvenza del credito e di liquidità della
relativa banca. Tale rischio può essere evitato effettuando i depositi
presso la banca centrale in modo che siano le riserve di quest'ultima a
garantire la \textit{stablecoin}. Tali \textit{stablecoin} sono state
chiamate «CBDC sintetiche»~\cite[][]{Adrian}. È importante sottolineare che
queste \textit{stablecoin} non sono moneta di banca centrale e quindi
non costituiscono una CBDC in quanto non sono registrate come passività
della banca centrale e, pertanto, rimangono soggette al rischio di
controparte, ovvero al rischio di fallimento dell'emittente.
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.
% References to Kumhof, Bindseil below should render like this:
% valore (Kumhof & Noone, 2018 e Bindseil, 2020).
\bibpunct{(}{)}{ e }{a}{}{,}
Esistono anche proposte per ridurre il rischio di disintermediazione
restringendo o scoraggiando l'uso della CBDC come riserva di valore. Una
delle proposte è di limitare la quantità di CBDC che si può possedere.
Una seconda proposta consiste nell'applicare un tasso di interesse
variabile ai conti in CBDC, in modo che il rendimento sia sempre
sufficientemente inferiore a quello dei conti nelle banche commerciali,
arrivando eventualmente fino a tassi negativi, in modo da rendere la CBDC
meno attraente come riserva di valore~\cite[][]{Kumhof,Bindseil}. Oltre a ciò,
per evitare le corse agli sportelli \cite[][]{Kumhof} suggeriscono che la
CBDC non dovrebbe essere emessa a fronte di depositi bancari ma solo a
fronte di obbligazioni come i titoli di stato. Nel complesso, una CBDC
basata su conti richiederebbe un'analisi più approfondita di queste
problematiche.
% Back to default style.
\bibpunct{(}{)}{ e }{,}{}{,}
\subsection{CBDC Basata su token e legata al hardware}
\label{cbdc-basata-su-token-e-legata-al-hardware}
In alternativa ai conti deposito, una banca centrale potrebbe emettere
token elettronici. Tecnicamente ciò richiede un sistema per garantire che
i token elettronici non possano essere copiati facilmente. Le funzioni
fisicamente non clonabili~\cite[vedi][]{Katzenbeisser} e le aree
sicure nell'hardware~\cite[vedi][]{Alves,Pinto} sono due tecnologie
possibili per la prevenzione della copia digitale. Le funzioni
fisicamente non clonabili, tuttavia, non possono essere scambiate su
Internet (eliminando di fatto l'uso principale delle CBDC) e le precedenti
funzionalità di sicurezza nell'hardware per la prevenzione della copia
sono state ripetutamente compromesse~\cite[si veda, ad esempio,][]{Wojtczuk,Johnston,Lapid}.
Un vantaggio fondamentale delle CBDC basate su token rispetto a quelle
basate su conti è che i sistemi tokenizzati funzionerebbero offline,
ovvero, gli utenti potrebbero scambiare token (\textit{peer-to-peer})
senza coinvolgere la banca centrale, proteggendo così la privacy e la
libertà delle persone. Tuttavia, la disintermediazione che si verifica
quando gli utenti possono scambiare token elettronici senza
intermediari bancari che eseguano i controlli per la conoscenza dei
clienti e le procedure per la lotta al riciclaggio di denaro e al
finanziamento del terrorismo renderebbe difficile la lotta alla
criminalità.
Le schede SIM sono oggi il mezzo più ampiamente disponibile per un
sistema di pagamento sicuro basato su hardware, ma comportano anche
dei rischi. L'esperienza~\cite[si veda, ad esempio,][]{Soukup,Garcia,Kasper,CCC}
suggerisce che qualsiasi dispositivo economicamente riproducibile in grado
di memorizzare token con valore monetario, che una persona possa possedere
e che consenta transazioni offline --- e quindi il furto mediante
clonazione delle informazioni in esso contenute --- sarà l'obiettivo di
attacchi di contraffazione riusciti non appena il valore economico
dell'attacco risulti sostanziale. Tali attacchi provengono anche da
utenti che forzano il proprio hardware~\cite[vedi][]{Allen}. Per
limitare l'impatto di una compromissione, i sistemi con carte di pagamento
che sono stati precedentemente implementati dependono dalla resistenza
alle manomissioni in combinazione con il rilevamento delle frodi.
Tuttavia, il rilevamento delle frodi richiede la capacità di identificare
i pagatori e tenere traccia dei clienti, il che non è compatibile con la
privacy nelle transazioni.
\section{Una CBDC basata su token progettata per tutelare la privacy}
\label{4.-una-cbdc-basata-su-token-progettata-per-tutelare-la-privacy}
La CBDC qui proposta è di tipo «solo software», semplicemente
un'applicazione per smartphone che non richiede alcun hardware aggiuntivo.
Il design fa affidamento su eCash e GNU Taler. Taler fa parte del progetto
GNU, il cui fondatore, Richard Stallman, ha coniato il termine
«\emph{Software Libero}», ora spesso indicato come \textit{Free/Libre
and Open Source Software} (FLOSS).\footnote{Per ulteriori informazioni
su GNU, si veda \url{https://www.gnu.org} e \cite{Stallman}. GNU Taler
è rilasciato sotto la licenza libera \textit{GNU Affero General Public
License} del Progetto GNU. Altri programmi del progetto GNU noti tra gli
economisti sono \textit{R} e \textit{GNU Regression, Econometrics and
Time-series Library} (GRETL). Per un'analisi dei vantaggi del FLOSS
rispetto al software proprietario nel campo della ricerca, si veda~\cite{Baiocchi}, \cite{Yalta2008} e \cite{Yalta2010}.
Sulle licenze libere e open source, si veda~\cite{Lerner}.} Il software
è considerato libero se la sua licenza concede agli utenti quattro libertà
essenziali: la libertà di eseguire il programma come si desidera, la
libertà di studiare il programma e modificarlo, la libertà di ridistribuire
copie del programma e la libertà di distribuire copie delle versioni
modificate del programma. Il software libero non impedisce la
commercializzazione; fornire supporto tecnico per il software è un modello
di business standard per il FLOSS.
Dato il gran numero di parti interessate coinvolte in una CBDC al
dettaglio (la banca centrale, il settore finanziario, i venditori e
i clienti) e l'importanza critica dell'infrastruttura, una CBDC al
dettaglio deve essere basata sul FLOSS. Imporre una soluzione
proprietaria, che comporta la dipendenza da un fornitore specifico,
sarebbe probabilmente un ostacolo all'adozione fin dall'inizio. Con il
FLOSS, tutte le parti interessate hanno accesso a ogni dettaglio della
soluzione e il diritto di adattare il software alle proprie esigenze.
Ciò facilita l'integrazione e migliora l'interoperabilità e la
concorrenza tra i fornitori.\footnote{Tuttavia, l'hardware privato
potrebbe avere un ruolo da svolgere. La protezione degli archivi delle
chiavi e di alcune funzioni di controllo, ad esempio, può essere un'area
dove l'hardware dedicato valutato solo da un numero limitato di esperti
può presentare dei vantaggi, nella misura in cui tale sicurezza sia solo
additiva.} Consente inoltre alla banca centrale di soddisfare i requisiti
di trasparenza e responsabilità. I vantaggi del FLOSS riguardo la
sicurezza sono anche ampiamente riconosciuti. La disponibilità del codice
sorgente e la libertà di modificarlo facilitano l'identificazione degli
errori e la loro rapida correzione. \footnote{Ad esempio, un bollettino
sulla sicurezza informatica emesso dall'Agenzia per la sicurezza nazionale
degli Stati Uniti (NSA) nell'aprile 2020 esorta gli utenti a dare la
priorità al software libero nella scelta e nell'utilizzo dei servizi
collaborativi per le comunicazioni su Internet: «Lo sviluppo open source
garantisce trasparenza sulla robustezza del codice e la sua conformità
alle migliori pratiche di programmazione, evitando l'introduzione di
vulnerabilità o punti deboli che potrebbero mettere a rischio utenti e
dati» (U/OO/134598-20).}
Nell'architettura che proponiamo, tutte le interazioni tra consumatori
e venditori si fanno con le banche commerciali, ma la creazione di moneta
e il database sono forniti esclusivamente dalla banca centrale. Le banche
commerciali autenticano i clienti quando ritirano CBDC così come i
venditori o beneficiari quando le ricevono. Quando spendono CBDC,
invece, i clienti o pagatori devono solo autorizzare le transazioni senza
bisogno di identificarsi. I pagamenti risultano più economici, più facili
e più veloci, evitando al contempo interferenze con la privacy~\cite[][]{Dold}.
L'autenticazione dei clienti quando ritirano CBDC, nonché dei venditori
o beneficiari quando le ricevono, consente altresì di adempire alle
normative sulla conoscenza dei clienti e sulla lotta al riciclaggio di
denaro e al finanziamento del terrorismo.
La CBDC che si propone in questo documento è un vero e proprio
strumento digitale al portatore perché quando l'utente preleva una
somma di denaro sotto forma di numero, tale numero viene «accecato» o
nascosto dallo smartphone con un'apposita crittografia. Nel sistema
stesso, una moneta è una coppia di chiavi pubblica-privata dove la
chiave privata è nota solo al proprietario della moneta.\footnote{In
Bitcoin, un sistema basato su conti, la coppia di chiavi è un conto
dove la chiave pubblica rappresenta l'«indirizzo» e quindi una sorta di
«identità», anche se pseudonimo.} La moneta trae il suo valore
finanziario dalla firma della banca centrale apposta sulla chiave
pubblica della moneta. La banca centrale firma con la propria chiave
privata e detiene più coppie di chiavi di valore per apporre la firma
cieca su monete di diverso valore unitario. Il venditore può utilizzare
la corrispondente «chiave pubblica» della banca centrale per verificare
la firma. Tuttavia, al fine di garantire che la moneta non sia stata
copiata e già ritirata da un altro beneficiario (cioè che non sia stata
«spesa due volte»), il venditore deve depositare la moneta affinché la
banca centrale possa confrontarla con un archivio di monete ritirate.
Poiché né la banca commerciale né la banca centrale vedono il numero
della moneta durante il prelievo, in seguito, quando il venditore
deposita la moneta, non si sa quale utente l'abbia ritirata. L'accecamento
e la privacy che ne deriva fanno di questa tipologia di CBDC un vero e
proprio strumento digitale al portatore.
Nell'analisi che segue forniamo una panoramica approfondita della
tecnologia e mostriamo come si può integrare con il sistema bancario
esistente per creare una CBDC. \citet{Dold} fornisce ulteriori
dettagli.
\subsection{Componenti fondamentali}\label{componenti-fondamentali}
Di seguito si descrivono i componenti principali del protocollo, comprese
le basi matematiche per una delle possibili rappresentazioni delle
primitive crittografiche utilizzate, allo scopo di illustrare in
che modo potrebbe funzionare un'implementazione. Considerando che
esistono altri modelli matematici equivalenti per ciascun componente,
presentiamo solo la più semplice delle soluzioni sicure a noi note.
\emph{Firme digitali.} L'idea che sta alla base delle firme digitali in
uno schema di firma a chiave pubblica è quella di garantire che il
titolare della chiave privata sia l'unico in grado di firmare un
messaggio, mentre la chiave pubblica consente a chiunque di verificare
la validità della firma.\footnote{La crittografia a chiave pubblica è
stata introdotta da~\cite{Diffie} e le prime implementazioni di firme
digitali sono state quelle di~\cite{Rivest}.} Il risultato della funzione
di verifica della firma è la dichiarazione binaria «vero» o «falso». Se
il messaggio è firmato con la chiave privata che appartiene alla chiave
pubblica di verifica, il risultato è «vero», altrimenti è «falso».
Nella nostra proposta il messaggio è una moneta o una banconota con un
numero di serie, e la firma della banca centrale ne attesta la
validità. Sebbene GNU Taler utilizzi per impostazione predefinita le
moderne firme EdDSA~\cite[vedi][]{Bernstein2012}, qui presentiamo un
semplice schema di firma crittografica basato su RSA~\cite[][]{Rivest}, un
sistema crittografico ben studiato.\footnote{Per un'analisi della
lunga storia del crittosistema RSA e uno studio degli attacchi a questo
sistema, si veda~\cite{Boneh}.} Tuttavia, in linea di principio, è
possibile utilizzare qualsiasi tecnologia di firma crittografica
(DSA, ECDSA, EdDSA, RSA, ecc.)
Per generare una chiave RSA, il firmatario prende prima due grandi
numeri primi indipendenti $p$ e $q$ e calcola $n = \emph{pq}$,
nonché la funzione phi di Eulero
$\phi(n) = (p - 1)(q - 1)$.
Quindi, si può utilizzare qualsiasi $e$ con $1 < e < \phi(n)$ e
$\gcd(e, \phi(n)) = 1$ per definire una chiave pubblica $(e,n)$.
La condizione che il massimo comune denominatore ($\texttt{MCD}$) di $e$ e
$\phi(n)$ debba essere 1 (cioè, che devono essere
primi tra loro) assicura che l'inverso di
$e \mod \phi(n)$ esista.
Questo inverso è la
corrispondente chiave privata $d$. Data $\phi(n)$, la chiave
privata $d$ può essere calcolata mediante l'algoritmo esteso
di Euclide tale che
$d \cdot e \equiv 1 \mod \phi(n)$.
Data la chiave privata $d$ e la chiave pubblica $(e, n)$, una semplice
firma RSA
$s$ su un messaggio $m$ è
$s \equiv m^{d} \mod n$.
Per verificare la firma si calcola
$m' \equiv s^{e} \mod n$.
Se $m'$ e $m$ corrispondono, la firma è valida e dimostra che il
messaggio è stato firmato con la chiave privata che corrisponde alla
chiave pubblica di verifica (autenticazione del messaggio) e che il
messaggio non è stato modificato durante il transito (integrità del
messaggio). In pratica, le firme vengono poste sull'hash dei messaggi
piuttosto che sui messaggi stessi. Le funzioni di hash calcolano le
impronte digitali dei messaggi (\textit{digest}), che sono identificatori
univoci e brevi per i messaggi. Firmare un hash breve è molto più veloce
che firmare un messaggio di grandi dimensioni, e la maggior parte degli
algoritmi di firma funzionano solo su input relativamente brevi.\footnote{Nel
caso del crittosistema RSA, il limite di lunghezza è di
$\log_{2}n$ bit.}
\emph{Firme cieche.} Utilizziamo le firme cieche introdotte
da~\cite{Chaum1983} per tutelare la privacy degli acquirenti. Una firma
cieca viene utilizzata per creare una firma crittografica per un messaggio
senza rivelare al firmatario il contenuto del messaggio. Nella nostra proposta,
ciò impedisce alle banche commerciali e alla banca centrale di poter risalire
all'acquirente tracciando gli acquisti. In linea di principio, la nostra
proposta funziona con qualsiasi sistema di firma cieca, ma la soluzione migliore
rimane la variante basata su RSA descritta da~\cite{Chaum1983}.
L'accecamento viene eseguito dai clienti, che accecano le proprie
monete prima di trasmetterle alla banca centrale per la firma. I
clienti non devono quindi affidare alla banca centrale la tutela della
propria privacy. Inoltre, l'accecamento con RSA fornirebbe protezione
della privacy anche contro gli attacchi informatici quantistici. La
banca centrale, dal canto suo, predispone più coppie di chiavi di
valore per apporre la firma cieca su monete di diverso valore
unitario, e fornisce le corrispondenti chiavi pubbliche
$(e, n)$ per tali valori.
Sia $f$ il valore di hash di una moneta e quindi l'identificatore
univoco per questa moneta. Il cliente che preleva la moneta prima
genera un fattore di accecamento casuale $b$ e calcola
$f' \equiv fb^{e} \mod n$
con la chiave pubblica della banca centrale per quel valore.
La moneta accecata $f'$ viene quindi trasmessa alla banca centrale per
la firma. La banca centrale firma $f'$ con la sua chiave
privata $d$ calcolando la firma cieca
$s' \equiv \left(f' \right)^{d} \mod n$, appone
la firma $s'$ alla moneta accecata $f'$ e restituisce la coppia
$(s',f')$ al cliente. Il cliente può quindi rimuovere l'accecamento
della firma calcolando
$s \equiv s'b^{- 1} \mod n$.
Ciò è possibile perché
$\left( f' \right)^d = f^db^{ed} = f^db$, e quindi
moltiplicando $s'$ con $b^{- 1}$ si ottiene $f^d$, che è una firma RSA
valida su $f$ come prima:
$s^e \equiv f^{de} \equiv f \mod n$.
Nella proposta originale di Chaum, le monete erano dei semplici
gettoni. Quel che vogliamo, invece, è che i consumatori possano
utilizzare le firme digitali per stipulare contratti. A tal fine, ogni
volta che un portafoglio digitale preleva una moneta, in primo luogo
crea per la moneta una chiave privata casuale $c$ e calcola la
corrispondente chiave pubblica $C$ per creare firme digitali con i
normali sistemi di firma crittografica (come DSA, ECDSA, EdDSA e
RSA). Quindi si deriva $f$ mediante una funzione di hash crittografica
dalla chiave pubblica $C$, prima che la banca centrale ne apponga la
firma cieca (utilizzando un nuovo fattore di accecamento casuale per
ciascuna moneta). Ora il cliente può utilizzare $c$ per firmare
elettronicamente gli acquisti, spendendo così la moneta.
Come visto sopra, la banca centrale andrebbe a predisporre coppie di
chiavi diverse per ogni valore unitario di moneta e pubblicherebbe le
chiavi pubbliche che i clienti userebbero per prelevare denaro. Queste
chiavi di valore, e quindi le monete, avrebbero una data di scadenza
prima della quale dovrebbero essere spese o scambiate con monete
nuove. Ai clienti verrebbe concesso un certo periodo di tempo per
scambiare le monete. Un processo simile esiste per le banconote
fisiche, dove le serie di banconote vengono regolarmente rinnovate per
essere dotate delle più recenti caratteristiche di sicurezza, tranne
per il fatto che le banconote generalmente rimangono in circolazione
per decenni anziché per pochi anni o mesi.\footnote{In Svizzera,
ad esempio, la Banca nazionale svizzera ha iniziato a ritirare dalla
circolazione l'ottava serie di banconote nell'aprile 2016. Questa serie
era stata messa in circolazione alla fine degli anni novanta. Dal 1
gennaio 2020, tuttavia, tutte le banconote a partire dalla sesta serie
(emesse nel 1976) fino alle serie future restano valide e possono essere
scambiate a tempo indeterminato con banconote correnti.}
Da un punto di vista tecnico, una data di scadenza offre due vantaggi.
In primo luogo, migliora l'efficienza del sistema perché la banca
centrale può cancellare i dati scaduti, evitando così di dover
archiviare e poi cercare in un elenco sempre crescente di monete
(spese) per rilevare una doppia spesa. In secondo luogo, riduce i
rischi per la sicurezza dato che la banca centrale non deve
preoccuparsi di attacchi alle proprie chiavi (private) di valore ($d$)
scadute. Inoltre, anche se una chiave privata venisse compromessa, il
periodo durante il quale l'attaccante può utilizzarla è breve. In aggiunta,
l'addebito di una commissione di cambio consentirebbe alla banca centrale di
applicare tassi di interesse negativi, se ritenuto necessario. La banca centrale
potrebbe anche, se lo desidera, fissare un limite di conversione per cliente in
considerazione dell'antiriciclaggio e l'antiterrorismo (soglia di «contante») o
per motivi di stabilità finanziaria (per prevenire accaparramenti e corse agli
sportelli).
\emph{Protocollo di scambio di chiavi.} GNU Taler utilizza un protocollo
di scambio di chiavi in un modo particolare per fornire un collegamento
tra la moneta originale e il resto reso per quella stessa moneta. Ciò
garantisce che il resto possa sempre essere reso senza compromettere
la trasparenza del reddito e la privacy dei consumatori. Lo stesso
meccanismo si può utilizzare per i rimborsi anonimi ai clienti. Il
protocollo gestisce anche i guasti alla rete e ai componenti,
assicurando che i pagamenti siano andati a buon fine o siano stati
definitivamente annullati e che tutte le parti abbiano una prova
crittografica dell'esito. Questo corrisponde all'incirca agli scambi
atomici nei protocolli \textit{interledger} o allo scambio equo nei
tradizionali sistemi \textit{e-cash}.
La costruzione matematica più comune per un protocollo di scambio di
chiavi è la costruzione~\cite{Diffie}), che
consente a due parti di derivare una chiave segreta condivisa. A tale
scopo, condividono due parametri di dominio $p$ e $g$, che possono
essere pubblici, dove $p$ è un numero primo grande e $g$ è una radice
primitiva modulo $p$.\footnote{Un intero $g$ è una radice primitiva
modulo $p$ se per ogni intero $a$ coprimo a $p$ esiste un intero $k$
per il quale
$g^k \equiv a \mod p$.
In pratica, $g$ dovrebbe essere una radice primitiva $(p-1)$-esima, detta
anche generatore, al fine di prevenire attacchi a sottogruppi come quelli
Pohlig-Hellman~\cite[vedi][]{Lim}.} Ora, le due parti scelgono le loro
chiavi private \emph{a} e \emph{b}, che sono due numeri interi grandi.
Con queste chiavi private e i parametri di dominio, generano le
rispettive chiavi pubbliche
$A \equiv g^{a} \mod p$ e $B \equiv g^{b} \mod p$.
Ciascuna parte può ora utilizzare la propria chiave privata e la chiave
pubblica dell'altra parte per calcolare la chiave segreta condivisa
$k \equiv \left( g^b \right)^{a} \equiv \left( g^{a} \right)^{b} \equiv g^{\text{ab}} \mod p$.\footnote{
Lo stesso meccanismo potrebbe essere utilizzato per garantire
che le monete non vengano trasferite a terzi durante il prelievo. A
questo scopo, gli utenti devono salvaguardare una chiave di identità a
lungo termine. Il processo di prelievo potrebbe quindi essere
costruito allo stesso modo di quello utilizzato da GNU Taler per dare
il resto, tranne per il fatto che quando si preleva dal conto bancario
del cliente verrebbe utilizzata la chiave d'identità a lungo termine
del cliente al posto della moneta originale. Tuttavia, le garanzie
sulla privacy potrebbero decadere se il cliente non protegge la chiave
d'identità a lungo termine, con il conseguente rischio di furto di
tutte le monete residue. Dato che il rischio nei trasferimenti a terzi
quando si prelevano monete è basso, non è chiaro se questa riduzione
del rischio possa essere un buon compromesso.}
Per ottenere il resto, il cliente parte dalla chiave privata della
moneta parzialmente spesa $c$. Sia $C$ la chiave pubblica corrispondente,
per esempio
$C = g^{c} \mod p$.
Quando la moneta fu parzialmente spesa in precedenza, la banca centrale
registrò la transazione relativa a $C$ nel proprio database. Per
semplicità, assumiamo che esista un valore unitario che corrisponda
esattamente a questo valore residuo. In caso contrario, il protocollo si
riavvia finché non viene reso tutto il resto. Sia $(e,n)$ la
chiave di valore per il resto da rendere.
Per ottenere il resto, l'acquirente crea prima $\kappa$ chiavi di
trasferimento private $t_{i}$ per
$i \in \left\{ 1,\ldots,\kappa \right\}$ e calcola le
corrispondenti chiavi pubbliche $T_{i}$. Queste chiavi di
trasferimento $\kappa$ sono semplicemente coppie di chiavi
pubbliche-private che consentono al cliente di eseguire localmente il
protocollo di scambio di chiavi, con il cliente che gioca su entrambi
i lati del processo, $\kappa$ volte tra $c$ e ogni $t_{i}$.
Se si usa Diffie-Hellman come protocollo per lo scambio di chiavi, si
ottiene
$T_{i} \equiv g^{t_{i}} \mod p$.
Il risultato sono tre trasferimenti
$K_{i} \equiv \emph{KX}(c,t_{i})$. Il protocollo di scambio di chiavi
può essere utilizzato in diversi modi per ottenere lo stesso valore
$K_{i} \equiv \emph{KX}(C,t_{i}) = \emph{KX}(c,T_{i})$.
Data $K_{i}$, il cliente utilizza una funzione crittografica hash $H$
per ricavare i valori
$(b_{i},c_{i}) \equiv H(K_{i})$, dove
$b_{i}$ è un fattore di accecamento valido per la chiave di valore
$(e,n)$ e $c_{i}$
è una chiave privata per la nuova moneta da ottenere come resto.
$c_{i}$ deve essere adatta sia per creare firme crittografiche sia per
un uso futuro con il protocollo di scambio di chiavi
(come $c$, per ottenere resto a partire dal resto).
Sia $C_{i}$ la chiave pubblica corrispondente a $c_{i}$.
Il cliente chiede quindi alla banca centrale di creare una firma cieca su
$C_{i}$ per $i \in \{ 1,\ldots,\kappa\}$.\footnote{Se dovesse essere
utilizzato il crittosistema RSA per le firme cieche, useremmo
$f \equiv \emph{FDH}_{n}(C_{i})$, dove
$\emph{FDH}_{n}()$
è l'hash del dominio completo sul dominio $n$.} In questa richiesta, il
cliente si impegna anche con le chiavi pubbliche
$T_{i}$.
La richiesta è autorizzata mediante una firma effettuata con la chiave
privata $c$.
Invece di restituire direttamente la firma cieca, la banca centrale
chiede prima al cliente di dimostrare che ha utilizzato correttamente la
costruzione di cui sopra fornendo
$\gamma \in \left\{ 1,\ldots,\kappa \right\}$.
Il cliente deve quindi mostrare alla banca centrale la
$t_{i}$ per $i \neq \gamma$.
La banca centrale può quindi calcolare
$K_{i} \equiv \emph{KX}(C,t_{i})$ e ricavare i valori
$(b_{i},c_{i})$. Se per tutte le
$i \neq \gamma$ la $t_{i}$ fornita dimostra che il cliente ha utilizzato
correttamente la costruzione, la banca centrale restituisce la firma
cieca su $C_{\gamma}$.
Se il cliente non fornisce una prova corretta, il valore residuo della
moneta originale viene perso. Questo penalizza efficacemente coloro che
tentano di eludere la trasparenza del reddito con un'aliquota fiscale
stimata di $1 - \frac{1}{\kappa}$.
Per evitare che un cliente cospiri con un venditore che sta tentando di
evadere il fisco, la banca centrale consente a chiunque
conosca $C$ di ottenere, in qualsiasi momento, i valori di
$T_{\gamma}$
e le firme cieche di tutte le monete collegate alla moneta originaria $C$.
Ciò permette al possessore della moneta originaria, che conosce $c$, di
calcolare
$K_{\gamma} \equiv \emph{KX}( c,T_{\gamma})$
e da lì ricavare
$(b_{i},c_{i})$
per, infine, rimuovere la firma cieca. Di conseguenza, un venditore che
nasconde il proprio reddito in questo modo formerebbe solo un'accordo
economico limitato con il cliente invece di ottenere il controllo esclusivo.
\hypertarget{architettura-del-sistema}{%
\subsection{Architettura del sistema}\label{architettura-del-sistema}}
Uno degli obiettivi principali della nostra architettura è garantire
che le banche centrali non debbano interagire direttamente con i
clienti né conservare alcuna informazione su di loro, ma solo tenere
un elenco delle monete spese. L'autenticazione è delegata alle banche
commerciali, che dispongono già dell'infrastruttura necessaria. I
protocolli di prelievo e deposito raggiungono la banca centrale
tramite una banca commerciale in qualità di intermediaria. Dal punto
di vista del cliente, il processo è analogo al prelievo di contanti da
un bancomat. La transazione tra la banca commerciale dell'utente e la
banca centrale avviene in background. La procedura per il prelievo di
CBDC è illustrata nel diagramma~\ref{fig:fig1}.
\begin{figure}[h!]
\includegraphics[width=\textwidth]{diagramma1-it.png}
\caption{Prelievo di CBDC}
\label{fig:fig1}
\end{figure}
Il cliente (1) invia i dati di accesso alla propria banca commerciale
utilizzando le relative procedure di autenticazione e autorizzazione.
Quindi il telefono (o il computer) del cliente ottiene la chiave di
valore pubblica $(e, n)$ fornita dalla banca centrale per quel valore; (2)
calcola quindi una coppia di chiavi per la moneta, con una chiave
privata $c$ e una chiave pubblica $C$, e sceglie un fattore di accecamento
$b$. La chiave pubblica della moneta viene quindi sottoposta a hash
($\to$ $f$) e accecata ($\to$ $f'$). Quindi il dispositivo del cliente (3)
invia $f'$ insieme all'autorizzazione a prelevare la moneta e ad
addebitarla dal conto del cliente presso la banca commerciale tramite un
canale sicuro stabilito. La banca commerciale (4) addebita quindi
l'importo dal conto deposito del cliente, (5) autorizza digitalmente la
richiesta utilizzando la firma digitale specifica della propria filiale
e inoltra la richiesta e la moneta accecata alla banca centrale per la
firma. La banca centrale (6) sottrae il valore della moneta dal conto
della banca commerciale, appone la firma cieca sulla moneta
utilizzando la chiave privata che detiene per il relativo valore e (7)
restituisce la firma cieca $s'$ alla banca commerciale. La banca
commerciale (8) inoltra la firma cieca $s'$ al portafoglio elettronico
del cliente. Infine, il dispositivo del cliente (9) utilizza $b$ per
rimuovere l'accecamento dalla firma ($\to$ $f$) e salva la moneta appena
coniata $(c, s)$.
Un cliente e un venditore negoziano un contratto commerciale. Il
cliente (1) utilizza una moneta elettronica per firmare il contratto o
l'atto di vendita con la chiave privata $c$ della moneta e trasmette la
firma al venditore. La firma di una moneta su un contratto con una
moneta valida è l'istruzione del cliente di pagare il venditore, che è
identificato dal conto bancario nel contratto. Se una singola moneta
non fosse sufficiente per coprire l'importo totale, i clienti possono
firmare il contratto con più monete. Il venditore (2) convalida quindi
la firma della moneta sul contratto e la firma $s$ della banca centrale
su $f$, che corrisponde a quella della moneta $C$ con le rispettive
chiavi pubbliche, e inoltra la moneta firmata (insieme alle
informazioni sul conto del venditore) alla banca commerciale del
venditore. La banca commerciale del venditore (3) conferma che il
venditore è un suo cliente e inoltra la moneta firmata alla banca
centrale. La banca centrale (4) verifica le firme e controlla il
proprio database per accertarsi che la moneta non sia già stata spesa.
Se tutto è in ordine, la banca centrale (5) aggiunge la moneta
all'elenco delle monete spese, l'accredita sul conto della banca
commerciale presso la banca centrale e (6) invia una conferma in tal
senso alla banca commerciale. Quindi la banca commerciale (7)
accredita la moneta sul conto del venditore e (8) gli invia una
notifica. Il venditore (9) consegna il prodotto o servizio al cliente.
L'intera operazione richiede poche centinaia di millisecondi.
\begin{figure}[h!]
\includegraphics[width=\textwidth]{diagramma2-it.png}
\caption{Spendere e depositare CBDC}
\label{fig:fig2}
\end{figure}
\hypertarget{considerazioni-sulla-sicurezza}{%
\subsection{Considerazioni sulla sicurezza}
\label{considerazioni-sulla-sicurezza}}
Nella nostra proposta, occorre che la banca centrale gestisca un
database e un servizio online ad alta disponibilità. Poiché le monete
elettroniche possono essere copiate dagli utenti, solo con i controlli
online si può prevenire in modo efficace la doppia spesa. Sebbene
nella teoria esistano soluzioni per identificare a posteriori gli
utenti che effettuano una doppia spesa~\cite[vedi][]{Chaum1990},
queste soluzioni creano rischi economici sia per gli utenti che per la
banca centrale a causa del ritardo nell'identificazione di
transazioni fraudolente. Il rilevamento online della doppia spesa
elimina questo rischio, ma significa anche che sarà impossibile
effettuare le transazioni se la connessione Internet alla banca
centrale non è disponibile.
La banca centrale dovrà anche proteggere la riservatezza delle chiavi
private che utilizza per firmare le monete e altri messaggi di
protocollo. Se le chiavi di firma della banca centrale dovessero
essere compromesse, ad esempio da un computer quantistico, da un
attacco fisico ai \textit{datacenter} o anche da qualche nuovo algoritmo
imprevisto, è possibile rimborsare gli utenti --- in tutta sicurezza e
senza compromettere la privacy --- tutte le monete non spese. La banca
centrale annuncerebbe la revoca della chiave tramite l'\textit{Application
Programming Interface} (API), che verrebbe rilevata dai portafogli,
avviando quindi il seguente protocollo di aggiornamento: l'utente
svela alla banca centrale la chiave pubblica $C$ della moneta, la firma
$s$ della banca centrale e il fattore di accecamento $b$, consentendo così
alla banca centrale di verificare il legittimo prelievo dell'utente e
di rimborsare il valore della moneta non spesa. Per rilevare una
possibile compromissione della propria chiave, la banca centrale può
monitorare il database in cerca di depositi che eccedano i prelievi.
\subsection{Scalabilità e costi}\label{scalabilità-e-costi}
Lo schema che proponiamo sarebbe efficiente ed economico quanto i
moderni sistemi RTGS attualmente utilizzati dalle banche centrali.
La scalabilità si riferisce al costo di aumentare la potenza di
calcolo in modo che si possa concludere un numero crescente di
transazioni in tempi adeguati. Il costo complessivo del sistema può
essere basso in quanto la CBDC qui proposta si basa interamente su
software. Le monete spese devono essere conservate fino alla scadenza
della coppia di chiavi di valore utilizzata per firmare le monete, ad
esempio tramite un ciclo annuale continuo, che mantiene limitata la
dimensione del database. La potenza di calcolo e la larghezza di banda
necessarie aumentano della stessa quantità per ogni transazione, spesa
o deposito addizionali, dato che le transazioni sono intrinsecamente
indipendenti l'una dall'altra. Questa ulteriore potenza si ottiene
semplicemente aggiungendo più hardware, una pratica spesso conosciuta
come partizionamento o \textit{sharding}. Grazie al cosiddetto
\textit{consistent hashing}, le aggiunte di hardware non risultano
dirompenti. Si può anche utilizzare qualsiasi tipo di database.
Più nello specifico, la logica del \textit{front-end} presso la banca
centrale deve solo eseguire poche operazioni di firma, e un singolo
processore può eseguirne alcune migliaia al secondo~\cite[vedi][]{Bernstein2020}.
Se un unico sistema non fosse sufficiente, è facile aggiungere altri
server \textit{front-end} e invitare le varie banche commerciali a
bilanciare le loro richieste nella \textit{server farm} o
utilizzare un sistema di bilanciamento del carico per distribuire le
richieste all'interno dell'infrastruttura della banca centrale.
I server \textit{front-end} devono comunicare con un database per
effettuare le transazioni e prevenire la doppia spesa. Un unico server
di database moderno dovrebbe essere in grado di gestire in modo
affidabile decine di migliaia di operazioni al secondo. Le operazioni
possono essere facilmente distribuite su più server di database
semplicemente assegnando a ciascuno un intervallo di valori da
gestire. Tale configurazione garantisce che le singole transazioni non
incrocino mai le partizioni. Pertanto, anche i sistemi \textit{back-end}
dovrebbero scalare in modo lineare con le risorse di calcolo messe a
disposizione, partendo sempre da una solida base di riferimento per un
singolo sistema.
I \textit{front-end} devono anche comunicare con i \textit{back-end} per
mezzo di un'interconnessione. Queste interconnessioni possono
supportare un gran numero di transazioni al secondo. La dimensione di
una singola transazione è in genere di circa 1–10 kilobyte. Pertanto,
i \textit{datacenter} di oggi, che scambiano informazioni a 400 Gbit/s,
possono supportare milioni di transazioni al secondo.
Infine, il costo totale del sistema è basso. Probabilmente il costo
principale sia rappresentato dall'archiviazione sicura per
molti anni di 1–10 kilobyte per transazione. Gli esperimenti su un
prototipo di GNU Taler che utilizzava i prezzi di \textit{Amazon Web Service}
hanno stabilito che il costo del sistema (archiviazione, larghezza di
banda e capacità di calcolo) su larga scala sarebbe inferiore a
0,0001 USD per transazione (per i dettagli sui dati, si veda~\citet{Dold}).
% In the reference for Dold, the year 2019 should be either not between parentesis
% or there should be a comma after Dold: Dold, 2019.
\section{Considerazioni normative e politiche}
\label{5.-considerazioni-normative-e-politiche}
Nella soluzione che proponiamo, la banca centrale non conosce
l'identità dei consumatori o dei venditori né l'importo totale delle
transazioni, ma vede solo il momento in cui le monete elettroniche vengono
rilasciate e quando vengono riscattate. Le banche commerciali continuano a
fornire l'autenticazione cruciale di consumatori e venditori e, in particolare,
custodiscono le informazioni che acquisiscono per la conoscenza dei clienti
(KYC). Le banche commerciali osservano quando i venditori ricevono fondi e, se
necessario, possono limitare la quantità di CBDC per transazione che
un singolo venditore può ricevere. Inoltre, le transazioni sono
collegate ai relativi contratti con i clienti. La conseguente
trasparenza del reddito consente al sistema di soddisfare i requisiti
delle normative sulla lotta al riciclaggio di denaro e al
finanziamento del terrorismo (AML e CFT). In caso vengano rilevate
anomalie nei redditi dei venditori, la banca commerciale e
l'autorità fiscale o giudiziaria possono ottenere e ispezionare i
contratti relativi ai pagamenti sospetti al fine di verificarne la
legittimità. La trasparenza del reddito risultante è anche una forte
misura contro l'evasione fiscale perché i venditori non possono
sottodichiarare il proprio reddito o evadere le tasse sulle vendite.
Nel complesso, il sistema implementa gli approcci \textit{privacy-by-
design} e \textit{privacy-by-default} (come richiesto, ad esempio,
dal Regolamento generale sulla protezione dei dati dell'UE, GDPR). I
venditori non apprendono necessariamente l'identità dei propri clienti,
le banche possiedono solo le informazioni necessarie sulle attività dei
propri clienti e la banca centrale non ha accesso ai dettagli sulle
attività dei cittadini.
In alcuni paesi le normative impongono limiti per i prelievi e i
pagamenti in contanti. Tali restrizioni possono essere implementate
anche per la CBDC nel progetto proposto. Ad esempio, è possibile
stabilire una soglia per l'importo giornaliero che i consumatori possono
prelevare, oppure limitare l'importo totale di CBDC che le banche
commerciali possono convertire.
La disintermediazione del settore bancario è uno dei rischi di
instabilità finanziaria spesso sollevato per quanto riguarda la BCDC
al dettaglio. In particolare, una CBDC al dettaglio potrebbe
facilitare l'accumulo di ingenti somme di denaro della banca
centrale, il che potrebbe avere un impatto negativo sul finanziamento
alle banche mediante depositi perché il pubblico deterrebbe meno
denaro sotto forma di depositi bancari. Per i paesi le cui valute
fungono da valute rifugio, ciò potrebbe anche portare ad un aumento
degli afflussi di capitali durante i periodi globali di avversione al
rischio, dando luogo ad ulteriori pressioni sui tassi di cambio.
Quello che quindi potrebbe rappresentare un serio problema nel caso di
una CBDC basata su conti, lo sarebbe molto meno con una CBDC basata
su token. Innanzitutto, l'accumulo di una CBDC basata su token comporta
rischi di furto o perdita simili a quelli legati all'accumulo di
contanti. Tenere poche centinaia di dollari su uno smartphone è
probabilmente un rischio accettabile per molti, ma detenere una somma
molto alta è probabilmente un rischio meno accettabile. Pertanto, non
ci aspettiamo un accaparramento significativamente maggiore rispetto a
quello del denaro fisico.
Tuttavia, se l'accumulo o la massiccia conversioni dei depositi
bancari in CBDC dovessero destare proccupazione, la banca centrale
avrebbe diverse opzioni. Come si è spiegato, secondo il progetto
proposto le banche centrali fissano una data di scadenza per tutte le
chiavi di firma, il che implica che in una data prestabilita le monete
firmate con quelle chiavi diventano non valide. Alla scadenza delle
chiavi di valore, i consumatori devono scambiare con monete nuove le
monete che erano state firmate con le vecchie chiavi; l'autorità di
regolamentazione può facilmente fissare una soglia di conversione per
cliente per creare un limite rigido alla quantità di CBDC che ogni
individuo può accumulare. Inoltre, la banca centrale potrebbe addebitare
commissioni, se necessario. Una commissione di aggiornamento quando le monete
stanno per scadere significherebbe nella pratica tassi di interesse negativi
sulla CBDC per limitare il suo fascino come riserva di valore, come
suggerisce~\cite{Bindseil}. Si tratterebbe infatti della diretta attuazione
dell'idea di Silvio Gesell di applicare una tassa di possesso sulla moneta,
notoriamente citata da~\cite{Keynes} e ripresa da~\cite{Goodfriend},
\cite{Buiter}, e~\cite{Agarwal}.
Per quanto riguarda le implicazioni in termini di politica monetaria,
non dovrebbero esserci cambiamenti reali perché la nostra CBDC è
progettata per replicare il contante piuttosto che i depositi bancari.
L'emissione, il prelievo e il deposito della nostra CBCD corrispondono
esattamente all'emissione, al prelievo e al deposito di banconote. È
possibile che la velocità di circolazione di una CBDC al dettaglio sia
diversa da quella del contante fisico, ma questo non dovrebbe
rappresentare un problema significativo per la politica monetaria.
\hypertarget{lavori-correlati}{%
\section{Lavori correlati}\label{6.-lavori-correlati}}
Come segnalato in precedenza, la CBDC che si propone in questo documento
si basa su eCash e GNU Taler.\footnote{L'implementazione di eCash
da parte della società DigiCash negli anni novanta è documentata su
\url{https://www.chaum.com/ecash}.} A partire dalla proposta originale
e-Cash di Chaum, la ricerca si è concentrata su tre questioni principali.
In primo luogo, nella proposta originale di Chaum le monete avevano un
valore fisso e potevano essere spese solo nella loro totalità. Pagare
grandi somme con monete denominate in centesimi sarebbe stato poco
efficiente; quindi~\cite{Okamoto}, \cite{Camenisch2005}, \cite{Canard}
e~\cite{Dold} idearono modi per affrontare il problema. Queste soluzioni
comprendono protocolli per dare il resto o rendere divisibili le monete.
Un secondo problema riguarda gli errori nelle transazioni dovuti ad
interruzioni della rete. In questo caso, il sistema deve garantire che
i fondi rimangano in possesso del consumatore senza pregiudicare la
privacy. L'\textit{Endorsed E-Cash} proposto da~\cite{Camenisch2007},
così come da~\cite{Dold}, affrontano entrambi questo problema. Molte
delle soluzioni violano le garanzie sulla privacy per i clienti che
utilizzano queste funzionalità e tutte, tranne Taler, violano il
requisito della trasparenza del reddito.
La terza questione importante, spesso trascurata, è la trasparenza del
reddito e quindi la conformità con i requisiti AML e KYC. \cite{Fuchsbauer}
hanno deliberatamente progettato il loro sistema di disintermediazione
per fornire una semantica più simile al contante. Tuttavia, la
disintermediazione totale è in genere difficile da concialiare con le
normative AML e KYC dato che diventa impossibile raggiungere qualsiasi
livello di responsabilità. Un esempio di tale architettura è ZCash, un
registro distribuito (\textit{ledger}) che nasconde dalla rete le
informazioni sul pagatore, sul beneficiario e sull'importo della
transazione, rendendolo quindi il sistema di pagamento perfetto per la
criminalità online. Solo Taler offre sia una privacy costante per i
clienti che la trasparenza del reddito, fornendo al contempo un sistema
di resto efficiente, scambi atomici~\cite[vedi][]{Camenisch2007} e la
possibilità di ripristinare i portafogli dal backup.
Per quanto riguarda i sistemi di pagamento per le CBDC, \cite{Danezis}
hanno progettato un \textit{ledger} scalabile per RSCoin. Si tratta
fondamentalmente di un sistema RTGS che viene protetto utilizzando la
stessa crittografia che si usa in Bitcoin. Come Taler, il design utilizza
il \textit{sharding} del database per consentire la scalabilità lineare.
Tuttavia, la soluzione di Danezis e Meiklejohn non prevede alcuna
disposizione per la privacy e manca di elementi per l'integrazione
pratica del design con i sistemi e i processi bancari esistenti.
L'EUROchain della Banca Centrale Europea\cite[vedi][]{ECB} è un altro
prototipo di CBDC con registro distribuito. Simile all'architettura
proposta in questo documento, EUROchain utilizza un'architettura a due
livelli in cui le banche commerciali agiscono come intermediari. Una
differenza cruciale è il modo in cui i sistemi cercano di combinare
privacy e conformità con la normativa antiriciclaggio (AML). Mentre nel
nostro progetto l'autorità di regolamentazione può imporre un limite
alla somma di denaro elettronico che un titolare di conto bancario può
prelevare in un determinato periodo di tempo, EUROchain emette un numero
limitato di «voucher di anonimato» che garantiscono al destinatario un
numero limitato di transazioni senza controlli AML. Poiché questi voucher
sembrano essere privi di qualsiasi token di valore, non è chiaro come
il design possa impedire l'emergere di un mercato nero per i «voucher
di anonimato». Inoltre, la nozione di anonimato di EUROchain è molto
diversa, in quanto i loro «voucher di anonimato» eliminano solo alcuni
controlli AML, preservando la capacità delle banche commerciali di
sapere in che modo i clienti spendono il denaro elettronico. Laddove chi
paga utilizzando Taler interagisce direttamente con i venditori per
spendere il proprio contante elettronico, il sistema EUROchain chiede
ai pagatori di istruire le proprie banche commerciali per accedere alle
CBDC. Pertanto, EUROchain non emette direttamente token di valore ai
consumatori, affida invece ai consumatori il compito di autenticarsi
presso la propria banca commerciale per accedere alle CBDC che la
banca centrale detiene effettivamente in deposito a garanzia. Non è
quindi evidente quali siano i vantaggi di EUROchain in termini di
privacy, prestazioni o sicurezza rispetto all'attuale denaro in deposito.
\section{Conclusione}\label{7.-conclusione}
Con l'emergere di Bitcoin e valute digitali come Diem (già nota come
Libra) recentemente proposte dai colossi del web, le banche centrali
affrontano una crescente concorrenza da parte di operatori privati che
offrono la propria alternativa digitale al contante fisico. Le decisioni
delle banche centrali sull'emissione o meno di una CBDC dipendono dalla
loro valutazione dei benefici e dei rischi di una CBDC. È probabile che
questi vantaggi e rischi, nonché le circostanze giurisdizionali
specifiche che definiscono l'ambito di applicazione di una CBDC al
dettaglio, differiscano da un paese all'altro.
Se una banca centrale decide di emettere una CBDC al dettaglio,
proponiamo una CBDC basata su token che combina la privacy delle
transazioni con la conformità alle normative KYC, AML e CFT. Tale CBDC
non sarebbe in concorrenza con i depositi presso le banche commerciali,
replicherebbe piuttosto il contante fisico, limitando quindi i rischi di
stabilità finanziaria e di perturbazione della politica monetaria.
Abbiamo dimostrato che lo schema qui proposto sarebbe efficiente ed
economico quanto i moderni sistemi RTGS gestiti dalle banche centrali.
I pagamenti elettronici con la nostra CBDC richiederebbero solo un
semplice database e minuscole quantità di larghezza di banda per le
transazioni. L'efficienza e l'economicità di questa soluzione, insieme
alla maggiore facilità d'uso da parte del consumatore determinata dal
passaggio dall'autenticazione all'autorizzazione, rendono questo schema
probabilmente il primo a supportare l'annoso obiettivo dei micropagamenti
online. Inoltre, l'uso di monete per firmare crittograficamente contratti
elettronici consente anche l'impiego di contratti intelligenti. Ciò
potrebbe anche portare all'emergere di applicazioni completamente nuove
per i sistemi di pagamento. Sebbene il nostro sistema non sia basato su
DLT, può essere facilmente integrato con tali tecnologie se richiesto
dalle future infrastrutture del mercato finanziario.
Altrettanto importante, una CBDC al dettaglio deve rimanere, come il
contante fisico, un bene rispettoso della privacy sotto il controllo
individuale dei cittadini. Lo schema proposto in questo studio soddisfa
questo criterio e consente alle banche centrali di evitare gravi sfide
alla loro politica monetaria e alla stabilità finanziaria sfruttando al
contempo i vantaggi del passaggio al digitale.
\newpage
\bibliographystyle{agsm}
\bibliography{cbdc}
\end{document}
|