Durante mucho tiempo hemos estado interesados en el tema del anonimato en las criptomonedas y tratamos de seguir el desarrollo de tecnologías en esta área. En nuestros artículos, ya hemos examinado en detalle los principios de operación de
transacciones confidenciales en Monero, y también hemos realizado una
revisión comparativa de las tecnologías que existen en este campo. Sin embargo, todas las criptomonedas anónimas de hoy se basan en el modelo de datos propuesto por Bitcoin: Salida de transacciones no gastadas (en adelante, UTXO). Para blockchains basadas en cuentas como Ethereum, las soluciones existentes para la implementación del anonimato y la privacidad (por ejemplo,
Mobius o
Aztec ) intentaron repetir el modelo UTXO en los contratos inteligentes.
En febrero de 2019, un grupo de investigadores de la Universidad de Stanford y Visa Research
lanzó el
preprint "Zether: hacia la privacidad en el mundo de los contratos inteligentes". Los autores primero propusieron un enfoque para garantizar el anonimato en blockchains basados en cuentas y presentaron dos opciones para un contrato inteligente: para transacciones confidenciales (ocultando saldos y cantidades de transferencia) y anónimas (ocultando destinatario y remitente). Consideramos que la tecnología propuesta es interesante y nos gustaría compartir su dispositivo, así como hablar sobre por qué el problema del anonimato en blockchains basados en cuentas se considera muy complejo y si los autores lograron resolverlo por completo.
Sobre el dispositivo de estos modelos de datos
En el modelo UTXO, una transacción consta de "entradas" y "salidas". Un análogo directo a las "salidas" es el billete en su billetera: cada "salida" tiene una cierta denominación. Cuando paga con alguien (forma una transacción), gasta uno o más "resultados", mientras se convierten en "entradas" de la transacción, y la cadena de bloques los marca como gastados. Al mismo tiempo, el destinatario de su pago (o usted mismo, si necesita un cambio) recibe los "resultados" recién generados. Esquemáticamente, esto se puede representar de la siguiente manera:
Las blockchains basadas en cuentas están estructuradas como su cuenta bancaria. Solo operan sobre el monto en su cuenta y el monto de la transferencia. Cuando transfiere una cierta cantidad de su cuenta, no quema ninguna "salida", la red no necesita recordar qué monedas se gastan y cuáles no. En el caso más simple, la verificación de una transacción se reduce a verificar la firma del remitente y el monto en su balance:
Análisis de tecnología
A continuación, hablaremos sobre cómo Zether oculta la cantidad de transacciones, el destinatario y el remitente. En el curso de la descripción de los principios de su trabajo, notaremos las diferencias en la versión confidencial y anónima. Dado que es mucho más fácil garantizar la confidencialidad en blockchains basados en cuentas, algunas de las restricciones impuestas por el anonimato no serán relevantes para una versión confidencial de la tecnología.
Ocultación de saldos e importes de transferencia.
Zether utiliza el esquema de encriptación
El Gamal para encriptar saldos y transferir cantidades. Funciona de la siguiente manera. Cuando Alice quiere enviar monedas de Bob
b a la dirección (su clave pública)
Y , elige un número aleatorio
r y cifra la cantidad:
donde
C es la suma cifrada,
D es el valor auxiliar necesario para descifrar esta suma,
G es el punto fijo en la curva elíptica, cuando la clave secreta se multiplica por la cual se obtiene la clave pública.
Cuando Bob recibe estos valores, simplemente los agrega a su saldo, encriptados de la misma manera, lo cual es conveniente para este esquema.
De manera similar, Alice resta los mismos valores de su balance general, solo usa
Y como su clave pública.
Ocultamiento del destinatario y remitente.
La mezcla de "salidas" en UTXO apareció en los albores de las criptomonedas y ayuda a ocultar al remitente. Para hacer esto, el remitente, cuando realiza una transferencia, recoge "salidas" aleatorias en la cadena de bloques y las amasa con las suyas. Luego firma las "salidas" con una firma de anillo, un mecanismo criptográfico que le permite convencer al verificador de que entre las "salidas" involucradas hay monedas emisoras. Las monedas implicadas, por supuesto, no se desperdician.
Sin embargo, para ocultar al destinatario, no podremos generar "salidas" falsas. Por lo tanto, en UTXO, cada "salida" tiene su propia dirección única, y está criptográficamente asociada con la dirección del destinatario de estas monedas. Por el momento, no hay forma de identificar la relación entre la dirección de "salida" única y la dirección del destinatario sin conocer sus claves secretas.
En un modelo basado en cuentas, no podemos usar direcciones de una sola vez (de lo contrario, ya será un modelo de "salidas"). Por lo tanto, el destinatario y el remitente deben ser amasados entre otras cuentas en la cadena de bloques. Al mismo tiempo, las monedas cifradas 0 se debitan de las cuentas amasadas (o se agrega 0, en el caso de un amasador del destinatario), sin cambiar realmente su saldo real.
Dado que tanto el remitente como el destinatario siempre tienen una dirección permanente, aquí es necesario usar los mismos grupos para mezclar con las mismas direcciones. Es más fácil considerar esto con un ejemplo.
Supongamos que Alice decide contribuir a la organización benéfica de Bob, pero prefiere que la transferencia permanezca anónima a un observador externo. Luego, para disfrazarse en el campo del remitente, también ingresa a las cuentas de Adam y Adele. Y para ocultar a Bob, en el campo del destinatario, además de las cuentas de Ben y Bill. Al hacer la próxima entrega, Alice decidió ingresar a Alex y Amanda junto a ella, y Bruce y Bengen junto a Bob. En este caso, al analizar la cadena de bloques en estas dos transacciones, solo hay un par de participantes que se entrecruzan: Alice y Bob, que desanonimizan estas transacciones.
Carreras de transacciones
Como ya mencionamos, para ocultar su saldo en sistemas basados en cuentas, el usuario cifra su saldo y el monto de la transferencia. Además, debe demostrar que el saldo en su cuenta no es negativo. El problema es que cuando se forma una transacción, el usuario crea evidencia con respecto a su estado actual de la cuenta. ¿Y qué sucede si Bob envía una transacción a Alice, y será aceptada antes de que Alice la envíe? Entonces la transacción de Alice se considerará inválida, porque la prueba de saldo se creó antes de la adopción de la transacción Bob.
La primera solución que se presenta en tal situación es congelar su cuenta antes de la transacción. Pero este enfoque no es adecuado, porque además de la complejidad de resolver un problema de este tipo en un sistema distribuido, en un esquema anónimo no quedará claro qué cuenta bloquear.
Para resolver este problema, la tecnología separa las transacciones entrantes y salientes: gastar dinero tiene un efecto inmediato en el balance general y los ingresos se difieren. Para esto, se introduce el concepto de "era": un grupo de bloques de un tamaño fijo. La "era" actual se determina dividiendo la altura del bloque por el tamaño del grupo. Al procesar la transacción, la red actualiza el saldo del remitente de inmediato y agrega los fondos del destinatario a la unidad. Los fondos acumulados están disponibles para el beneficiario solo cuando se establece una nueva "era".
Como resultado, el usuario puede enviar transacciones independientemente de la frecuencia con la que recibe fondos (siempre que su saldo lo permita, por supuesto). El tamaño de una época se determina en función de la rapidez con que los bloques se extienden por la red y la rapidez con que la transacción cae en el bloque.
Esta solución funciona bien en el caso de transferencias confidenciales, pero con transacciones anónimas, como veremos más adelante, crea serios problemas.
Reproducción de protección contra ataques
En blockchains basados en cuentas, cada transacción está firmada por la clave privada del remitente, lo que convence al verificador de que la transacción no ha sido modificada y fue creada por el propietario de esta clave. Pero, ¿qué pasa si el atacante que estaba escuchando el canal de transmisión intercepta este mensaje y envía exactamente el mismo segundo? El verificador verificará la firma de la transacción y se convencerá de su autoría, y la red debitará nuevamente la misma cantidad del saldo del remitente.
Este ataque se llama ataque de repetición. En el modelo UTXO, tales ataques no son relevantes, porque el atacante intentará usar las salidas gastadas, que en sí mismas no son válidas y son rechazadas por la red.
Para evitar que esto suceda, se inserta un campo de datos aleatorio en la transacción, que se llama nonce o simplemente "salt". Al volver a enviar una transacción con sal, el revisor busca para ver si este nonce se ha utilizado antes y, si no, considera que esta transacción es válida. Para no almacenar todo el historial de usuarios que no son usuarios en la cadena de bloques, generalmente se considera cero en la primera transacción, y luego se incrementa en uno. La red solo puede verificar que el nonce de la nueva transacción difiere del pasado en uno.
En un esquema de traducción anónimo, surge el problema de validar las transacciones nonce. No podemos vincular nonce explícitamente a la dirección del remitente, porque, obviamente, esto desanoniza la traducción. Tampoco podemos agregar una unidad al nonce de todas las cuentas participantes, ya que esto puede entrar en conflicto con otras traducciones que se están procesando.
Los autores de Zether proponen generar nonce criptográficamente, dependiendo de la "era". Por ejemplo:
Aquí
x es la clave secreta del remitente, y
G epoch es un generador adicional para la era, obtenido al trocear una cadena de la forma 'Zether +'. Ahora parece que el problema se está resolviendo: no revelamos el nonce del remitente y no interferimos con el nonce de los participantes no involucrados. Pero este enfoque impone una seria limitación: una cuenta no puede enviar más de una transacción en la "era". Este problema, desafortunadamente, sigue sin resolverse y actualmente hace que una versión anónima de Zether, en nuestra opinión, sea poco adecuada para su uso.
Evidencia de confianza cero
En UTXO, el remitente debe demostrar a la red que no está gastando una cantidad negativa, de lo contrario, es posible generar nuevas monedas desde el aire (por qué esto fue posible, escribimos en uno de los
artículos anteriores). Y también firme las "entradas" con una firma de anillo para demostrar que entre las monedas de amasado hay fondos que le pertenecen.
En la versión anónima de blockchain basada en cuentas, las expresiones de prueba son mucho más complicadas. El remitente prueba que:
- La cantidad enviada es positiva;
- El saldo sigue siendo no negativo;
- El remitente cifró correctamente la cantidad de transferencias (incluido cero);
- El saldo se cambia solo por el remitente y el destinatario;
- El remitente posee la clave secreta de su cuenta y él realmente está en la lista de remitentes (entre los involucrados);
- El nonce utilizado en la transacción está compuesto correctamente.
Para una prueba tan compleja, los autores usan una mezcla de
Bulletproof (uno de los autores, por cierto, participó en su creación) y el
protocolo Sigma , que se llama Sigma-bullets. La prueba formal de tal declaración es una tarea bastante difícil, y limita severamente el número de personas que desean asumir la implementación de la tecnología.
Cual es el resultado?
En nuestra opinión, la parte de Zether, que agrega privacidad a las blockchains basadas en cuentas, bien puede usarse ahora. Pero en este momento, una versión anónima de la tecnología impone restricciones serias en su uso y su complejidad en la implementación. Sin embargo, no olvide que los autores lo lanzaron hace solo unos meses, y tal vez alguien más encuentre una solución a los problemas hoy. De hecho, así es como se hace la ciencia.