Continuamos nuestra serie sobre la cadena de bloques de Monero y el artículo de hoy se centrará en el protocolo RingCT (Ring Confidential Transactions), que presenta transacciones confidenciales y nuevas firmas de anillo. Desafortunadamente, hay poca información en Internet sobre cómo funciona y hemos intentado llenar este vacío.
Hablaremos sobre cómo la red oculta los montos de las transferencias usando este protocolo, por qué abandonaron las clásicas firmas en anillo de criptonotas y cómo se desarrollará aún más esta tecnología.
Dado que este protocolo es una de las tecnologías más complejas de Monero, el lector necesitará un conocimiento básico del diseño de esta cadena de bloques y un conocimiento pasajero de criptografía de curva elíptica (para repasar este conocimiento, puede leer los primeros capítulos de nuestro artículo anterior sobre ).
Protocolo RingCT
Uno de los posibles ataques a las criptomonedas es el análisis de blockchain basado en el conocimiento del monto y el momento de la transacción enviada. Esto permite reducir significativamente el área de búsqueda de salidas de interés para el atacante. Para protegerse contra dicho análisis, Monero ha implementado un protocolo de transacciones anónimas que oculta completamente los montos de las transferencias en la red.
Vale la pena señalar que la idea de ocultar montos no es nueva. El desarrollador de Bitcoin Core, Greg Maxwell, fue uno de los primeros en describirlo en su . La implementación actual de RingCT es su modificación con la posibilidad de usar firmas en anillo (o sin ellas), y de ahí su nombre: Transacciones Confidenciales en Anillo.
Entre otras cosas, el protocolo ayuda a eliminar los problemas con la mezcla de salidas de polvo: salidas de una pequeña cantidad (normalmente recibidas en forma de cambio de transacciones), que creaban más problemas de los que valían.
En enero de 2017, se produjo una bifurcación dura de la red Monero, que permitió el uso opcional de transacciones confidenciales. Y ya en septiembre del mismo año, con la versión 6 del hard fork, este tipo de transacciones se convirtieron en las únicas permitidas en la red.
RingCT utiliza varios mecanismos a la vez: firmas de grupo anónimos espontáneos vinculados de múltiples capas (Firma de grupo anónimo espontáneo vinculable de múltiples capas, en lo sucesivo, MLSAG), un esquema de compromiso (Compromisos de Pedersen) y pruebas de rango (este término no tiene una traducción establecida al ruso) .
El protocolo RingCT introduce dos tipos de transacciones anónimas: simples y completas. La billetera genera el primero cuando una transacción utiliza más de una entrada, el segundo, en la situación opuesta. Se diferencian en la validación de los montos de las transacciones y los datos firmados con una firma MLSAG (hablaremos más sobre esto a continuación). Además, las transacciones de tipo completo se pueden generar con cualquier número de entradas, no existe una diferencia fundamental. En el libro En este sentido, se dice que la decisión de limitar las transacciones completas a un solo insumo se tomó apresuradamente y puede cambiar en el futuro.
firma del MLSAG
Recordemos qué son las entradas de transacciones firmadas. Cada transacción gasta y genera algunos fondos. Los fondos se generan creando resultados de transacciones (una analogía directa son los billetes), y el resultado que gasta la transacción (después de todo, en la vida real gastamos billetes) se convierte en la entrada (tenga cuidado, es muy fácil confundirse aquí). .
Una entrada hace referencia a múltiples salidas, pero gasta solo una, creando así una "cortina de humo" que dificulta el análisis del historial de traducción. Si una transacción tiene más de una entrada, entonces dicha estructura se puede representar como una matriz, donde las filas son las entradas y las columnas son las salidas mixtas. Para demostrarle a la red que la transacción gasta exactamente sus resultados (conoce sus claves secretas), las entradas se firman con una firma en anillo. Dicha firma garantiza que el firmante conocía las claves secretas de todos los elementos de cualquiera de las columnas.
Las transacciones confidenciales ya no utilizan las clásicas firmas de anillo, fueron reemplazadas por MLSAG, una versión de firmas de anillo de una sola capa similares adaptadas para múltiples entradas, .
Se llaman multicapa porque firman varias entradas a la vez, cada una de las cuales se mezcla con varias otras, es decir, se firma una matriz y no una fila. Como veremos más adelante, esto ayuda a ahorrar en el tamaño de la firma.
Veamos cómo se forma una firma en anillo, usando el ejemplo de una transacción que gasta 2 salidas reales y usa m - 1 aleatorias de la cadena de bloques para mezclar. Denotemos las claves públicas de las salidas que gastamos como
e imágenes clave para ellos en consecuencia: Por tanto, obtenemos una matriz de tamaño 2xm. Primero, necesitamos calcular los llamados desafíos para cada par de resultados:
Comenzamos los cálculos con las salidas, que gastamos usando sus claves públicas:y números aleatoriosComo resultado, obtenemos los siguientes valores:
, que utilizamos para calcular el desafío
el siguiente par de salidas (para que sea más fácil entender qué estamos sustituyendo y dónde, hemos resaltado estos valores en diferentes colores). Todos los valores siguientes se calculan en un círculo utilizando las fórmulas que figuran en la primera ilustración. Lo último que hay que calcular es el desafío para un par de resultados reales.
Como podemos ver, todas las columnas, excepto la que contiene resultados reales, utilizan números generados aleatoriamente.. Para π- columna también los necesitaremos. transformemosEn s:
La firma en sí es una tupla de todos estos valores:
Estos datos luego se escriben en una transacción.
Como podemos ver, MLSAG contiene solo un desafío. c0, que le permite ahorrar en el tamaño de la firma (que ya requiere mucho espacio). A continuación, cualquier inspector, utilizando los datos, restablece los valores c1,…, cm y comprueba que. Así, nuestro anillo queda cerrado y la firma ha sido verificada.
Para las transacciones RingCT de tipo completo, se agrega una línea más a la matriz con resultados mixtos, pero hablaremos de esto a continuación.
Compromisos de Pedersen
(El término inglés compromisos se utiliza con más frecuencia) se utilizan para que una de las partes pueda demostrar que conoce un determinado secreto (número) sin revelarlo. Por ejemplo, tiras un determinado número en los dados, consideras el compromiso y lo pasas a la parte verificadora. Así, en el momento de revelar el número secreto, el verificador calcula de forma independiente el compromiso, asegurándose así de que no lo engañaste.
Los compromisos de Monero se utilizan para ocultar los montos de las transferencias y utilizan la opción más común: los compromisos de Pedersen. Por cierto, un dato interesante: al principio los desarrolladores propusieron ocultar las cantidades mediante una mezcla ordinaria, es decir, agregar salidas en cantidades arbitrarias para introducir incertidumbre, pero luego cambiaron a compromisos (no es un hecho que ahorraron en el tamaño de la transacción, como veremos a continuación).
En general, el compromiso se ve así:
Donde C — el significado del compromiso mismo, a - cantidad oculta, H es un punto fijo en la curva elíptica (generador adicional), y x — una especie de máscara arbitraria, un factor de ocultación generado al azar. La máscara es necesaria aquí para que un tercero no pueda simplemente adivinar el valor del compromiso.
Cuando se genera una nueva salida, la billetera calcula el compromiso y, cuando se gasta, toma el valor calculado durante la generación o lo recalcula, según el tipo de transacción.
AnilloCT simple
En el caso de transacciones RingCT simples, para garantizar que la transacción generó resultados en una cantidad igual a la cantidad de insumos (no produjo dinero de la nada), es necesario que la suma de los compromisos del primero y segundo sean iguales, es decir:
Las comisiones de compromiso lo ven de manera un poco diferente, sin máscara:
Donde a — el importe de la comisión está a disposición del público.
Este enfoque nos permite demostrarle a la parte que confía que estamos utilizando las mismas cantidades sin revelarlas.
Para aclarar las cosas, veamos un ejemplo. Digamos que una transacción gasta dos salidas (lo que significa que se convierten en entradas) de 10 y 5 XMR y genera tres salidas por valor de 12 XMR: 3, 4 y 5 XMR. Al mismo tiempo, paga una comisión de 3 XMR. Así, la cantidad de dinero gastada más la cantidad generada y la comisión equivale a 15 XMR. Intentemos calcular los compromisos y observemos la diferencia en sus montos (recuerde las matemáticas):
Aquí vemos que para que la ecuación converja, necesitamos que las sumas de las máscaras de entrada y salida sean iguales. Para hacer esto, la billetera genera aleatoriamente x1, y1, y2 y y3, y el resto x2 calcula así:
Usando estas máscaras, podemos demostrarle a cualquier verificador que no generamos más fondos de los que gastamos, sin revelar el monto. Originales, ¿verdad?
RingCT completo
En las transacciones RingCT completas, verificar los montos de la transferencia es un poco más complicado. En estas transacciones, la billetera no recalcula los compromisos por los insumos, sino que utiliza los calculados cuando se generaron. En este caso debemos suponer que ya no obtendremos la diferencia de las sumas igual a cero, sino que:
es z — diferencia entre máscaras de entrada y salida. Si consideramos zG como clave pública (que de facto lo es), entonces z es la clave privada. Así, conocemos las claves pública y privada correspondiente. Teniendo estos datos, podemos usarlos en la firma del anillo MLSAG junto con las claves públicas de las salidas que se están mezclando:
Por lo tanto, una firma de anillo válida garantizará que conozcamos todas las claves privadas de una de las columnas, y solo podremos conocer la clave privada en la última fila si la transacción no genera más fondos de los que gasta. Por cierto, aquí está la respuesta a la pregunta "¿por qué la diferencia en los montos de los compromisos no conduce a cero?", si zG = 0, luego expandiremos la columna con resultados reales.
¿Cómo sabe el destinatario de los fondos cuánto dinero le enviaron? Aquí todo es simple: el remitente de la transacción y el destinatario intercambian claves utilizando el protocolo Diffie-Hellman, utilizando la clave de transacción y la clave de visualización del destinatario y calculan el secreto compartido. El remitente escribe datos sobre los importes de salida, cifrados con esta clave compartida, en campos especiales de la transacción.
Pruebas de rango
¿Qué sucede si utiliza un número negativo como monto en compromisos? ¡Esto puede conducir a la generación de monedas adicionales! Este resultado es inaceptable, por lo que debemos garantizar que las cantidades que utilizamos no sean negativas (sin revelar estas cantidades, por supuesto, de lo contrario habrá mucho trabajo y todo será en vano). En otras palabras, debemos demostrar que la suma está en el intervalo [0, 2n - 1].
Para ello, la suma de cada producción se divide en dígitos binarios y el compromiso se calcula para cada dígito por separado. Es mejor ver cómo sucede esto con un ejemplo.
Supongamos que nuestras cantidades son pequeñas y caben en 4 bits (en la práctica son 64 bits) y creamos una salida con un valor de 5 XMR. Calculamos los compromisos para cada categoría y el compromiso total por el importe total:
A continuación, cada compromiso se mezcla con una gestante subrogada. (Ci-2iH) y está firmado a pares con la firma del anillo Borromeo (otra firma del anillo), propuesta por Greg Maxwell en 2015 (puedes leer más al respecto ):
En conjunto, esto se denomina prueba de rango y le permite garantizar que los compromisos utilicen montos en el rango [0, 2n - 1].
¿Qué será lo próximo?
En la implementación actual, las pruebas de rango ocupan mucho espacio: 6176 bytes por salida. Esto conduce a transacciones más grandes y, por lo tanto, tarifas más altas. Para reducir el tamaño de una transacción de Monero, los desarrolladores están introduciendo pruebas de balas en lugar de firmas de Borromeo, un mecanismo de prueba de rango sin compromisos bit a bit. , son capaces de reducir el tamaño de la prueba de rango hasta en un 94%. Por cierto, a mediados de julio pasó la tecnología. de Kudelski Security, que no reveló deficiencias significativas ni en la tecnología en sí ni en su implementación. La tecnología ya se utiliza en la red de prueba y, con el nuevo hard fork, probablemente pueda trasladarse a la red principal.
Haga sus preguntas, sugiera temas para nuevos artículos sobre tecnologías en el campo de las criptomonedas y también suscríbase a nuestro grupo en para estar al día de nuestros eventos y publicaciones.
Fuente: habr.com