Llevamos mucho tiempo interesados en el tema del anonimato en las criptomonedas e intentamos seguir el desarrollo de las tecnologías en este ámbito. En nuestros artículos ya hemos discutido en detalle los principios de funcionamiento. en Monero, y también llevado a cabo tecnologías existentes en este campo. Sin embargo, todas las criptomonedas anónimas actuales se basan en el modelo de datos propuesto por Bitcoin: Unspent Transaction Output (en adelante, UTXO). Para cadenas de bloques basadas en cuentas como Ethereum, las soluciones existentes para implementar el anonimato y la confidencialidad (por ejemplo, o ) intentó replicar el modelo UTXO en contratos inteligentes.
En febrero de 2019, un grupo de investigadores de la Universidad de Stanford y Visa Research liberado "Zether: Hacia la privacidad en el mundo de los contratos inteligentes". Los autores fueron los primeros en proponer un enfoque para garantizar el anonimato en las cadenas de bloques basadas en cuentas y presentaron dos versiones de un contrato inteligente: para transacciones confidenciales (ocultando saldos y montos de transferencia) y anónimas (ocultando al destinatario y al remitente). La tecnología propuesta nos parece interesante y nos gustaría compartir su diseño, así como hablar sobre por qué el problema del anonimato en las cadenas de bloques basadas en cuentas se considera muy difícil y si los autores lograron resolverlo por completo.
Acerca de la estructura de estos modelos de datos
En el modelo UTXO, una transacción consta de "entradas" y "salidas". El análogo directo de las "salidas" son los billetes en su billetera: cada "salida" tiene alguna denominación. Cuando le pagas a alguien (mediante una transacción), gastas una o más "salidas", en cuyo caso se convierten en "entradas" de la transacción, y la cadena de bloques las marca como gastadas. En este caso, el destinatario de su pago (o usted mismo, si necesita un cambio) recibe las “salidas” recién generadas. Esto se puede representar esquemáticamente así:
Las cadenas de bloques basadas en cuentas están estructuradas de forma muy parecida a su cuenta bancaria. Solo se ocupan del monto en su cuenta y el monto de la transferencia. Cuando transfieres una cierta cantidad desde tu cuenta, no quemas ninguna "salida", la red no necesita recordar qué monedas se han gastado y cuáles no. En el caso más sencillo, la verificación de la transacción se reduce a comprobar la firma del remitente y el importe de su saldo:
Análisis de tecnología
A continuación, hablaremos sobre cómo Zether oculta el monto de la transacción, el destinatario y el remitente. A medida que describamos los principios de su funcionamiento, notaremos las diferencias entre las versiones confidencial y anónima. Dado que es mucho más fácil garantizar la confidencialidad en las cadenas de bloques basadas en cuentas, algunas de las restricciones impuestas por la anonimización no serán relevantes para la versión confidencial de la tecnología.
Ocultar saldos y montos de transferencia
Se utiliza un esquema de cifrado para cifrar saldos y transferir cantidades en Zether . Funciona de la siguiente manera. Cuando Alice quiere enviar a Bob b monedas por dirección (su clave pública) Y, ella elige un número aleatorio r y cifra la cantidad:
donde C - cantidad cifrada, D - valor auxiliar necesario para descifrar esta cantidad, G - un punto fijo en la curva elíptica, al multiplicarlo por la clave secreta se obtiene la clave pública.
Cuando Bob recibe estos valores, simplemente los agrega a su saldo cifrado de la misma manera, razón por la cual este esquema es conveniente.
De manera similar, Alice resta los mismos valores de su saldo, solo que como Y utiliza su clave pública.
Ocultar el destinatario y el remitente
La mezcla de "salidas" en UTXO se remonta a los primeros días de las criptomonedas y ayuda a ocultar al remitente. Para hacer esto, el propio remitente, al realizar una transferencia, recopila "salidas" aleatorias en la cadena de bloques y las mezcla con las suyas. Luego, firma las "salidas" con una firma en anillo, un mecanismo criptográfico que le permite convencer al verificador de que las monedas del remitente están presentes entre las "salidas" involucradas. Las monedas mixtas, por supuesto, no se gastan.
Sin embargo, no podremos generar salidas falsas para ocultar al destinatario. Por lo tanto, en UTXO, cada “salida” tiene su propia dirección única y está vinculada criptográficamente a 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 el modelo basado en cuentas, no podemos utilizar direcciones únicas (de lo contrario, ya será un modelo de “salidas”). Por lo tanto, el destinatario y el remitente deben mezclarse entre otras cuentas en la cadena de bloques. En este caso, se debitan 0 monedas cifradas de las cuentas mixtas (o se añaden 0 si el destinatario es mixto), sin cambiar realmente su saldo real.
Dado que tanto el remitente como el destinatario siempre tienen una dirección permanente, es necesario utilizar los mismos grupos para mezclar cuando se realizan transferencias a las mismas direcciones. Es más fácil ver esto con un ejemplo.
Digamos que Alice decide hacer una contribución a la organización benéfica de Bob, pero prefiere que la transferencia permanezca anónima para un observador externo. Luego, para disfrazarse en el campo del remitente, también ingresa en las cuentas de Adam y Adele. Y para ocultar a Bob, agregue las cuentas de Ben y Bill en el campo del destinatario. Al hacer la siguiente contribución, Alice decidió escribir a Alex y Amanda junto a ella, y a Bruce y Benjen junto a Bob. En este caso, al analizar la cadena de bloques, en estas dos transacciones solo hay un par de participantes que se cruzan: Alice y Bob, lo que anonimiza estas transacciones.
Carreras de transacciones
Como ya hemos mencionado, para ocultar su saldo en los sistemas basados en cuentas, el usuario cifra su saldo y el monto de la transferencia. Al mismo tiempo, debe demostrar que el saldo de su cuenta no es negativo. El problema es que al crear una transacción, el usuario genera una prueba sobre el estado actual de su cuenta. ¿Qué sucede si Bob envía una transacción a Alice y es aceptada antes que la enviada por Alice? Entonces la transacción de Alice se considerará inválida, ya que la prueba de saldo se creó antes de que se aceptara la transacción de Bob.
La primera decisión que se toma en tal situación es congelar la cuenta hasta que se realice 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 estará claro de quién es la cuenta bloquear.
Para resolver este problema, la tecnología separa las transacciones entrantes y salientes: el gasto tiene un efecto inmediato en el balance, mientras que los ingresos tienen un efecto retardado. Para hacer esto, se introduce el concepto de "época": un grupo 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 saldo del remitente y almacena los fondos del destinatario en un tanque de almacenamiento. Los fondos acumulados se ponen a disposición del beneficiario sólo cuando comienza una nueva “era”.
Como resultado, el usuario puede enviar transacciones independientemente de la frecuencia con la que reciba los fondos (hasta donde su saldo lo permita, por supuesto). El tamaño de la época se determina en función de la rapidez con la que los bloques se propagan a través de la red y la rapidez con la que una transacción ingresa a un bloque.
Esta solución funciona bien para transferencias confidenciales, pero con transacciones anónimas, como veremos más adelante, crea serios problemas.
Protección contra ataques de repetición
En las cadenas de bloques basadas 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 un 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 quedará convencido de su autoría, y la red cancelará nuevamente la misma cantidad del saldo del remitente.
Este ataque se llama ataque de repetición. En el modelo UTXO, este tipo de ataques no son relevantes, ya que el atacante intentará utilizar salidas gastadas, que en sí mismas no son válidas y son rechazadas por la red.
Para evitar que esto suceda, 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 salt, el verificador comprueba si el nonce se ha utilizado antes y, en caso contrario, considera la transacción válida. Para no almacenar todo el historial de registros de usuarios en la cadena de bloques, normalmente en la primera transacción se iguala a cero y luego se aumenta en uno. La red solo puede verificar que el nonce de la nueva transacción difiera uno por uno del anterior.
En el esquema de transferencia anónima, surge el problema de validar los nonces de las transacciones. No podemos vincular explícitamente el nonce a la dirección del remitente, ya que, obviamente, esto anonimiza la transferencia. Tampoco podemos agregar uno a los nonces de todas las cuentas participantes, ya que esto puede entrar en conflicto con otras transferencias que se estén procesando.
Los autores de Zether proponen generar el nonce criptográficamente, dependiendo de la “época”. Por ejemplo:
es x es la clave secreta del remitente, y Gepoch — un generador adicional para la época, obtenido mediante hash de una cadena de la forma 'Zether + '. Ahora el problema parece estar resuelto: no revelamos el nonce del remitente y no interferimos con los nonce de los participantes no involucrados. Pero este enfoque impone una limitación importante: una cuenta no puede enviar más de una transacción por "época". Desafortunadamente, este problema sigue sin resolverse y actualmente hace que, en nuestra opinión, la versión anónima de Zether sea poco adecuada para su uso.
La complejidad de las pruebas de conocimiento cero
En UTXO, el remitente debe demostrarle a la red que no está gastando una cantidad negativa; de lo contrario, es posible generar nuevas monedas de la nada (por qué es posible esto, escribimos en uno de los artículos anteriores). ). Y también firmar las “entradas” con una firma anular para acreditar que entre las monedas que se mezclan hay fondos que le pertenecen.
En la versión anónima de la cadena de bloques basada en cuentas, las expresiones de prueba son mucho más complejas. El remitente prueba que:
- La cantidad enviada es positiva;
- El saldo sigue siendo no negativo;
- El remitente cifró correctamente los montos de la transferencia (incluido cero);
- El saldo del saldo cambia solo para el remitente y el destinatario;
- El remitente posee la clave privada de su cuenta y, de hecho, 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 utilizan una mezcla (uno de los autores, por cierto, participó en su creación) y , que se llaman balas Sigma. La prueba formal de tal afirmación es una tarea bastante difícil y limita en gran medida el número de personas dispuestas a implementar la tecnología.
¿El resultado?
En nuestra opinión, la parte de Zether que aporta privacidad a las cadenas de bloques basadas en cuentas se puede utilizar ahora mismo. Pero por el momento, la versión anónima de la tecnología impone serias restricciones a su uso y complejidad a su implementación. Sin embargo, no se debe descartar que los autores lo publicaron hace solo unos meses, y quizás alguien más encuentre una solución a los problemas que existen hoy. Después de todo, así es como se hace ciencia.
Fuente: habr.com