diff options
Diffstat (limited to 'doc/cbdc-es/cbdc-es.tex')
| -rw-r--r-- | doc/cbdc-es/cbdc-es.tex | 1283 |
1 files changed, 1283 insertions, 0 deletions
diff --git a/doc/cbdc-es/cbdc-es.tex b/doc/cbdc-es/cbdc-es.tex new file mode 100644 index 000000000..8c87c3e0d --- /dev/null +++ b/doc/cbdc-es/cbdc-es.tex @@ -0,0 +1,1283 @@ +\documentclass[a4paper,10pt]{article} %tamaño de papel y letra ``base'' +\usepackage[utf8]{inputenc} +\usepackage[T1]{fontenc} +\usepackage[top=2cm, +bottom=2cm, +includefoot, +left=3cm, +right=2cm, +footskip=1cm]{geometry} +\usepackage{url} +\IfFileExists{lmodern.sty}{\usepackage{lmodern}}{} +\usepackage{graphicx} +\usepackage{mathpazo} +\usepackage{amsmath} +\usepackage{mathptmx} +\usepackage{color} +\usepackage[utf8]{inputenc} +\usepackage[T1]{fontenc} +\usepackage[hidelinks]{hyperref} + %\usepackage{natbib,har2nat} +\usepackage{natbib} +\usepackage[spanish]{babel} +\input{eshyphexh.tex} + %\renewcommand{\abstractname}{Resumen} + %\renewcommand{\refname}{Referencias} + % de estas cosas se ocupa \usepackage[spanish]{babel} + + +\title{Cómo Emitir una Moneda Digital del Banco Central} +\author{David Chaum\footnote{david@chaum.com} \\ + xx Network \and + Christian Grothoff\footnote{christian.grothoff@bfh.ch} \\ + BFH\footnote{Universidad de Ciencias Aplicadas de Berna} + \quad y Proyecto GNU \and + Thomas Moser\footnote{thomas.moser@snb.ch}\\ + Banco Nacional de Suiza} +\date{Esta versión: octubre 2021 \\ + Primera versión: mayo 2020} + + + +\begin{document} + +\maketitle + +\begin{abstract} +Con la aparición de Bitcoin y monedas estables propuestas recientemente +por grandes empresas tecnológicas como Diem (antes Libra), los bancos +centrales se enfrentan a la creciente competencia de particulares que +ofrecen su propia alternativa digital al dinero en efectivo. No +abordamos la cuestión normativa de si un un banco central debería o no +emitir una moneda digital del banco central (Central Bank Digital +Currency -- CBDC). Contribuimos en cambio al actual debate de +investigación mostrando de qué manera un banco central podría hacerlo si +así lo deseara. Proponemos un sistema basado en tokens sin tecnología de +libro mayor distribuido, y mostramos que el efectivo electrónico ya +implementado solo mediante software se puede mejorar para preservar la +privacidad en las transacciones, cumplir con los requisitos +reglamentarios de modo convincente y ofrecer un nivel de protección de +resistencia cuántica contra los riesgos sistémicos que amenazan la +privacidad. Ni la política monetaria ni la estabilidad financiera se +verían materialmente afectadas porque una CBDC con este diseño +replicaría el efectivo físico en lugar de los depósitos bancarios. \\ +JEL: E42, E51, E52, E58, G2 +\\ +Keywords: Monedas digitales, banco central, CBDC, firmas ciegas, monedas +estables +\end{abstract} + +\vspace{40pt} + +\section*{Agradecimientos} +Agradecemos a 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, y tres colaboradores +anónimos por sus comentarios y sugerencias. Las ideas, opiniones, +investigaciones y conclusiones o recomendaciones expresadas en este +documento pertenecen estrictamente a los autores. No reflejan +necesariamente los puntos de vista del Banco Nacional de Suiza (BNS). El +BNS no asume ninguna responsabilidad por errores u omisiones ni por la +exactitud de la información contenida en este documento. + +Traducción: Javier Sepulveda \& Dora Scilipoti + + +\newpage + +%\tableofcontents + +\section{Introducción}\label{1.-introducciuxf3n} + +Desde la aparición de los ordenadores personales en los años ochenta, y +especialmente desde que en 1991 la National Science Foundation quitara +las restricciones al uso de Internet para propósitos comerciales, se ha +buscado crear dinero digital para realizar pagos en línea. La primera +propuesta la realizó~\citet{Chaum1983}. A pesar de que tales métodos fueron +implementados, no prosperaron. Fueron en cambio los sistemas con tarjeta +de crédito los que se convirtieron en el método dominante para pagos en +línea. La propuesta de~\citet{Nakamoto} para un sistema P2P de dinero +digital y el posterior lanzamiento exitoso de Bitcoin desataron una +nueva era de investigación sobre el tema y desarrollo de dinero digital. +CoinMarketCap enumera más de 5.000 criptomonedas. Recientemente los +bancos centrales han empezado a considerar, o al menos estudiar, la +emisión de monedas digitales~\cite[véase][]{AuerBoehme,AuerCornelli,Boar,Kiff,Mancini-Griffoli}. + +Actualmente los bancos centrales emiten dos tipos de dinero: (i) +reservas en forma de cuentas de liquidación en los bancos centrales para +determinados participantes del mercado financiero y (ii) moneda en forma +de billetes disponibles para el público. En consecuencia, la +bibliografía sobre la moneda digital del banco central (CBDC) distingue +entre (a) venta de CBDC al por mayor, con acceso limitado, y (b) venta +de CBDC al por menor, accesible al público \cite[véase, p. ej.][]{Bech}. +Una CBDC al por mayor sería menos disruptiva para el sistema +actual debido a que los bancos y los participantes seleccionados del +mercado financiero ya tienen acceso a dinero digital del banco en forma +de cuentas del banco central, que utilizan para liquidar pagos +interbancarios. La cuestión aquí es si la tokenización del dinero de un +banco central y la tecnología de libro mayor distribuido (Distributed +Ledger Technology - DLT) ofrecen beneficios netos en comparación con los +sistemas de liquidación bruta en tiempo real (Real-Time Gross +Settlement - RTGS). Hasta el momento, la conclusión es que no es así, al +menos cuando se trata de pagos interbancarios nacionales~\cite[véase][]{Chapman}. + +Una CBDC al por menor, que sería una nueva forma de dinero del banco +central a disposición del público, podría ser más disruptiva para el +sistema actual, dependiendo de su diseño. Cuanto más compita una CBDC de +este tipo con los depósitos bancarios comerciales, mayor será la amenaza +para la financiación bancaria, con un posible impacto adverso en el +crédito bancario y la actividad económica~\cite[véase][]{Agur}. Sin +embargo, una CBDC al por menor podría también tener +beneficios~\cite[véase][]{Bordo,Berentsen,Bindseil,Niepelt,Riksbank,BoE}. +Poner a disposición de +todos dinero electrónico del banco central sin riesgo de contrapartida +podría mejorar la estabilidad y la resistencia del sistema de pago al +por menor. También podría proporcionar una infraestructura de pago +neutral para promover la competencia, la eficiencia y la innovación. En +general, es probable que los costos y beneficios de una CBDC al por +menor difieran de un país a otro. Para conocer la opinión del Banco +Nacional de Suiza, que no tiene planes de emitir una CBDC al por +menor~\cite[véase][]{Jordan}. + +El presente documento se centra en una CBDC al por menor, pero no abordamos la +cuestión de si un banco central \emph{debería o no} emitir una moneda +CBDC. Nos centramos en cambio en el diseño potencial de una +CBCD. Recientemente ha habido un creciente interés en el diseño de monedas +CBCD (\cite[véase p. ej.][]{Allen,BoE}). El diseño que proponemos difiere +significativamente de otras propuestas. Nuestro sistema se basa en la +tecnología eCash descrita por Chaum~\cite{Chaum1983,Chaum1990}, +mejorándola. En particular, proponemos un sistema para CBCD basado en tokens y +solo mediante software, sin blockchain para la DLT. La DLT es un diseño +interesante en ausencia de un actor principal o si las entidades que +interactúan no concuerdan en nombrar un actor central de confianza. Sin +embargo, este no es el caso de una CBCD al por menor emitida por un +\emph{banco central}. Distribuir el libro mayor del banco central con una +blockchain solo aumenta los costes de transacción, no proporciona beneficios +tangibles en una implementación por parte de un banco central. Utilizar la DLT +para emitir dinero digital puede ser útil si no hay un banco central para +empezar (p. ej. el proyecto Sovereign de las Islas Marshall) o si la +intención explícita es prescindir de un banco central +(p. ej. Bitcoin).\footnote{Puede haber buenos casos de uso para la DLT en el +caso de infraestructura de mercado financiero, tal como los intercambios +digitales, donde surge la cuestión de como obtener dinero del banco central en +la DLT a efectos de liquidación. Sin embargo en esas situaciones, los +beneficios potenciales de la DLT, por ejemplo menos costes o reconciliación +automática, no surgen de una emisión descentralizada del dinero del banco +central.} + +La CBCD basada en tokens que se propone aquí permite también la +preservación de una cualidad clave del dinero físico: la privacidad en +la transacción. Usualmente se argumenta que las protecciones +criptográficas para la privacidad exigen tantos recursos computacionales +que su utilización en dispositivos móviles no es factible~\cite[véase][]{Allen}. +Si bien esto puede ser cierto en el contexto de la DLT, +donde la rastreabilidad pública de las transacciones es necesaria para +prevenir el doble gasto~\cite{Narayanan}, no es cierto para el +protocolo de firma ciega de tipo Chaum con un banco central que se +propone en el presente documento. Nuestra CBDC, basada en firmas ciegas +y arquitectura de dos niveles, garantiza una perfecta privacidad de +resistencia cuántica en las transacciones, al mismo tiempo que +proporciona protecciones sociales tales como impedir el lavado de dinero +(Anti-Money Laundering - AML) y financiar la lucha contra el terrorismo +(Counter Terrorism Financing -- CFT), protecciones que de hecho tienen +mayor fuerza que con los billetes. + +La privacidad en las transacciones es importante por tres razones. +Primero, porque protege a los usuarios frente al escrutinio y el abuso +de vigilancia gubernamental. Los programas de vigilancia masiva son +problemáticos incluso si las personas creen que no tienen nada que +esconder, simplemente por la posibilidad de error y abuso, +particularmente si los programas carecen de transparencia e +imputabilidad~\cite[véase][]{Solove}. Segundo, porque la privacidad en las +transacciones protege a los usuarios frente a la explotación de datos por parte +de los proveedores de servicios de pago. +Tercero, porque protege a los usuarios frente a la contraparte en la +transacción, descartando la posibilidad de un posterior comportamiento +oportunista, o frente a riesgos de seguridad debido a fallos o +negligencia en la protección de los datos del cliente~\cite[véase][]{Kahn2005}. + +Este documento está estructurado como sigue: en la sección 2 explicamos +la diferencia entre el dinero del banco central y otro dinero. En la +sección 3 analizamos los diseños de CBDC comunes y simplistas, antes +de proponer nuestro diseño en la sección 4. Luego comentamos +consideraciones políticas y normativas (5) y trabajos relacionados (6); +en fin, concluimos (7). + + +\section{¿Qué es el dinero del banco central?} + \label{2.-quuxe9-es-el-dinero-del-banco-central} + +El dinero es un activo que puede ser usado para comprar bienes y +servicios. Para ser considerado dinero, este activo debe ser aceptado +por otras entidades distintas del emisor. Este es el motivo por el que +los vales, por ejemplo, no se consideran dinero. El dinero genuino tiene +que ser aceptado \emph{comúnmente} como medio de intercambio. Si bien el +dinero tiene otras funciones, por ejemplo como unidad de cuenta y +depósito de valor, la característica que lo distingue es su función como +medio de intercambio. Normalmente, la unidad de cuenta (p. ej. cómo se +cotizan los precios y cómo se registran las deudas) coincide con el +medio de intercambio por razones de conveniencia. La separación puede +ocurrir, sin embargo, si el valor del medio de intercambio carece de +estabilidad en relación a los bienes y servicios +comercializados.\footnote{Esto puede ocurrir espontáneamente en un entorno +de alta-inflación, p. ej. cuando los precios se fijan en USD pero los pagos +se realizan en divisa local. Lo mismo es cierto para los pagos en Bitcoin, +donde los precios usualmente se fijan en USA u otras divisas locales debido a +la alta volatilidad de Bitcoin. Una separación también puede ocurrir por el +diseño, p. ej. en la Unidad de Fomento (UF) de Chile o la Special Drawing Right +(SDR) del fondo monetario internacional (IMF). Sin embargo, también entonces el +propósito es tener una unidad de cuenta más estable.} El dinero debe también ser +un depósito de valor para poder actuar como medio de intercambio, porque +debe preservar su poder de compra desde el momento en que se recibe +hasta el momento en que se gasta. Sin embargo, varios otros activos +sirven como depósito de valor, como por ejemplo acciones, bonos, metales +preciosos e inmuebles. Por tanto, la característica como depósito de +valor no es distintiva del dinero. + +En la economía moderna, el público usa dos tipos diferentes de dinero: +(a) dinero estatal y (b) dinero privado. El dinero estatal lo emite +típicamente un banco central, que actúa como agente del Estado. El +dinero del banco central está disponible para determinadas instituciones +financieras en forma de depósitos en el banco central (reservas) y para +el público en forma de moneda (billetes y monedas), también llamado +``efectivo''. En una economía moderna con dinero fiduciario, tal dinero +no tiene valor intrínseco. Legalmente es una obligación del banco +central, aunque no es canjeable. + +En la mayoría de los países, el dinero del banco central se define como +moneda de curso legal, lo cual significa que debe ser aceptado como pago +de una deuda monetaria, incluyendo impuestos y multas legales. Si bien +esto garantiza que el dinero del banco central tenga algún valor, el +estatus de moneda de curso legal es insuficiente para que el dinero del +banco central mantenga un valor estable. Más bien, es la política +monetaria de los bancos centrales la que mantiene el valor del dinero. +Mantener la estabilidad de los precios, es decir, un valor estable del +dinero en relación con el valor de los bienes y servicios +comercializados, es una de las principales responsabilidades de los +bancos centrales. + +En una economía moderna, la mayoría de los pagos se hacen con dinero +privado emitido por bancos comerciales. Tal dinero se compone de +depósitos a la vista que la gente tiene en los bancos comerciales. A +estos depósitos bancarios se puede acceder con cheques, tarjetas de +débito, tarjetas de crédito, u otros medios para transferir dinero. Son +una obligación del respectivo banco comercial. Una característica +fundamental de los depósitos bancarios es que los bancos comerciales +garantizan la convertibilidad, bajo demanda, en dinero del banco central +a un precio fijo, es decir, a la par. Los depositantes pueden retirar +sus fondos en efectivo o transferirlos a una tasa fija de 1:1. Los +bancos comerciales mantienen estable el valor de su dinero vinculándolo +al dinero del banco central. + +No obstante, en un sistema de reserva fraccionado, un banco comercial +-- incluso siendo solvente -- puede no contar con la liquidez necesaria +para cumplir su promesa de convertir los depósitos bancarios en dinero +del banco central (p. ej. en caso de una caída bancaria) de manera tal +que los clientes no puedan retirar su dinero. Un banco también puede +llegar a ser insolvente e ir a la bancarrota, y como resultado los +clientes pueden perder su dinero. Así, los bancos comerciales están +regulados para mitigar estos riesgos. + +Una diferencia significativa entre el dinero de un banco central y el +dinero emitido privadamente por un banco comercial es, por lo tanto, que +este último conlleva un riesgo para la contraparte. Un banco central +puede siempre cumplir con sus obligaciones usando su propio dinero no +reembolsable. El dinero del banco central es el único activo monetario +de una economía nacional sin riesgo crediticio o de liquidez. Por lo +tanto, es el activo que típicamente se prefiere para los pagos en las +infraestructuras del mercado financiero (véase p. ej. CPMI-IOSCO +\emph{Principles for Financial Market Infrastructures}, 2012). Otra +diferencia es que el dinero del banco central afianza el sistema +monetario nacional al proporcionar una referencia de valor con la que el +dinero de los bancos comerciales mantiene una convertibilidad a la par. + +Aparte de los bancos comerciales, otra entidades privadas ocasionalmente +intentan emitir dinero, las criptomonedas son solo el intento más +reciente. Pero a diferencia de los depósitos bancarios, tal dinero no es +comúnmente aceptado como medio de intercambio. Esto también sucede con +Bitcoin, la criptomoneda más aceptada. Un impedimento a su utilidad como +medio de intercambio es la alta volatilidad de su valor. Una respuesta +reciente a este problema fue la aparición de las llamadas monedas +estables. Las monedas estables generalmente intentan estabilizar su +valor en una de las dos maneras siguientes: o bien imitando a los bancos +centrales (monedas estables algorítmicas) o bien imitando a los bancos +comerciales o a los medios de inversión (monedas estables con respaldo +de activos).\footnote{Para más detalles sobre la taxonomía y descripción +de las monedas estables véase~\citet{Bullmann}.} + +Las ``monedas estables algorítmicas'' dependen de algoritmos para +regular su suministro. En otras palabras, intentan alcanzar la +estabilidad de su precio con sus propias ``políticas monetarias +algorítmicas''. Hay ejemplos de tales monedas estables (p. ej. Nubits), +pero hasta ahora ninguna ha estabilizado su valor por largo tiempo. + +Las monedas estables ``respaldadas con activos'' difieren en función del +tipo de activos que usan y de los derechos legales que adquieren los +titulares de monedas estables. Los tipos de activos que típicamente se +usan son: dinero (reservas del banco central, billetes o depósitos en +bancos comerciales), productos básicos (p. ej. oro), valores y a veces +otras criptomonedas. Cuán bien tal esquema estabilice el valor de las +monedas en relación al activo o los activos subyacentes depende de +manera crucial de los derechos legales que adquieran los titulares de +las monedas estables. Si una moneda estable es canjeable a un precio +fijo (p. ej. 1 moneda = 1 USD, o 1 moneda = 1 onza de oro), tal +estabilidad teóricamente se conseguirá.\footnote{Si también estabilice o +no el valor de las monedas estables en relación con los bienes y +servicios negociados depende de la estabilidad del valor del respectivo +activo en relación con el valor de los bienes y servicios.} Lo que el esquema +esencialmente hace es replicar a los bancos comerciales garantizando la +convertibilidad al activo subyacente a la vista. Sin embargo, a +diferencia de los depósitos bancarios, que típicamente están solo +parcialmente respaldados por las reservas monetarias del banco central, +las monedas estables generalmente están respaldadas completamente por +las reservas del activo subyacente para evitar el riesgo de liquidez, +principalmente porque carecen de beneficios públicos tales como el +soporte de seguros de depósito y prestamistas de última instancia, que +se aplican en cambio a los bancos regulados. + +Las monedas estables respaldadas con dinero se llaman también monedas +estables fiduciarias. Sin embargo, mantener el 100\% de garantía en +dinero (billetes o depósitos bancarios) no es muy rentable. En +consecuencia, los proveedores de monedas estables tienen un incentivo +para economizar su tenencia de activos y trasladarse hacia un sistema de +reserva fraccionado, tal como lo hicieron los bancos comerciales.\footnote +{La incertidumbre sobre si un moneda estable está +totalmente garantizada puede ser una de las razones por las que una +moneda estable puede negociarse por debajo de la par en el mercado +secundario~\cite[véase][]{Lyons}. Este fue +también históricamente el caso con los billetes cuando eran emitidos +por los bancos comerciales. Tales billetes solían negociarse con +diversos descuentos en el mercado secundario antes de que la emisión +de billetes fuera nacionalizada y transferida al monopolio de los +bancos centrales.} Esto implica que reducen su tenencia de activos de +bajo rendimiento al mínimo que se considere necesario para satisfacer el +requisito de convertibilidad. Añadiendo en cambio activos líquidos de +alto rendimiento tales como bonos del Estado. Esto mejora la +rentabilidad pero también incrementa el nivel de riesgo. + +Sin embargo, incluso si una moneda estable está garantizada al 100\% por +un depósito en un banco comercial, sigue expuesta a los riesgos de +crédito y liquidez del banco subyacente. Este riesgo se puede eliminar +si los depósitos se mantienen en el banco central para que la moneda +estable esté respaldada por las reservas del banco central. Tales +monedas estables han sido llamadas ``CBDC sintéticas''~\cite{Adrian}. +Es importante señalar, sin embargo, que tales +monedas estables no son dinero del banco central y por lo tanto no son +CBDC, ya que no constituyen obligaciones del banco central y, por lo +tanto, siguen expuestas al riesgo de contraparte, es decir, el riesgo de +que el emisor de la moneda estable se declare en quiebra. + +Si una moneda estable no es canjeable a un precio fijo, su estabilidad +no está garantizada por el activo subyacente. Si la moneda estable a +pesar de esto representa una participación en la propiedad del activo +subyacente, el esquema se asemeja a un fondo de inversión fijo o a un +fondo cotizado en bolsa (Exchange-Traded Fund - ETF), y se aplican los +correspondientes riesgos. El valor de la moneda dependerá del valor neto +de los activos del fondo, pero su valor real puede desviarse. Si hay +participantes autorizados que puedan crear y canjear monedas estables y +así actuar como arbitristas, como en el caso de los ETF y como estaba +previsto para Diem~\cite{Libra}, es probable que la +desviación sea mínima. + +En general, las monedas estables tiene una mayor probabilidad de llegar +a convertirse en dinero que las criptomonedas, especialmente si se +regulan adecuadamente. Sin embargo, la disponibilidad de CBDC limitaría +significativamente su utilidad. + +\section{Diseños simplistas de CBDC} \label{3.-diseuxf1os-simplistas-de-cbdc} + +Como se ha señalado, una CBDC sería una obligación del banco central. +Dos posibles diseños que se analizan en la literatura son: (a) una CBDC +basada en cuentas y (b) una CBDC basada en tokens (o basada en valor). +Estos diseños corresponden a los dos tipos existentes de dinero de un +banco central y sus correspondientes sistemas de pago (Kahn \& Roberds +2008): las reservas de un banco central (en un sistema basado en +cuentas) y billetes (en un sistema basado en tokens). Un pago se produce +si un activo monetario se transfiere de un pagador a un beneficiario. En +un sistema basado en cuentas, una transferencia se produce cobrándole a +la cuenta del pagador y transfiriendo el crédito a la cuenta del +beneficiario. En un sistema basado en tokens, la transferencia se +produce transfiriendo el valor en sí o el token, es decir, un objeto que +representa el activo monetario. El mejor ejemplo de un token es el +efectivo -- monedas o billetes. Pagar con efectivo significa entregar +una moneda o un billete. No es necesario registrar la transferencia, la +posesión del token es suficiente. Por lo tanto, las partes no están +obligadas a revelar sus identidades en ningún momento durante la +transacción, ambas pueden permanecer anónimas. De todas maneras, el +beneficiario tiene que poder verificar la autenticidad del token. Esta +es la razón por la que los bancos centrales invierten mucho en elementos +de seguridad para los billetes. + +Ha habido sugerencias de que la distinción entre los sistemas basados en +cuentas y los sistemas basados en tokens no es aplicable a las monedas +digitales~\cite{Garratt}. Nosotros tenemos una opinión diferente +porque creemos que hay una diferencia significativa. La distinción +fundamental es la información contenida en el activo. En un sistema +basado en cuentas, los activos (las cuentas) se asocian con los +historiales de las transacciones, que incluyen todas las operaciones de +crédito y débito de las cuentas. En un sistema basado en tokens, los +activos (tokens) incluyen información acerca de su valor y de la entidad +que emitió el token. Por tanto, la única posibilidad de lograr la +propiedad de privacidad de la transacción como la que se obtiene con el +dinero efectivo reside en los sistemas basados en tokens.\footnote +{Si bien el término ``Bitcoin'' sugiere el uso de tokens, Bitcoin es un +sistema basado en cuentas. La única diferencia entre un sistema +tradicional basado en cuentas y una blockchain es que las cuentas no +se guardan en una base de datos central, sino en una base de datos +descentralizada del tipo ``solo por anexión''.} + +\subsection{CBDC basada en cuentas}\label{cbdc-basada-en-cuentas} + +La forma más simple de lanzar una CBDC sería permitir que el público +tenga cuentas de depósito en el banco central. Esto implica que el banco +central seria responsable de llevar a cabo verificaciones para conocer a +sus clientes (Know-Your-Customer - KYC) y asegurar el cumplimiento del +AML y CFT. Esto incluiría no solo realizar el proceso inicial del KYC, +sino también autentificar a los clientes para las transacciones +bancarias, gestionar el fraude y lidiar con los falsos positivos y las +autenticaciones de los falsos negativos. Dada la limitada presencia +física de bancos centrales en la sociedad, y el hecho de que la +autenticación del ciudadano es algo que probablemente en la actualidad +los bancos no estén preparados para hacer a gran escala, cualquier CBDC +basada en cuentas requeriría que el banco central delegara estas +verificaciones. Todo el servicio y mantenimiento de tales cuentas podría +asignarse a proveedores externos~\cite{Bindseil}, o la legislación +podría obligar a los bancos comerciales a abrir cuentas bancarias en el +banco central para sus clientes~\cite{Berentsen}. + +Tal CBDC basada en cuentas daría potencialmente a un banco central mucha +información. Una posible preocupación podría ser que esto permitiera a +los gobiernos realizar fácilmente vigilancia masiva e imponer sanciones +a los titulares de cuentas individuales. Su naturaleza centralizada hace +que tales intervenciones sean económicas y fáciles de aplicar contra +individuos o grupos. Incluso en las democracias, hay muchos ejemplos de +abusos de vigilancia dirigidos a críticos y opositores políticos. Se +podría argumentar que los bancos centrales independientes puedan +salvaguardar tal información del escrutinio del gobierno y el abuso +político, pero esto solo abriría una nueva vía para la presión política, +amenazando la independencia del banco central. Además, la base de datos +central sería un objetivo importante para los atacantes: incluso el +acceso de solo lectura a partes de la base de datos podría crear riesgos +significativos para las personas cuyos datos fueran expuestos. + +Proveyendo cuentas bancarias al público, un banco central estaría +también en competición directa con los bancos comerciales. Esta +competición implicaría dos riesgos. Primero, podría amenazar la base de +depósitos de los bancos y, en el extremo, desintermediar el sector +bancario. Esto podría afectar de manera adversa la disponibilidad de +crédito para el sector privado y, como resultado, la actividad +económica~\cite{Agur}. La desintermediación de los bancos también podría +conducir a la centralización del proceso de asignación de crédito dentro +del banco central, lo que afectaría negativamente la productividad y el +crecimiento económico. En segundo lugar, permitir que la gente traslade +sus depósitos al refugio seguro de un banco central podría acelerar las +caídas bancarias durante crisis financieras. + +Existen sin embargo argumentos contrarios. \citet{Brunnermeier} argumentan +que la transferencia de fondos desde un +depósito hacia una cuenta de CBDC conduciría a una sustitución automática de +la financiación de depósitos por la financiación del banco central, +simplemente haciendo explicita la garantía implícita del banco central como +prestamista de última instancia. \citet{Berentsen} +sostienen que la competencia de los bancos centrales podría incluso tener un +efecto disciplinario sobre los bancos comerciales y, por lo tanto, incrementar +la estabilidad del sistema financiero, ya que los bancos comerciales tendrían +que hacer sus modelos de negocio más seguros para evitar las caídas bancarias. + +También hay propuestas para mitigar el riesgo de la desintermediación +que tienen como objetivo limitar o desincentivar el uso de CBDC como +depósito de valor. Una propuesta es limitar la cantidad de CBDC que se +puede poseer. Una segunda propuesta es aplicar una tasa de interés +ajustable a las cuentas de CBDC, de manera que la remuneración esté +siempre lo bastante por debajo de la remuneración de las cuentas de los +bancos comerciales (posiblemente incluyendo un rendimiento negativo) +para hacer que las CBDC resulten menos atractivas como depósitos de +valor~\cite{Kumhof,Bindseil}. Además, para disuadir las +caídas bancarias, \citet{Kumhof} sugieren que las CBDC no +deberían ser emitidas contra depósitos bancarios, sino solo contra +valores tales como bonos del Estado. En general, una CBDC basada en +cuentas requeriría un análisis más profundo de estas cuestiones. + + +\subsection{CBDC basada en tokens y dependiente del hardware} +\label{cbdc-basada-en-tokens-y-dependiente-del-hardware} + +Un banco central podría también emitir tokens electrónicos en lugar de +cuentas. Técnicamente esto requiere de un sistema para asegurar que los tokens +electrónicos no se puedan copiar fácilmente. Las funciones físicamente +imposibles de clonar~\cite[véase][]{Katzenbeisser} y las zonas seguras en +el hardware~\cite[véase][]{Alves,Pinto} son dos tecnologías potenciales para +la prevención de la copia digital. Las funciones físicas imposibles de clonar, +sin embargo, no se pueden intercambiar a través de Internet (eliminando así el +uso principal de las CBDC), y anteriores funciones de seguridad en el hardware +para la prevención de copias se han visto comprometidas +repetidamente~\cite[véase p. ej.][]{Wojtczuk,Johnston,Lapid}. + +Una ventaja fundamental de las CBDC basadas en tokens sobre las basadas +en cuentas del banco central es que los sistemas basados en tokens +funcionarían sin conexión, es decir, los usuarios podrían intercambiar +tokens (peer-to-peer) sin involucrar al banco central, lo que protegería +la privacidad y la libertad de las personas. Sin embargo, la +desintermediación que se produce cuando los usuarios pueden intercambiar +tokens electrónicos sin los bancos como intermediarios que realizan los +controles KYC, AML y CFT dificultarían la limitación de los abusos por +parte de delincuentes. + +Las tarjetas SIM son actualmente las candidatas más extensivamente +disponibles para un sistema de pago seguro basado en hardware, pero +estas también conllevan riesgos. La experiencia~\cite[véase p. ej.][]{Soukup,Garcia,Kasper,CCC} sugiere +que cualquier dispositivo económicamente producible que almacene tokens +con un valor monetario en posesión de una persona, y que permita +transacciones sin conexión -- y por tanto el robo de la información que +contiene -- será el objetivo de ataques de falsificación exitosos tan +pronto como el valor económico del ataque fuera los suficientemente +elevado. Tales ataques incluyen usuarios que atacan su propio +hardware~\cite[véase también]{Allen}. Los sistemas de pago con tarjeta que +se han desplegado previamente dependen de la resistencia a la +manipulación en combinación con la detección del fraude para limitar el +impacto de una situación de peligro. Sin embargo, la detección del +fraude requiere la habilidad de identificar a los pagadores y seguir la +pista de los clientes, lo cual no es compatible con la privacidad de la +transacción. + +\section{Diseño de CBDC basado en tokens para salvaguardar la +privacidad} +\label{4.-diseuxf1o-de-cbdc-basado-en-tokens-para-salvaguardar-la-privacidad} + +La CBDC que se propone aquí es de tipo ``solo software'', simplemente una +aplicación para teléfonos inteligentes que no requiere ningún hardware +adicional por parte de los usuarios. La CBDC se basa en eCash y GNU +Taler. Taler es parte del Proyecto GNU, cuyo fundador, Richard Stallman, acuñó +el término \emph{Software Libre}, actualmente denominado \emph{Software Libre +y de Código Abierto} (Free/Libre Open Source Software -- FLOSS).\footnote{Para +más información sobre GNU, véase \url{https://www.gnu.org} y +\citet{Stallman}. GNU Taler se publica gratuitamente bajo la Licencia Pública +General Affero del Proyecto GNU. Otros programas del Proyecto GNU populares +entre los economistas son «R» y ``GNU Regression, Econometrics and Time-series +Library'' (GRETL). Un análisis de los beneficios del FLOSS en comparación con +el software privativo en el campo de la investigación puede consultarse +en~\citet{Baiocchi}, \citet{Yalta2008} y \citet{Yalta2010}. Sobre el +licenciamiento de código abierto véase \citet{Lerner}.} Un programa se +considera ``Software Libre'' si la licencia otorga a los usuarios cuatro +libertades esenciales: la libertad de ejecutar el programa como deseen, la +libertad de estudiar el programa y modificarlo, la libertad de redistribuir +copias del programa y la libertad de distribuir copias de las versiones +modificadas del programa. El software libre no tiene por qué ser no +comercial: proporcionar soporte técnico para software es un modelo de negocio +estándar para el FLOSS. + +Dado el gran número de partes interesadas involucradas en una CBDC al +por menor (el banco central, el sector financiero, comerciantes y +clientes) y la importancia crítica de la infraestructura, una CBDC al +por menor debe basarse en el FLOSS. Imponer una solución propietaria que +requiera la dependencia de un proveedor en particular sería +probablemente un obstáculo para la adopción desde el principio. Con el +FLOSS, todas las partes interesadas tienen acceso a cada detalle de la +solución y el derecho de adaptar el software a sus necesidades. Esto +conduce a una integración más fácil y una mejor interoperabilidad y +competencia entre proveedores.\footnote{Sin embargo, puede haber otros +roles para hardware privado. Por ejemplo, proteger los depósitos de +claves y ciertas funciones de auditoría, en la medida en que tal +seguridad pueda demostrarse solo como aditiva, puede ser un área donde +el hardware dedicado evaluado por solo un número limitado de expertos +podría tener ventajas.} Además, permite que el banco central cumpla +con los requisitos de transparencia y responsabilidad. Los beneficios +del FLOSS para la seguridad son también ampliamente reconocidos. La +disponibilidad del código fuente y el derecho a modificarlo facilitan la +detección de fallos y su rápida solución.\footnote{Por ejemplo, un +boletín de seguridad cibernética emitido por la Agencia de Seguridad +Nacional de EE. UU. en abril de 2020 insta a los usuarios a priorizar +el software de código abierto en la selección y el uso de servicios de +colaboración para la comunicación por Internet: ``El desarrollo de +código abierto puede proporcionar confiabilidad de que el código está +escrito para asegurar las mejores prácticas de programación y no es +probable que introduzca vulnerabilidades o debilidades que puedan +poner en riesgo a los usuarios y los datos '' (U/OO/134598-20).} + +En esta nuestra arquitectura que proponemos todas las interacciones del +consumidor y el comerciante son con bancos comerciales. Sin embargo, la +creación de dinero y la base de datos las proporcionan exclusivamente el +banco central. Los bancos comerciales autentican a los clientes cuando +retiran CBDC y a los comerciantes/beneficiarios cuando reciben CBDC, +pero cuando gastan CBDC, los clientes/pagadores solo tienen que +autorizar sus transacciones y no necesitan identificarse. Esto hace que +los pagos resulten más baratos, fáciles y rápidos, y evita una fácil +interferencia con la privacidad~\cite{Dold}. Además, autenticar a los +clientes cuando retiran CBDC y a los comerciantes/beneficiarios cuando +reciben CBDC garantiza el cumplimiento del KYC, AML y CFT. + +La CBDC que se propone en el presente documento es un auténtico +instrumento digital al portador porque cuando el usuario retira una suma +de dinero en forma de número, el número es ``cegado'' u ocultado por el +teléfono inteligente con un cifrado especial. En el sistema real, una +moneda es un par de claves pública / privada, y la clave privada solo la +conoce el propietario de la moneda.\footnote{En Bitcoin, que es un +sistema basado en cuentas, el par de claves es una cuenta, siendo la +clave pública la ``dirección'' de la cuenta y por tanto un tipo de +``identidad'', incluso si se trata de un pseudónimo.} La moneda deriva +su valor financiero de la firma del banco central en la clave pública de +la moneda. El banco central hace la firma con su clave privada y dispone +de múltiples pares de claves de denominación para la firma ciega de +monedas de diferentes valores. Un comerciante puede utilizar la +correspondiente ``clave pública'' del banco central para verificar la +firma. Sin embargo, para asegurarse de que la moneda no haya sido +copiada y ya canjeada por otro beneficiario (es decir, que no se haya +``gastado dos veces''), el comerciante debe depositar la moneda para que +el banco central pueda comparar la moneda con un archivo de monedas +canjeadas. Debido a que ni el banco comercial ni el banco central ven el +número de la moneda durante el retiro, más tarde, cuando el comerciante +deposita la moneda, se desconoce qué usuario la retiró. El cegamiento y +la privacidad resultante son los que hacen de este tipo de CBDC un +verdadero instrumento digital al portador. + +En el análisis que sigue proporcionamos una introducción de alto nivel a +la tecnología y demostramos cómo se puede integrar con el sistema +bancario existente para crear una CBDC. \citet{Dold} describe detalles +adicionales. + +\subsection{Componentes fundamentales}\label{componentes-fundamentales} + +A continuación describimos los principales componentes del protocolo, +incluido el trasfondo matemático para una posible instanciación de las +primitivas criptográficas utilizadas, para ilustrar cómo podría +funcionar una implementación. Observamos que existen diseños matemáticos +alternativos y equivalentes para cada componente, y simplemente +presentamos los diseños seguros más sencillos de los que tenemos +conocimiento. + +\emph{Firmas digitales.} La idea básica de las firmas digitales en un esquema +de firma con clave pública es que el propietario de una clave privada es el +único que puede firmar un mensaje, mientras que la clave pública permite a +cualquiera verificar la validez de la firma.\footnote{La criptografía de clave +pública fue introducida por~\citet{Diffie}, y la primera implementación de +firmas digitales fue introducida por~\citet{Rivest}.} El resultado de la +función de verificación es la declaración binaria ``verdadero'' o ``falso''. Si el +mensaje está firmado con la clave privada que pertenece a la clave pública de +verificación, el resultado es verdadero, de lo contrario es falso. En nuestra +propuesta, el mensaje es una ``moneda'' o ``billete'' con un número de serie, y la +firma del banco central confirma su validez. Si bien GNU Taler usa por defecto +firmas EdDSA modernas~\cite[véase][]{Bernstein2012}, presentamos un esquema de +firma criptográfica simple basado en el bien estudiado sistema criptográfico +RSA~\cite{Rivest}.\footnote{Para un análisis de la larga historia del +criptosistema RSA y un estudio de los ataques al criptosistema RSA, +consulte~\citet{Boneh}.} Sin embargo, en principio se puede utilizar cualquier +esquema de firma criptográfica (DSA, ECDSA, EdDSA, RSA, etc.). + +Para generar las claves RSA, el firmante elige primero dos grandes e +independientes números primos $p$ y $q$ y calcula $n = \emph{pq}$ +así como la función totient de Euler +$\phi(n) = (p - 1)(q - 1)$. +Entonces, cualquier $e$ con $1 < e < \phi(n)$ y +$\gcd(e, \phi(n)) = 1$ se puede usar para +definir una clave pública $(e,n)$. La condición de que el +máximo común divisor (greatest common divisor - $\gcd$) de $e$ y +$\phi(n)$ tiene que ser 1 (p. ej., que deben ser +relativamente primos) asegura que la inversa de +$e \mod \phi(n)$ existe. +Esta inversa es la +correspondiente clave privada $d$. Dado $\phi(n)$, la clave +privada $d$ se puede calcular usando el algoritmo extendido +Euclídeo de modo que +$d \cdot e \equiv 1 \mod \phi(n)$. + +Dada la clave privada $d$ y la clave pública $(e, n)$, una firma simple RSA +$s$ sobre un mensaje $m$ es +$s \equiv m^{d} \mod n$. +Para verificar la firma, se calcula +$m' \equiv s^{e} \mod n$. +Si $m'$ y $m$ coinciden, la firma es válida, lo que prueba que el +mensaje fue firmado con la clave privada que pertenece a la clave +publica de verificación (autenticación de mensaje) y que ese mensaje no +ha sido cambiado en tránsito (integridad de mensaje). En la práctica, +las firmas se colocan sobre lo hashes de los mensajes en vez de los +propios mensajes. Las funciones hash calculan el resumen de los +mensajes, que son identificadores únicos y cortos para los mensajes. +Firmar un hash corto es mucho más rápido que firmar un mensaje largo, y +la mayoría de los algoritmos de firma solo funcionan con entradas +relativamente cortas.\footnote{En el caso del criptosistema RSA el +límite de la longitud es $\log_{2}n$ bits.} + +\emph{Firmas ciegas.} Usamos firmas ciegas, introducidas +por~\citet{Chaum1983}, para proteger la privacidad de los compradores. Una +firma ciega se usa para crear una firma criptográfica para un mensaje sin que +el firmante conozca el contenido del mensaje que se firma. En nuestra +propuesta, esto evita que los bancos comerciales y el banco central puedan +rastrear las compras identificando a los compradores. Nuestra propuesta +funciona en principio con cualquier esquema de firma ciega, pero la mejor +solución es la variante basada en RSA descrita por~\citet{Chaum1983}. + +El cegamiento lo realizan los clientes, quienes ciegan sus monedas antes +de transmitirlas al banco central para ser firmadas. Los clientes por +tanto no necesitan confiar al banco central la protección de su +privacidad. Además, el cegamiento RSA proveería de protección de la +privacidad incluso contra ataques informáticos cuánticos. El banco +central, por su parte, establece múltiples denominaciones de pares de +claves disponibles para realizar la firma ciega de monedas con +diferentes valores, y publica/provee las correspondientes claves +públicas $(e, n)$ para estos valores. + +Sea $f$ el valor hash de una moneda y por tanto un identificador único +para esta moneda. El cliente que retira la moneda primero genera una +factor ciego aleatorio $b$ y calcula +$f' \equiv fb^{e} \mod n$ +con la clave pública del banco central para ese valor. +La moneda cegada $f'$ se transmite luego +al banco central para ser firmada. El banco central firma $f'$ con su +clave privada $d$ calculando la firma ciega +$s' \equiv \left(f' \right)^{d} \mod n$ y devuelve +$s'$ al cliente. +El cliente puede entonces des-cegar la firma calculando +$s \equiv s'b^{- 1} \mod n$. +Esto funciona porque +$\left( f' \right)^d = f^db^{ed} = f^db$ y, así, +multiplicar $s'$ con $b^{- 1}$ produce $f^d$, que es una firma RSA +válida sobre $f$ como antes: +$s^e \equiv f^{de} \equiv f \mod n$. + +En la propuesta original de Chaum, las monedas eran solo tokens. Sin +embargo, nosotros queremos que los consumidores puedan realizar +contratos usando firmas digitales. Para lograrlo, cuando una billetera +digital retira una moneda, primero crea una clave privada aleatoria +$c$ y calcula la correspondiente clave publica $C$ de esta moneda +para crear firmas digitales con esquemas de firma criptográfica +regulares (como DSA, ECDSA, EdDSA y RSA). Entonces, se deriva $f$ +usando una hash criptográfica de la clave pública $C$, que luego es +firmada en modalidad ciega por el banco central (usando un factor +aleatorio ciego actualizado para cada moneda). Ahora el cliente puede +usar $c$ para firmar compras electrónicamente, gastando así la moneda. + +Como se ha señalado anteriormente, el banco central establecería pares +de claves para los diferentes valores de las monedas y publicaría las +claves públicas que los clientes podrían usar para retirar dinero. Estas +claves de denominación, y por tanto las monedas, tendrían una fecha de +vencimiento antes de la cual deberían ser gastadas o intercambiadas por +nuevas monedas. A los clientes se les daría una cierta cantidad de +tiempo durante el cual podrían intercambiar sus monedas. Un proceso +similar existe para los billetes físicos, donde las series de los +billetes se renuevan regularmente para que los billetes vayan equipados +con las últimas características de seguridad, excepto que los billetes +generalmente permanecen en circulación durante décadas en vez de por +unos pocos meses o años.\footnote{En Suiza, por ejemplo, el Swiss +National Bank empezó la eliminación paulatina la serie octava de +billetes en abril de 2016. Estos billetes fueron puestos en +circulación al final de los 90. A partir del día 1 de enero de 2020, +sin embargo, todos los billetes que empiezan por la serie sexta +emitidos en 1976, así como cualquier futura serie, permanecen válidas +y se pueden cambiar por billetes actuales de forma indefinida.} + +Desde un punto de vista técnico, una fecha de vencimiento tiene dos +ventajas. Primero, mejora la eficiencia del sistema porque el banco +central puede descartar entradas vencidas y no tiene que almacenar y +buscar una lista siempre creciente de monedas (gastadas) para detectar +el doble gasto. Segundo, reduce los riesgos de seguridad porque el banco +central no tiene que preocuparse sobre ataques contra sus claves +($d$) de denominación (privadas) vencidas. Además , incluso si una +clave privada se ve comprometida, el tiempo durante el cual el atacante +puede usar la clave es limitado. Además cobrar una comisión por el +cambio permitiría al banco central implementar tasas de interés +negativas, si se considera necesario. El banco central podría también +imponer un límite de conversión por cliente en consideración del AML y +el CFT (límites de ``efectivo'') o por razones de estabilidad +financiera (para prevenir el acaparamiento o las caídas bancarias), si +así se deseara. + +\emph{Protocolo de intercambio de claves.} GNU Taler utiliza un +protocolo de intercambio de claves de manera inusual para proporcionar +un vínculo entre la moneda original y el cambio (también llamado +``vuelto'') entregado por esa moneda original. Esto asegura que siempre +se pueda entregar el cambio sin comprometer la transparencia de los +ingresos o la privacidad del consumidor. El mismo mecanismo se puede +usar también para realizar devoluciones anónimas a los clientes. El +protocolo también maneja fallos en la red y en los componentes, +asegurando que los pagos se hayan realizado definitivamente o se hayan +cancelado definitivamente y que todas las partes tengan una prueba +criptográfica del resultado. Esto es aproximadamente equivalente a los +intercambios atómicos de los protocolos \emph{interledger} o al +intercambio justo en sistemas tradicionales de efectivo electrónico. + +La construcción matemática más común para un protocolo de intercambio de +claves es la construcción Diffie-Hellman~\cite{Diffie}. Esta +permite que dos partes puedan derivar una clave secreta compartida. Para +hacerlo, comparten dos parámetros del dominio $p$ y $g$, que +pueden ser públicos, donde $p$ es un número primo grande y $g$ +es una raíz primitiva módulo $p$.\footnote{Un entero $g$ es una raíz +primitiva módulo $p$ si para cada entero $a$ coprimo a $p$ hay +algún entero $k$ para el cual +$g^k \equiv a \mod p$. +En la práctica, $g$ debería ser tal raíz primitiva $p-1$, que se +llama también generador, para prevenir ataques de subgrupo tales como ataques +Pohlig-Hellman~\cite[véase][]{Lim}.} Ahora, las dos partes eligen sus claves +privadas \emph{a} y \emph{b}, que son dos números enteros grandes. Con estas claves +privadas y los parámetros del dominio, generan sus respectivas claves +públicas $A \equiv g^{a} \mod p$ y $B \equiv g^{b} \mod p$. +Cada una de las partes ahora puede usar su propia clave privada y la +clave pública de la otra parte para calcular la clave secreta compartida +$k \equiv \left( g^b \right)^{a} \equiv \left( g^{a} \right)^{b} \equiv g^{\text{ab}} \mod p$. +\footnote{El mismo mecanismo también se podría usar para garantizar que +las monedas no se transfieran a un tercero durante el retiro. Para +lograr esto, los consumidores tendrían que salvaguardar una clave de +identidad a largo plazo. Luego, el proceso de retiro podría usar la +misma construcción que usa GNU Taler para obtener el cambio, excepto +que se usaría la clave de identidad a largo plazo de un cliente en +lugar de la moneda original cuando se retira de la cuenta bancaria del +cliente. Sin embargo, si el cliente no proteje la clave de identidad a +largo plazo las garantías de privacidad podrían quedar anuladas con +consecuente riesgo de robo de todas las monedas restantes. Dado el +riesgo limitado en las transferencias a terceros al retirar monedas, +no está claro si esta mitigación sería una buena compensación.} + +Para obtener el cambio (también llamado ``vuelto''), el cliente empieza +con la clave privada de la moneda $c$. gastada parcialmente. Sea $C$ la +correspondiente clave pública, p. ej. +$C = g^{c} \mod p$. +Cuando la moneda se gastó parcialmente, el banco central grabó en su base de +datos la transacción en la que se incluye a $C$. Para simplificar, daremos +por sentado que existe una denominación que coincide exactamente con el +valor residual. De no ser así, se puede simplemente ejecutar +repetidamente el protocolo de cambio hasta obtener todo el cambio +necesario. Sea $(e,n)$ la clave de denominación para el +cambio que se tiene que emitir. + +Para obtener el cambio, el cliente primero crea $\kappa$ claves de +transferencia privada $t_{i}$ para +$i \in \left\{ 1,\ldots,\kappa \right\}$ y calcula las +correspondientes claves públicas $T_{i}$. Estas claves de +transferencia $\kappa$ son simplemente pares de claves pública-privada +que permiten al cliente ejecutar localmente el protocolo de intercambio +de claves -- con el cliente jugando en ambos lados -- $\kappa$ veces +entre $c$ y cada $t_{i}$. Si se usa Diffie-Hellman para el protocolo de +intercambio de claves, tendremos +$T_{i} \equiv g^{t_{i}} \mod p$. + +El resultado son tres secretos de transferencia +$K_{i} \equiv \emph{KX}(c,t_{i})$. El protocolo de +intercambio de claves se puede usar de diferentes maneras para llegar al +mismo valor +$K_{i} \equiv \emph{KX}(C,t_{i}) = \emph{KX}(c,T_{i})$. +Dada $K_{i}$, el cliente usa una función criptográfica hash $H$ para +derivar valores +$(b_{i},c_{i}) \equiv H(K_{i})$, donde +$b_{i}$ es un factor ciego válido para la clave de denominación +$(e,n)$ y $c_{i}$ es una clave privada para obtener la +moneda recién creada como cambio. $c_{i}$ debe ser adecuada tanto para +crear firmas criptográficas como para su futuro uso con el protocolo de +intercambio de claves (como $c$, para obtener cambio a partir del cambio). +Sea $C_{i}$ la clave pública correspondiente a $c_{i}$. El cliente +solicita entonces al banco central que cree una firma ciega sobre +$C_{i}$ para $i \in \{ 1,\ldots,\kappa\}$.\footnote{Si se usara el +criptosistema RSA para firmas ciegas, usaríamos +$f \equiv \emph{FDH}_{n}(C_{i})$, donde +$\emph{FDH}_{n}()$ es el hash de dominio completo sobre +el dominio $n$.} En esta petición, el cliente también se compromete a +las claves públicas $T_{i}$. La petición es autorizada usando una +firma hecha con la clave privada $c$. + +En lugar de devolver directamente la firma ciega, el banco central +primero desafía al cliente para comprobar que el cliente haya usado +correctamente la construcción mencionada anteriormente proveyendo +$\gamma \in \left\{ 1,\ldots,\kappa \right\}$. El cliente debe +entonces revelar al banco central la $t_{i}$ para $i \neq \gamma$ . +El banco central puede entonces calcular +$K_{i} \equiv \emph{KX}(C,t_{i})$ y derivar los valores +de $(b_{i},c_{i})$. Si para todas las $i \neq \gamma$ +la $t_{i}$ provista demuestra que el cliente usó la construcción +correctamente, el banco central devuelve la firma ciega sobre +$C_{\gamma}$. Si el cliente no provee una prueba correcta, se pierde +el valor residual de la moneda original. Esto penaliza efectivamente a +quienes intentan evadir la transparencia de sus ingresos con una tasa de +impuestos estimada de $1 - \frac{1}{\kappa}$. + +Para evitar que un cliente conspire con un comerciante que está tratando +de ocultar sus ingresos, el banco central permite que cualquiera que +conozca $C$ pueda obtener, en cualquier momento, los valores de +$T_{\gamma}$ y las correspondientes firmas ciegas de todas las monedas +vinculadas a la moneda original $C$. Esto permite que el propietario de la +moneda original -- que conoce $c$ -- calcule +$K_{\gamma} \equiv \emph{KX}( c,T_{\gamma})$ y, a partir de +allí, pueda derivar $(b_{i},c_{i})$ y descifrar la firma +ciega. En consecuencia, un comerciante que oculte sus ingresos de este +modo formaría básicamente una unión económica limitada con el cliente en +lugar de obtener un control exclusivo. + +\hypertarget{arquitectura-del-sistema}{% +\subsection{Arquitectura del sistema}\label{arquitectura-del-sistema}} + +El objetivo principal de nuestra arquitectura es asegurar que los bancos +centrales no tengan que interactuar directamente con los clientes o +guardar ninguna información sobre ellos, sino simplemente mantener una +lista de las monedas que se gastan. La autenticación se delega a los +bancos comerciales, que tienen ya la infraestructura necesaria. Los +protocolos de retiro y depósito llegan al banco central a través del +banco comercial como intermediario. Desde el punto de vista del cliente, +el proceso es análogo a retirar dinero efectivo desde un cajero +automático. La transacción entre el banco comercial del usuario y el +banco central tiene lugar en segundo plano. El procedimiento para +retirar CBDC sería como se muestra en la Figura~\ref{fig:fig1}. + +\begin{figure}[h!] + \includegraphics[width=\textwidth]{retirada.pdf} + \caption{Retiro de CBDC} + \label{fig:fig1} +\end{figure} + +Un cliente (1) proporciona autenticación a su banco comercial usando la +autenticación respectiva del banco comercial y los procedimientos de +autorización. A continuación, el teléfono (u ordenador) del cliente +obtiene la clave de denominación $(e, n)$ provista por el banco central +para ese valor; calcula entonces (2) un par de claves para una moneda, +con la clave privada c y la clave pública $C$, y elige un factor de cegado +$b$. A la clave pública de la moneda se le aplica una función hash +($\to$ $f$) y es cegada ($\to$ $f'$). A continuación, (3) el teléfono +del cliente envía $f'$ junto con una autorización para retirar la +moneda y debitar de la cuenta del cliente en el banco comercial a través +de un canal seguro establecido. El banco comercial entonces (4) debita +la cantidad en la cuenta de depósito del cliente, (5) autoriza +digitalmente la petición con la propia firma digital de su sucursal +bancaria y reenvía la petición y la moneda cegada al banco central para +su firma. El banco central (6) deduce el valor de la moneda en la cuenta +del banco comercial, firma la moneda de forma ciega con la clave privada +del banco central para el valor respectivo, y (7) devuelve la firma +ciega $s'$ al banco comercial. (8) reenvía la firma ciega $s'$ +a la billetera electrónica del cliente. Finalmente, el teléfono del +cliente (9) usa $b$ para descifrar la firma ($\to$ $f$) y almacena la +moneda recién acuñada $(c, s)$. + +Cuando se gastan CBDC, el proceso es análogo a pagar al vendedor en +efectivo. Sin embargo, para asegurar el acuerdo, el vendedor debe +depositar las monedas. El procedimiento para gastar CBDC se indica en la +Figura~\ref{fig:fig2}. + +Un cliente y un vendedor negocian un contrato comercial, y (1) el +cliente usa una moneda electrónica para firmar el contrato o factura de +venta con la clave privada $c$ de la moneda y transmite la firma al +vendedor. La firma de una moneda en un contrato con una moneda válida es +una instrucción del cliente para pagar al vendedor que es identificado +por la cuenta bancaria en el contrato. Los clientes pueden firmar +contratos con múltiples monedas en caso de que una sola moneda fuera +insuficiente para pagar la cantidad total. El vendedor (2) valida +entonces la firma de la moneda sobre el contrato y la firma s del banco +central sobre $f$ que corresponde a la $C$ de la moneda con las +respectivas claves públicas y reenvía la moneda firmada (junto con la +información de la cuenta del vendedor) al banco comercial del vendedor. +El banco comercial del vendedor (3) confirma que el vendedor es uno de +sus clientes y envía la moneda firmada al banco central. El banco +central (4) verifica las firmas y comprueba su base de datos para +asegurar que la moneda no haya sido previamente gastada. Si todo está en +orden, (5) el banco central añade la moneda a la lista de monedas +gastadas, acredita la cuenta del banco comercial en el banco central y +(6) envía la confirmación al banco comercial a tal efecto. A +continuación, (7) el banco comercial acredita la cuenta del vendedor e +(8) informa al vendedor. El vendedor (9) entrega el producto o servicio +al cliente. Todo el proceso dura solo unos pocos milisegundos. + +\begin{figure}[h!] + \includegraphics[width=\textwidth]{deposito.pdf} + \caption{Gastar y depositar CBDC} + \label{fig:fig2} +\end{figure} + +\hypertarget{consideraciones-acerca-de-la-seguridad}{% +\subsection{Consideraciones acerca de la Seguridad} +\label{consideraciones-acerca-de-la-seguridad}} + +Nuestra propuesta requiere que el banco central opere un servicio en +línea y una base de datos de alta disponibilidad. Debido a que los +usuarios pueden copiar las monedas electrónicas, solo los controles en +línea pueden prevenir eficientemente el doble gasto. Si bien existen +soluciones teóricas para identificar de manera retroactiva a usuarios +que se dediquen al doble gasto~\cite[véase][]{Chaum1990}, tales +soluciones crean un riesgo económico tanto para los usuarios como para +el banco central, debido al retraso en la identificación de +transacciones fraudulentas. La detección del doble gasto en línea +elimina este riesgo, pero a su vez implica que las transacciones serán +imposibles de realizar si la conexión con el banco central no estará +disponible. + +El banco central también tendrá que proteger la confidencialidad de las +claves privadas que utiliza para firmar las monedas y otros mensajes del +protocolo. De manera que si las claves de las firmas del banco central +se vieran en algún momento comprometidas, como por ejemplo por una +computadora cuántica, un ataque físico en su centro de datos, o quizás +por algún nuevo algoritmo imprevisto, los usuarios puedan de forma +segura, y sin comprometer su privacidad, ser reembolsados con todas las +monedas que no han gastado. El banco central anunciaría la revocación de +clave mediante la API (Application Programming Interface), que sería +detectada por las billeteras e iniciarían el siguiente protocolo de +actualización: el usuario revela al banco central la clave pública +$C$ de la moneda, la firma $s$ del banco central, y el factor +ciego $b$, posibilitando así que el banco central verifique el +retiro legítimo del usuario y devuelva el valor de la moneda no gastada. +Para detectar un posible compromiso de esta clave, el banco central +puede monitorear la base de datos en busca de casos de depósitos que +superen los retiros. + +\subsection{Escalabilidad y Costes}\label{escalabilidad-y-costes} + +El esquema que proponemos sería tan eficiente y rentable como los +modernos sistemas RTGS que utilizan actualmente los bancos centrales. + +La escalabilidad se refiere al costo de aumentar la capacidad de +procesamiento para que se pueda procesar un número cada vez mayor de +transacciones en un tiempo adecuado para la finalidad. El costo global +del sistema puede ser bajo, ya que la CBDC que se propone aquí se basa +en software solamente. Las monedas gastadas deben guardarse hasta que +caduque el par de claves de denominación que se usó para firmar las +monedas; por ejemplo, mediante un calendario anual renovable, que +mantiene limitado el tamaño de la base de datos. La cantidad de potencia +de procesamiento adicional y ancho de banda necesarios aumenta en la +misma cantidad por cada transacción, gasto o depósito adicional, porque +las transacciones son esencialmente independientes una de la otra. Esta +potencia adicional se logra simplemente añadiendo más hardware, +comúnmente llamado partición o fragmentación. Con el llamado hash +consistente, las adiciones de hardware no tienen por qué ser +disruptivas. Se puede utilizar cualquier tecnología de base de datos +subyacente. + +Más concretamente, la lógica del front-end en el banco central solo tiene que +realizar unas cuantas operaciones de firma, y un único procesador puede hacer +miles de operaciones por segundo~\cite[véase][]{Bernstein2020}. Si un solo +sistema es insuficiente, es fácil desplegar servidores front-end adicionales y +solicitar a los varios bancos comerciales que balanceen sus peticiones en la +granja de servidores o que utilicen un balanceador de carga para distribuir +las peticiones dentro de la infraestructura del banco central. + +Los servidores front-end deben comunicarse con una base de datos para +hacer transacciones y prevenir el doble gasto. Un solo servidor moderno +para la base de datos debería ser suficiente para manejar de manera +fiable decenas de miles de estas operaciones por segundo. Las +operaciones se reparten fácilmente entre varios servidores de bases de +datos simplemente asignando a cada servidor un rango de valores de los +que es responsable. Este diseño asegura que las transacciones +individuales nunca crucen fragmentos. Así, se espera que también los +sistemas de back-end escalen linealmente con los recursos +computacionales disponibles, de nuevo partiendo de una línea de base +alta para un solo sistema. + +Los front-end también deben comunicarse con los back-end mediante una +interconexión. Las interconexiones puede soportar grandes cantidades de +transacciones por segundo. El tamaño de una transacción individual suele +ser de 1-10 kilobytes aproximadamente. Así, las interconexiones de un +centro de datos moderno, con velocidades de conmutación de 400 Gbit/s, +pueden soportar millones de transacciones por segundo. + +En fin, el costo total del sistema es bajo. Es probable que el +almacenamiento seguro de 1 a 10 kilobytes por transacción durante muchos +años sea el costo predominante del sistema. Utilizando los precios de +Amazon Web Services, experimentamos con un prototipo anterior de GNU +Taler y descubrimos que el costo del sistema (almacenamiento, ancho de +banda y computación) a escala estaría por debajo de USD 0,0001 por +transacción (para obtener detalles sobre los datos, consulte~\citet{Dold}). + + +\section{Consideraciones normativas y políticas} + \label{5.-consideraciones-normativas-y-poluxedticas} + +En el esquema propuesto, los bancos centrales no conocen la identidad de +los consumidores o comerciantes ni los montos totales de las +transacciones. Los bancos centrales solo ven cuándo se lanzan las +monedas electrónicas y cuándo se canjean. Los bancos comerciales siguen +proporcionando autenticación crucial de clientes y comerciantes y, en +particular, siguen siendo los guardianes de la información del KYC. Los +bancos comerciales observan cuándo los comerciantes reciben fondos y +pueden limitar la cantidad de CBDC por transacción que un comerciante +individual puede recibir, si así se requiere. + +Además, las transacciones están asociadas con los contratos pertinentes +de los clientes. La transparencia de ingresos que se obtiene permite que +el sistema cumpla con los requisitos del AML y CFT. Si se detectan +patrones inusuales de ingresos comerciales, el banco comercial, las +autoridades fiscales o las fuerzas del orden pueden obtener e +inspeccionar los contratos comerciales subyacentes a los pagos para +determinar si la actividad sospechosa es ilegal. La transparencia de los +ingresos que se obtiene es también una fuerte medida contra la evasión +fiscal porque los comerciantes no pueden declarar menos ingresos o +evadir los impuestos sobre las ventas. En general, el sistema implementa +privacidad por diseño y privacidad por omisión (como lo exige, por +ejemplo, el Reglamento General de Protección de Datos de la Unión +Europea). Los comerciantes no infieren inherentemente la identidad de +sus clientes, los bancos solo tienen la información necesaria sobre las +actividades de sus propios clientes y los bancos centrales están +felizmente divorciados del conocimiento detallado de las actividades de +los ciudadanos. + +Por razones reglamentarias, en algunos países existen límites para los +retiros y pagos en efectivo. Dichas restricciones también podrían +implementarse para la CBDC en el diseño propuesto. Por ejemplo, se +podría limitar la cantidad que los consumidores puedan retirar por día, +o limitar la cantidad total de CBDC que los bancos comerciales puedan +convertir. + +Un problema potencial de estabilidad financiera que a menudo se plantea +con las CBDC al por menor es la desintermediación del sector bancario. +En particular, la venta de CBDC al por menor podría facilitar el +acaparamiento de grandes cantidades de dinero del banco central. Esto +podría afectar negativamente a la financiación de depósitos de los +bancos porque el público tendría menos dinero en forma de depósitos +bancarios. Para los países cuyas monedas sirven como monedas de refugio +seguro, podría conducir a un aumento de las entradas de capital durante +períodos de riesgo global, lo que resultaría en presiones adicionales en +la apreciación del tipo de cambio. + +Si bien esto podría representar una preocupación seria en el caso de una +CBDC basada en cuentas, la preocupación sería menor con una CBDC basada +en tokens. En primer lugar, acumular una CBDC basada en tokens conlleva +riesgos de robo o pérdida similares a los de acumular efectivo. Tener +unos cientos de dólares en un teléfono inteligente es probablemente un +riesgo aceptable para muchos, pero tener una cantidad muy grande es +probablemente un riesgo menos aceptable. Por tanto, no esperaríamos un +acaparamiento significativamente mayor que en el caso del efectivo +físico. + +Sin embargo, si el acaparamiento o la conversión masiva a CBDC de dinero +proveniente de depósitos bancarios se convirtieran en un problema, los bancos +centrales tendrían varias opciones. Como se señaló, en el diseño propuesto los +bancos centrales configuran una fecha de vencimiento para todas las claves de +firma, lo que implica que en una fecha establecida las monedas firmadas con +esas claves dejan de ser válidas. Cuando las claves de denominación caducan y +los clientes tienen que cambiar monedas firmadas con claves de denominación +antiguas por monedas nuevas, el regulador podría fácilmente imponer un límite +de conversión por cliente para hacer cumplir un límite estricto a la cantidad +de CBDC que cualquier individuo puede acumular. Además, los bancos centrales +podrían cobrar una tarifa si fuera necesario. Una tarifa de actualización de +este tipo, cuando las monedas están programadas para caducar, implicaría de +hecho tasas de interés negativas en la CBDC, y haría que la CBDC resultara +menos atractiva como depósito de valor, tal como sugiere Bindseil (2020). De +hecho, sería la implementación directa de la idea de Silvio Gesell de aplicar +un ``impuesto de posesión'' sobre la moneda, al que hace célebremente +referencia~\citet{Keynes}, y reviven~\citet{Goodfriend}, \citet{Buiter} +y~\citet{Agarwal}. + +En cuanto a las posibles implicaciones para las políticas monetarias, no +anticipamos efectos materiales porque nuestra CBDC está diseñada para +replicar el dinero en efectivo en lugar de los depósitos bancarios. La +emisión, retiro y depósito de nuestra CBCD corresponden exactamente a la +emisión, retiro y depósito de billetes. Es posible que una CBDC al por +menor tenga un ritmo de circulación diferente a la del efectivo físico, +pero esto no sería un problema material para las políticas monetarias. + +\hypertarget{trabajos-relacionados}{% +\section{Trabajos relacionados}\label{6.-trabajos-relacionados}} + +Como se señaló anteriormente, la CBDC propuesta en el presente documento se +basa en eCash y GNU Taler.\footnote{La implementación de eCash por la compañía +DigiCash en los años noventa está documentada en +\url{https://www.chaum.com/ecash}.} A partir de la propuesta original de Chaum +para el efectivo electrónico, la investigación se ha centrado en tres +cuestiones principales. Primero, en la propuesta original de Chaum las monedas +tenían un valor fijo y solo podían gastarse en su totalidad. Pagar grandes +cantidades con monedas denominadas en centavos sería ineficiente, por lo +que~\citet{Okamoto}, \citet{Camenisch2005}, \citet{Canard} y~\citet{Dold} +idearon formas de abordar este problema. Estas soluciones involucran +protocolos para dar cambio o para posibilitar la divisibilidad de las monedas. + +Una segunda cuestión es que las transacciones a veces fallan debido a +caídas de la red, por ejemplo. En este caso, el sistema debe permitir +que los fondos permanezcan con el consumidor sin impacto negativo sobre +privacidad. \citet{Camenisch2007} y~\citet{Dold} abordan este tema en +su propuesta de dinero electrónico respaldado. Varias de las soluciones +anteriores violan las garantías de privacidad para los clientes que +utilizan estas funciones, y todas, excepto Taler, violan el requisito de +transparencia de ingresos. + +La tercera cuestión importante, a menudo desatendida, es conservar la +transparencia de los ingresos y, por lo tanto, el cumplimiento del AML y +KYC. \citet{Fuchsbauer} diseñaron deliberadamente un sistema que +posibilita la desintermediación para proporcionar una semántica más +similar al efectivo. Sin embargo, la desintermediación ilimitada +generalmente no concuerda con las regulaciones del AML y KYC, ya que no +permite lograr ningún nivel de responsabilidad. Un ejemplo de tal diseño +es ZCash, un libro mayor distribuido que oculta a la red la información +sobre el pagador, el beneficiario y el monto de la transacción, siendo +por lo tanto el sistema de pago perfecto para la delincuencia en línea. +Solo Taler ofrece tanto la privacidad constante del cliente como la +transparencia de los ingresos, al mismo tiempo que proporciona un cambio +eficiente, intercambios atómicos~\cite[consulte][]{Camenisch2007} y la +capacidad de restaurar billeteras desde una copia de seguridad. + +Con respecto a los sistemas de pago para las CBDC, \citet{Danezis} diseñaron +un libro mayor escalable con RSCoin. Básicamente es un sistema RTGS que es +protegido utilizando la misma criptografía que se usa en Bitcoin. Al igual que +Taler, el diseño utiliza la fragmentación de la base de datos para lograr una +escalabilidad lineal. Sin embargo, el diseño de~\citet{Danezis} no tiene +ninguna disposición para la privacidad y carece de consideraciones sobre cómo +integrar prácticamente el diseño con los sistemas y procesos bancarios +existentes. + +La EUROchain del Banco Central Europeo\cite[véase][]{ECB} es otro +prototipo para CBDC con libro mayor distribuido. Similar a la +arquitectura propuesta en el presente documento, la EUROchain utiliza +una arquitectura de dos niveles donde los bancos comerciales actúan como +intermediarios. Una diferencia crucial es la manera en que los sistemas +intentan combinar la privacidad y el cumplimiento del AML. En nuestro +diseño, los reguladores podrían imponer un límite a la cantidad de +efectivo electrónico que el titular de una cuenta bancaria puede retirar +durante un cierto tiempo, mientras que la EUROchain emite un número +limitado de ``vales de anonimato'' que conceden al receptor un número +limitado de transacciones sin verificación del AML. Como estos vales +parecen no tener ninguna relación con ningún token de valor, no queda +claro de qué manera el diseño evitaría la aparición de un mercado negro +de ``vales de anonimato''. Además, la noción de anonimato de la +EUROchain es muy diferente, ya que sus ``vales de anonimato'' simplemente +eliminan ciertas verificaciones del AML, al mismo tiempo que preservan +la capacidad de los bancos comerciales de ver cómo los consumidores +gastan el efectivo electrónico. Mientras que los pagadores usuarios de +Taler interactúan directamente con los comerciantes para gastar su +efectivo electrónico, el sistema EUROchain requiere que los pagadores +instruyan a sus bancos comerciales para que accedan a su CBDC. Por lo +tanto, la EUROchain no emite tokens de valor directamente a los +consumidores y, en cambio, depende de que los consumidores se +autentiquen ellos mismos en sus bancos comerciales para acceder a la +CBDC que el banco central mantiene efectivamente en custodia. Por lo +tanto, no está claro qué ventajas de privacidad, rendimiento o seguridad +tiene la EUROchain sobre el dinero existente en depósito. + +\section{Conclusión}\label{7.-conclusiuxf3n} + +Con la aparición de Bitcoin y monedas digitales recientemente propuestas +por grandes empresas tecnológicas como Diem (antes Libra), los bancos +centrales se enfrentan a una competencia cada vez mayor de actores que +ofrecen su propia alternativa digital al efectivo físico. Las decisiones +de los bancos centrales sobre la emisión o no de una CBDC dependen de +cómo evalúen los beneficios y los riesgos de una CBDC. Estos beneficios +y riesgos, así como las circunstancias jurisdiccionales específicas que +definen el alcance de las CBDC al por menor, probablemente difieran de +un país a otro. + +Si un banco central decide emitir una CBDC al por menor, proponemos una +CBDC basada en tokens que combina la privacidad de las transacciones con +el cumplimiento del KYC, AML y CFT. Dicha CBDC no competiría con los +depósitos de los bancos comerciales, sino que reproduciría el efectivo +físico, lo que limitaría los riesgos de estabilidad financiera y +políticas monetarias. + +Hemos demostrado que el esquema propuesto aquí sería tan eficiente y +rentable como los sistemas RTGS modernos operados por los bancos +centrales. Los pagos electrónicos con nuestra CBDC solo necesitarían una +simple base de datos para las transacciones y cantidades minúsculas de +ancho de banda. La eficiencia y la rentabilidad, junto con la facilidad +de uso mejorada para el consumidor provocada por el cambio de la +autenticación a la autorización, hacen que este esquema sea +probablemente el primero en respaldar el objetivo largamente previsto de +los micropagos en línea. Además, el uso de monedas para firmar +criptográficamente contratos electrónicos permitiría el uso de contratos +inteligentes. Esto también podría conducir a la aparición de +aplicaciones completamente nuevas para los sistemas de pago. Aunque +nuestro sistema no se basa en la DLT, podría integrarse fácilmente con +dichas tecnologías si así lo requirieran las infraestructuras del +mercado financiero en el futuro. + +Igualmente importante, sin embargo, es que una CBDC al por menor debe +preservar el efectivo como un bien común respetuoso de la privacidad +bajo el control individual de los ciudadanos. Esto se puede lograr con +el esquema propuesto en este documento, y los bancos centrales pueden +evitar perturbaciones significativas en sus políticas monetarias y +estabilidad financiera cosechando al mismo tiempo los beneficios de la +digitalización. + + +\newpage +%REFERENCIAS +\bibliographystyle{agsm} +\bibliography{cbdc} + +\end{document} |