Hace unos meses un buen amigo me hizo esta pregunta pero ese momento no tenía una respuesta tan clara. Ahora sí tengo una buena respuesta gracias a bastante estudio, experimentación y mucha ayuda que me han dado los expertos. Al terminar este artículo, te podrás hacer una espectativa más acertada sobre lo que se viene, sobre lo que ya se puede construir y lo que hace falta.

Quizás escuchaste que ZK es fundamental para Ethereum, ¡y sí es verdad! Esta tecnología trae dos propiedades muy importantes: la escalabilidad y la privacidad. Ya hemos visto la rápida implementación de ZK en escalabilidad a través de los rollups. Desde que zkSync lanzó su canal de pagos, hasta hoy que tenemos Rollups zkEVM que ofrecen la misma experiencia que Ethereum pero a una fracción de su costo.

Entonces, ¿porqué no ha ocurrido lo mismo con la privacidad? ¿Porqué no hay aplicaciones en Ethereum que hagan uso de la privacidad de ZK?

¿Es tán difícil ZK?

En realidad, no tanto.

Al inicio pensé que era un problema de falta de investigación. O falta de las herramientas necesarias para crear aplicaciones de esta naturaleza. Pero este claramente no es el caso pues seguramente hacer una zkEVM es mucho más complicado que, por ejemplo, votos anónimos on-chain.

Con esto no quiero decir que hacer aplicaciones con privacidad es sencillo, se necesita unir una serie de tecnologías: contratos, circuitos, probadores WASM en el navegador, una red de relayers incentivados. Pero a pesar que sea complejo no deja de ser accesible. Por cierto, si te llama la atención tengo una guía paso a paso sobre cómo hacerlo.

Habiendo descartado esta posibilidad, a continuación comparto las 3 razones por las que no hay aplicaciones de privacidad con adopción masiva en Ethereum.

Problema #1: Incertidumbre regulatoria

Saquemos primero el elefante en la habitación. El proyecto de privacidad con mayor cantidad de usuarios que ha tenido crypto ha sido Tornado Cash. Un mixer capaz de mantener nuestras finanzas privadas, protegiendo así nuestra soberanía y seguridad como individuos. El problema es que también se le da el poder a los hackers, estafadores y otros actores maliciosos de borrar su rastro.

Hoy Tornado Cash está prohibido para los ciudadanos estadounidenses, los repositorios de github archivados y un desarrollador en la cárcel (nota: se presume que no está en la carcel por desarollar en sí). Esto ha generado un clima de incertidumbre en los desarrolladores, inversionistas y usuarios.

La solución a este problema existe dentro la misma tecnología. Para entenderla primero debemos hablar ver cómo funciona un mixer. En resumidas cuentas, un mixer en el fondo usa algo que llamamos Prueba de Inclusión, donde demostramos que depositamos en un smart contract específico sin revelar cuál depositante somos. De esta manera podemos retirar fondos a una nueva address limpia.

La solución es aplicar el proceso inverso, una Prueba de Exclusión, para demostrar que no soy uno de los address excluídos o blacklisteados. Combinando ambas pruebas, la de inclusión con la de exclusión, puedo demostrar que soy un depositante honesto y mantener mi identidad privada.

El debate moral sobre bajo qué criterios se excluye un participante persiste. Pero ZK es una tecnología flexible y expresiva que puede adaptarse a diferentes regulaciones o requerimientos.

Problema #2: Mala UX

Esto va más allá que el problema de guardar las 12 palabras en un papel para crear una wallet. Sí, este es un problema que tenemos en web3 y seguimos trabajando para resolver. Pero ZK le agrega un nuevo inconveniente: largos tiempos de prueba en el cliente.

Resulta que el equipo de Ethereum, en etapas iniciales de desarrollo no sabía que iba a ser tán problemático implementar Keccak256 como algoritmo de hasheo para crear las cuentas. Pedersen o Poseidon son opciones con tiempos de para producir pruebas ZK mucho menores.

Si un desarrollador decide tomar el camino de Keccak, los usuarios pueden usar por ejemplo Metamask o Rabby. Pero el tiempo de generar una prueba es de varios minutos en una PC. Este problema se hace más grave en un celular porque adicionalmente se debe de tomar el sistema operativo no cierre el proceso si el usuario lo pone el teléfono en modo reposo.

Por otro lado, si se decide tomar el camino de Pedersen o Poseidon, se necesita crear un sistema de cuentas que no es compatible con las wallets de Ethereum como Metamask. ¿Quizás la solución es crear un sistema de cuentas con abstracción de cuentas combinado con una wallet nueva que los usuarios tienen que instalar? Suena como un esfuerzo bastante alto para onboardear usuarios.

Como nota positiva, hay bastante expectiva en métodos para reducir los costos y tiempos de espera usando Keccak256. Existen varios estudios y papers que en el futuro próximo serán aplicados.

Problema #3: Nulificadores ECDSA

Este problema es bastante técnico así que les invito a tener más paciencia.

Anteriormente mencionamos que usamos las Pruebas de Inclusión para demostrar que somos parte de un grupo sin demostrar cuál somos. Entonces ¿cómo prevenimos a alguien retirar dos veces los mismos fondos de un mixer? La respuesta es por medio de algo que llamamos nulificadores. Los nulificadores son una técnica creada para resolver el problema de, por ejemplo, el doble gasto (double spend) en DeFi, o de doble voto en un sistema de votación.

En Ethereum, podemos implementar nulificadores de la siguiente manera:

1. Los usuarios son colocados en una lista (o merkle tree), puede ser por ejemplo la lista de depositantes en un mixer, la lista de votantes o la lista de usuarios en una red social anónima.

2. Los usuarios firman un mensaje, este se usa para generar una prueba de manera local (en el navegador del usuario). La prueba contiene un hash de, en parte, la firma de un mensaje. De esta manera se puede verificar que es una firma válida sin revelar el orígen. A este hash le llamamos el nulificador.

3. Al pasar la prueba a un contrato de Ethereum, almacenamos el nulificador en el contrato (usualmente en un mapping(bytes32 nullifier => bool exists)). Únicamente se aceptan pruebas con nulificadores nuevos, de esta manera cada prueba o acción puede ser aplicada solo una vez.

El problema que tenemos es que el sistema de firmas actual no es nulificable. Es decir, las firmas implementadas en las wallets como Metamask, Rabby, Coinbase no tienen un mecanismo para generar hashs únicos. Y tampoco, con justa razón, mecanismos para extraer las llaves privadas.

Necesitamos implementar un nuevo sistema de firmas en las wallets. Pero este sistema debería ser adoptado por todas las wallets por igual, debería de existir un consenso. El mejor candidato que tenmos hoy es Plume. Y ya existen PRs, las wallets principales listos para ser mergeados. Pero las wallets se resisten a aceptarlo pues quieren estudiar primero la seguridad e implicaciones.

La alternativa también es implementar un sistema de firmas aparte con abstracción de cuentas (AA) que sea nulificable. Pero la comunidad de Ethereum no se ha decidido en un estandar aún.

Si eres un desarrollador nuevo en ZK, es importante no dejarte frenar por estas dificultades. Al contrario, busca alternativas creativas o soluciones a estas limitantes. Este es el espíritu que ha tenido blockchain y web3 desde su inicio. Estoy seguro que ZK seguirá avanzando y es por eso sigo estudiando de cerca esta tecnología.

¡Gracias por leer! Sígueme en Youtube, Twitter y dev.to para todo lo relacionado a ZK y Ethereum.