Desde hace tiempo estamos interesados en el tema de la anonimidad en las criptomonedas y estamos atentos al desarrollo de tecnologías en este campo. En nuestros artículos ya hemos analizado detalladamente los principios de funcionamiento en Monero, así como hemos realizado tecnologías existentes en este ámbito. Sin embargo, todas las criptomonedas anónimas actuales se basan en un modelo de datos propuesto por Bitcoin — Unspent Transaction Output (UTXO). Para las blockchains basadas en cuentas como Ethereum, las soluciones existentes para implementar la anonimidad y confidencialidad (por ejemplo, o ) intentaron replicar el modelo UTXO en contratos inteligentes.
En febrero de 2019, un grupo de investigadores de la Universidad de Stanford y Visa Research no se manifiesta titulado “Zether: Hacia la privacidad en el mundo de los contratos inteligentes”. Los autores propusieron por primera vez un enfoque para garantizar la anonimidad en las blockchains basadas en cuentas y presentaron dos variantes de contratos inteligentes: para transacciones confidenciales (ocultación de saldos y montos de transferencias) y anónimas (ocultación del receptor y del emisor). Consideramos que la tecnología propuesta es interesante y nos gustaría compartir su funcionamiento, así como discutir por qué el problema de la anonimidad en las blockchains basadas en cuentas se considera muy complejo y si los autores lograron resolverlo completamente.
Sobre el funcionamiento de estos modelos de datos
En el modelo UTXO, una transacción consta de "entradas" y "salidas". El equivalente directo a las “salidas” son los billetes en su cartera: cada “salida” tiene un cierto valor nominal. Cuando paga a alguien (forma una transacción), gasta una o más “salidas”, convirtiéndolas en “entradas” de la transacción, y la blockchain las marca como gastadas. A su vez, el receptor de su pago (o usted mismo si necesita cambio) recibe nuevas “salidas” generadas. Esquema esto se puede representar así:
Las blockchains basadas en cuentas funcionan de manera similar a su cuenta bancaria. Solo operan con la cantidad en su cuenta y la cantidad de la transferencia. Cuando transfiere una cantidad desde su cuenta, no quema ninguna “salida”, y la red no necesita recordar qué monedas han sido gastadas y cuáles no. En el caso más simple, la verificación de la transacción se reduce a comprobar la firma del emisor y la cantidad en su saldo:
Análisis de la tecnología
A continuación, hablaremos sobre cómo Zether oculta la cantidad de las transacciones, el receptor y el remitente. A lo largo de la descripción de sus principios de funcionamiento, señalaremos las diferencias entre la versión confidencial y la anónima. Dado que es mucho más sencillo garantizar la confidencialidad en blockchains basados en cuentas, algunas de las restricciones impuestas por la anonimización no serán relevantes para la versión confidencial de la tecnología.
Ocultamiento de saldos y montos de transferencias
Para cifrar los saldos y montos de transferencias en Zether se utiliza un esquema de cifrado Funciona de la siguiente manera. Cuando Alice quiere enviar a Bob b monedas a la dirección (su clave pública) Y, elige un número aleatorio r y cifra la cantidad:
donde C — cantidad cifrada, ataques — valor auxiliar necesario para descifrar esta cantidad, G — punto fijo en la curva elíptica, que al multiplicar la clave secreta da como resultado la clave pública.
Cuando Bob recibe estos valores, simplemente los suma a su balance cifrado de la misma manera, lo que hace que este esquema sea conveniente.
De manera análoga, Alice resta de su saldo los mismos valores, solo que utiliza su clave pública como Y referencia.
Ocultamiento del receptor y remitente
El mezclado de “salidas” en UTXO apareció ya en los inicios de las criptomonedas y ayuda a ocultar al remitente. Para ello, el propio remitente al realizar la transferencia selecciona “salidas” aleatorias en la blockchain y las mezcla con las suyas. A continuación, firma las “salidas” con una firma en anillo, un mecanismo criptográfico que permite convencer al verificador de que entre las “salidas” mezcladas se encuentran las monedas del remitente. Por supuesto, las monedas mezcladas no se gastan.
Sin embargo, para ocultar al receptor no podemos generar “salidas” falsas. Por lo tanto, en UTXO cada “salida” tiene su dirección única, que está criptográficamente vinculada a la dirección del receptor de estas monedas. Actualmente no hay forma de identificar la relación entre la dirección única de la “salida” y la dirección del receptor sin conocer sus claves secretas.
En un modelo basado en cuentas, no podemos usar direcciones desechables (de lo contrario, sería un modelo de «salidas»). Por lo tanto, el receptor y el remitente deben mezclarse entre otras cuentas en la cadena de bloques. En este proceso, de las cuentas mezcladas se deducen 0 monedas cifradas (o se añaden 0 en el caso de mezclar al receptor), sin cambiar realmente su saldo real.
Dado que tanto el remitente como el receptor siempre tienen una dirección constante, aquí surge la necesidad, al realizar transferencias a las mismas direcciones, de utilizar los mismos grupos para la mezcla. Es más fácil verlo con un ejemplo.
Supongamos que Alicia decidió hacer una donación a la fundación benéfica de Bob, pero prefiere que esta transferencia permanezca anónima para un observador externo. Entonces, para ocultar su identidad en el campo del remitente, incluye también las cuentas de Adán y Adela. Y para ocultar a Bob, añade en el campo del receptor las cuentas de Ben y Bill. Al realizar la siguiente donación, Alicia decidió incluir junto a sí a Alex y Amanda, y junto a Bob a Bruce y Benjen. En este caso, al analizar la cadena de bloques, solo habrá un par de participantes intersectados en estas dos transacciones: Alicia y Bob, lo que desanonymiza estas transacciones.
Carreras de transacciones
Como ya mencionamos, para ocultar su saldo en sistemas basados en cuentas, el usuario cifra su saldo y la cantidad de la transferencia. Al hacerlo, debe demostrar que el saldo de su cuenta sigue siendo no negativo. El problema es que, al crear una transacción, el usuario construye una prueba en relación con su estado actual de cuenta. ¿Y qué sucede si Bob envía a Alicia una transacción, y esta se acepta antes que la enviada por Alicia? Entonces, la transacción de Alicia se considerará inválida, ya que la prueba de saldo se construyó antes de la aceptación de la transacción de Bob.
La primera solución que se le ocurre a uno en tal situación es congelar la cuenta hasta que se realice la transacción. Pero este enfoque no es adecuado, ya que, además de la complejidad de resolver tal problema en un sistema distribuido, en un esquema anónimo no sería claro a quién se le debe bloquear la cuenta.
Para solucionar este problema, la tecnología divide las transacciones entrantes y salientes: el gasto tiene un efecto inmediato en el estado del balance, mientras que los ingresos son diferidos. Para esto, se introduce el concepto de “épocas”, que son grupos de bloques de tamaño fijo. La “época” actual se determina dividiendo la altura del bloque por el tamaño del grupo. Al procesar una transacción, la red actualiza inmediatamente el balance del remitente, mientras que los fondos del receptor se suman a un acumulador. Los fondos acumulados se ponen a disposición del receptor del pago solo cuando comienza una nueva “época”.
Como resultado, el usuario puede enviar transacciones independientemente de la frecuencia con la que reciba fondos (en la medida en que su balance lo permita, por supuesto). El tamaño de la época se determina según la rapidez con que los bloques se difunden a través de la red y qué tan rápido una transacción entra en un bloque.
Esta solución funciona bien en el caso de transferencias privadas, sin embargo, en el caso de transacciones anónimas, como veremos más adelante, plantea problemas serios.
Protección contra ataques de repetición
En las cadenas de bloques basadas en cuentas, cada transacción se firma con la clave privada del remitente, lo que convence al verificante de que la transacción no ha sido alterada y que fue creada por el propietario de esa clave. Pero, ¿qué pasa si un atacante, que ha estado escuchando el canal de transmisión, intercepta este mensaje y envía exactamente el mismo segundo? El verificador comparará la firma de la transacción y estará convencido de su autoría, y la red deducirá la misma cantidad del balance del remitente nuevamente.
A este ataque se le llama ataque de repetición. En el modelo UTXO, tales ataques no son relevantes, ya que el atacante intentaría usar salidas gastadas, lo que en sí mismo no es válido y es rechazado por la red.
Para evitar esto, se incorpora un campo con datos aleatorios en la transacción, que se llama nonce o simplemente “sal”. Al volver a enviar una transacción con una “sal”, el verificador comprueba si ese nonce se ha usado anteriormente y, si no, considera válida la transacción. Para no almacenar toda la historia de los nonces de los usuarios en la cadena de bloques, generalmente en la primera transacción se establece que su valor es cero y luego se incrementa en uno. A la red solo le queda verificar que el nonce de la nueva transacción difiera del anterior en uno.
En un esquema anónimo de transferencias surge el problema de validación de los nonces de las transacciones. No podemos vincular el nonce de manera explícita a la dirección del remitente, ya que, evidentemente, esto desanonimizaría la transferencia. Tampoco podemos incrementar en uno los nonces de todas las cuentas involucradas, ya que esto podría entrar en conflicto con otras transferencias que están en proceso.
Los autores de Zether proponen generar nonces criptográficamente, dependiendo de la "época". Por ejemplo:
Aquí x — la clave secreta del remitente, y Gepoch — un generador adicional para la época, obtenido mediante el hashing de una cadena del tipo 'Zether + '. Ahora, el problema parece resolverse, ya que no revelamos el nonce del remitente y no interferimos en los nonces de participantes ajenos. Pero este enfoque impone una limitación seria: una cuenta puede enviar no más de una transacción en una "época". Este problema, desafortunadamente, permanece sin resolver y en este momento hace que la versión anónima de Zether, en nuestra opinión, sea poco práctica para su uso.
Complejidad de las pruebas de cero conocimiento
En UTXO, el remitente debe demostrar a la red que no está gastando una cantidad negativa, de lo contrario es posible generar nuevas monedas de la nada (por qué esto es posible, hemos escrito en uno de nuestros anteriores ). Y también firmar los "entradas" con una firma de anillo para demostrar que entre las monedas mezcladas hay fondos que le pertenecen.
En la versión anónima de blockchain basada en cuentas, las expresiones para la prueba se vuelven mucho más complejas. El remitente demuestra que:
- La cantidad enviada es positiva;
- El saldo permanece no negativo;
- El remitente ha cifrado correctamente las cantidades de las transferencias (incluidas las cero);
- El saldo cambia únicamente en las cuentas del remitente y el receptor;
- El remitente posee la clave secreta de su cuenta y realmente está en la lista de remitentes (entre los mezclados);
- El nonce utilizado en la transacción está compuesto correctamente.
Para tal prueba compleja, los autores utilizan una mezcla (uno de los autores, por cierto, participó en su creación) y , que se denomina Sigma-bullets. La prueba formal de tal afirmación es una tarea bastante complicada y limita mucho el número de interesados en implementar esta tecnología.
¿Cuál es el resultado?
En nuestra opinión, la parte de Zether que introduce privacidad en los blockchains basados en cuentas ya puede ser utilizada en este momento. Sin embargo, la versión anónima de la tecnología impone serias limitaciones a su uso, y su complejidad representa un desafío para su implementación. No obstante, no se debe pasar por alto que los autores la lanzaron hace solo unos meses, y es posible que alguien más encuentre una solución a los problemas actuales. Después de todo, así es como se hace ciencia.
Fuente: habr.com
