Introducción

Un punto importante de dolor para los usuarios de criptomonedas web3 es la falta de privacidad. El hecho de que todas las transacciones sean visibles en un libro mayor público, y cada vez más: asociadas con un único y legible nombre ENS, desincentiva a los usuarios a realizar ciertas actividades, o les hace realizar esas actividades de maneras que resultan en una mayor fricción en la experiencia de usuario. Un ejemplo es simplemente transferir fondos de una billetera caliente a una billetera fría o viceversa. Los usuarios pueden no querer que una billetera esté vinculada a otra, ya que no desean que se vea el saldo de su billetera fría. Actualmente, las direcciones de Ethereum no funcionan como cuentas bancarias privadas, porque todos pueden ver tu billetera, y cada vez más, tu actividad social (SBTs, certificaciones, actividades en diversas dapps, etc.). Es por estas razones que Vitalik mencionó la privacidad como una de las tres principales transiciones técnicasque Ethereum necesita llevar a cabo para ser útil para los usuarios promedio.

Usar soluciones de privacidad existentes, como Tornado Cash, es una experiencia algo subóptima por varias razones. En primer lugar, los usuarios tendrán razones para preocuparse por tener su dirección en una lista negra en intercambios centralizados u otras plataformas. En segundo lugar, la experiencia del usuario al interactuar con servicios como Tornado Cash no es muy amigable y realmente solo es adecuada para usuarios altamente competentes.

Las direcciones ocultas proporcionan una forma de brindar al usuario la privacidad que dan por sentado en las cuentas bancarias privadas, y de una manera fácil de entender. Además, las innovaciones en torno a las direcciones ocultas significan que potencialmente podemos hacer esto de una manera que cumpla con las regulaciones contra el lavado de dinero en numerosas jurisdicciones.

Demanda del usuario por la privacidad

Si bien la investigación sobre las actitudes hacia la privacidad entre los usuarios de la web y web3 no está ampliamente disponible, la siguiente investigación fue descubierta a través de búsquedas en la web y los resultados se alinean ampliamente y demuestran que hay un claro apetito por la privacidad de las transacciones.

1. Una encuesta que se llevó a cabo en 2022 y publicada por Simin Ghesmati et al. en un artículo titulado: Privacidad percibida por el usuario en la cadena de bloquesdeclaró que 'la mitad de los entrevistados especificaron que la privacidad de las transacciones es muy importante para ellos'. Aunque esta investigación estuvo más relacionada con Bitcoin que con Ethereum, es probable que existan actitudes similares entre los usuarios de Ethereum también. El tamaño de la muestra para esta investigación fue, sin embargo, bastante pequeño (14 participantes).
2. Otra interesante pieza de investigación de 2022, publicada en Fronteras, titulado Actitudes políticas, económicas y de gobernanza de los usuarios de blockchain, es más completo, con 3.710 usuarios de criptomonedas encuestados. Los resultados mostraron que alrededor de una cuarta parte de los encuestados indicaron que la privacidad es 'la característica más importante de blockchain y las criptomonedas'.

1. En cuanto a las actitudes hacia la privacidad en general,Consensyspublicó una investigación tituladaEncuesta global de Web3 y criptomonedas 2023, en la que encuestaron a 15,158 personas en línea en 15 países sobre varios temas relacionados con la web, y no solo con criptomonedas. La encuesta encontró que el 83% de los encuestados piensa que la privacidad de los datos es importante, mientras que solo el 45% de los encuestados afirmaron que confían en cómo los servicios actuales de Internet utilizan sus datos e información personal.
2. A encuesta realizada por el Esquema de Compensación de Servicios Financieros del Reino Unido, publicado en abril de 2023, destacó que el 9% de los encuestados citaron el "deseo de anonimato/privacidad" como su razón para invertir en criptomonedas.

Adopción de Protocolos de Transacciones Stealth

Railguntiene números impresionantes, con el uso del protocolo que parece estar creciendo constantemente con el tiempo, alcanzando un pico de más de $70M TVL y $2 mil millones en volumen hasta noviembre de 2024.

TVL (USD) Railgun en la red principal de Ethereum — fuente: Railgun - DefiLlama

Umbratambién ha visto un aumento constante de personas que utilizan su protocolo (personas que registran una dirección oculta en su ENS), con casi 77K hasta noviembre de 2024:

Registrantes Acumulados de Umbra (Cross Chain)— fuente: dune.com

Si observamos el protocolo de privacidad más conocido (y ahora desafortunadamente infame) en Ethereum, que es Tornado cash, podemos ver que todavía está siendo ampliamente utilizado, a pesar de que las direcciones de contrato están técnicamente en la lista SDN de OFAC.

El gráfico a continuación muestra el TVL de Tornado Cash a lo largo del tiempo. Podemos observar que la primera caída importante en el TVL desde su punto máximo alrededor de octubre de 2021 coincidió con una venta más amplia en los mercados de criptomonedas, mientras que la segunda caída importante en agosto de 2022 corresponde a que OFAC colocó a Tornado Cash en la lista SDN, y la tercera caída importante corresponde a la redesignación de OFAC en noviembre de 2022. Desde entonces, sin embargo, Tornado Cash ha estado experimentando un crecimiento constante, a pesar de las sanciones, alcanzando casi $600M en TVL. Esto es una evidencia bastante sólida de que existe una demanda de privacidad básica en las transacciones en Ethereum.

TVL (USD) Tornado Cash en Ethereum principal — fuente:Tornado Cash - DefiLlama

El Paisaje de la Dirección Oculta

Esta investigación ha identificado 4 soluciones principales para las cadenas EVM en producción hasta la fecha, las cuales son:

• Fluidkey
• Umbra
• Laberinto
• Railgun

Tanto Fluidkey como Umbra se basan en los estándares de Ethereum, que son:

• ERC-5564: Protocolo de Dirección Oculta
• ERC-6538: Registro de direcciones meta-ocultas

Labyrinth y Railgun se basan en el protocolo zerocash(que zcashtambién se basa en), que utiliza un grupo blindado en el que los usuarios depositan fondos. Zerocash utiliza el concepto de “notas”, que son básicamente representaciones criptográficas de valor que permiten transacciones privadas. Cada nota incluye un valor oculto, una clave del propietario y un número único (un anulador), con zk-SNARKs utilizados para verificar la propiedad sin revelar detalles, y por lo tanto transferir el valor en las notas. Cuando se gasta una nota, se revela su anulador para evitar el doble gasto, mientras que se crean nuevas notas para el(los) destinatario(s), formando un sistema UTXO dentro del grupo blindado.

A un nivel alto, las direcciones furtivas funcionan en base al principio básico de que un tercero puede enviar fondos a una dirección que nunca ha existido antes, pero que el destinatario pretendido puede descubrir y controlar (es decir, posteriormente gastar esos fondos).

El estándar erc-5564 especifica un mecanismo mediante el cual un destinatario puede publicar una dirección meta oculta, a partir de la cual se pueden derivar nuevas direcciones de Ethereum. Cualquier persona que desee enviar fondos al destinatario puede generar nuevas direcciones a partir de la dirección meta oculta y permitir que el destinatario se entere de estos fondos sin que se realice ninguna comunicación directa. Todas las implementaciones de direcciones ocultas funcionan sobre esta premisa básica.

Cómo funcionan las direcciones stealth

Una meta-dirección sigilosa es esencialmente la concatenación de 2 claves públicas comprimidas, conocidas como la "clave de gasto" y la "clave de visualización". La meta-dirección sigilosa utiliza el formato de dirección específico de la cadena EIP-3770, con la adición del prefijo "st:". El siguiente es un ejemplo de una dirección sigilosa:

st:eth:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0521b6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507

Para simplificar, esta dirección oculta puede estar asociada con una dirección Ethereum normal (y por lo tanto ENS), lo que facilita el envío de fondos al propietario de la dirección oculta. Para enviar fondos, un remitente resolvería la dirección mencionada anteriormente y, utilizando el estándar EIP-5564, crearía una clave pública efímera, a partir de la cual se deriva la dirección oculta. El remitente envía fondos a la nueva dirección oculta, normalmente a través de un contrato único al que todos los destinatarios de direcciones ocultas escuchan para eventos. Este contrato emite un evento de “Anuncio” al que se suscriben los destinatarios. Cada vez que se emite un evento de anuncio, los destinatarios verificarán la clave pública efímera en el anuncio, la combinarán con su clave privada de visualización y determinarán si tienen la capacidad de gastar los fondos enviados a la dirección oculta. Si pueden hacerlo, la billetera / cliente que están utilizando recordará la dirección oculta y los fondos respectivos, agregándolos al saldo mostrado del usuario. Para gastar realmente los fondos, pueden firmar una transacción utilizando la clave privada de gasto.

El siguiente diagrama describe el proceso de principio a fin, con suerte un poco más claro:

Recuerde que este proceso se lleva a cabo completamente de manera no interactiva, lo que significa que el remitente y el destinatario nunca tienen ninguna comunicación directa, lo que significa que no hay efectivamente ningún vínculo entre el remitente y el destinatario que cualquier tercero pueda observar.

Sin embargo, para que esto funcione en primer lugar, el destinatario debe comunicar su dirección oculta al remitente(s). Una forma de hacer esto es utilizar la Registro de direcciones meta sigilosas EIP-6538. Este es un contrato singleton que permite a los usuarios registrar una meta-dirección sigilosa en una dirección normal de Ethereum, que los remitentes pueden buscar. Esto permite a los remitentes resolver la dirección normal a través de ENS, y luego buscar la meta-dirección sigilosa asociada en el registro.

Este esquema rompe el vínculo entre el remitente y el destinatario, brindándoles privacidad a ambos para que el mundo no conozca sus negocios. Hay algunas advertencias:

• Cuando el destinatario vaya a gastar los fondos, la persona a la que transfiera esos fondos verá que se originaron en el remitente original (es decir, puede ver la dirección desde la que se transfirieron los fondos y quién envió fondos previamente a esa dirección). Lo que esto significa es que la cadena de transferencias permanece intacta y rastreable, pero simplemente no están asociadas con el destinatario en cuestión (a menos que el destinatario haga algo como enviar los fondos a una de sus direcciones no ocultas conocidas). Tenga en cuenta que esto solo se aplica a las implementaciones erc-5564, no a Railgun o Labyrinth.
• Otro efecto secundario del problema anterior es que, para mantener la privacidad óptima, es probable que un usuario necesite dejar los fondos en las direcciones ocultas a las que originalmente se enviaron hasta que realmente los necesiten, en lugar de consolidarlos bajo una única dirección. Esto representa una carga para recordar las direcciones y posteriormente gastar los fondos en esas direcciones, ya que la cantidad que desee transferir deberá provenir de la combinación de fondos en varias otras direcciones.
• Para transferir fondos desde esta dirección, el destinatario deberá financiar la dirección con algo de ETH para pagar el gas, y esto podría potencialmente desanonimizar al destinatario. Este es un problema conocido con las direcciones ocultas, y una de las razones por las cuales varios implementaciones han implementado soporte para eip-4337 y un maestro de pagos.
• Una desventaja del esquema de dirección oculta es que los destinatarios deben monitorear la cadena de bloques en busca de eventos de anuncio y verificar cada anuncio para determinar si se les ha enviado fondos. Esto obviamente representa una sobrecarga impráctica para la mayoría de los usuarios, especialmente cuando se trata de recibir fondos en múltiples redes. Con el fin de hacer este proceso más eficiente, el estándar especifica una 'etiqueta de vista', que es un hash truncado derivado del secreto compartido, y se puede utilizar para descartar rápidamente transacciones que definitivamente no están destinadas a ellos. Al utilizar las etiquetas de vista, el rendimiento no es tan malo en el escritorio, sin embargo, puede ser un poco más notable en dispositivos móviles. El único momento en que el impacto en el rendimiento es realmente notable es si se está restaurando una billetera, en cuyo caso la billetera deberá escanear cada dirección desde que se implementó el contrato en la cadena, lo cual lleva tiempo.
• Para solucionar esto, los usuarios pueden compartir opcionalmente la clave de visualización privada con un tercero de confianza. Este servicio de terceros puede monitorear varias redes y notificar a los usuarios cuando hayan recibido fondos. Por supuesto, esto implica un compromiso: aunque el tercero no puede gastar realmente los fondos de los usuarios (ya que no tienen la clave de gasto privada para hacerlo), pueden ver todos los fondos enviados a un destinatario específico, lo que significa que el usuario necesita confiar en ellos con su privacidad. Fluidkey hace esto de forma predeterminada.
• El protocolo de dirección encubierta estándar, es decir, ERC-5564, está diseñado para facilitar transferencias que preserven la privacidad. Sin embargo, los casos de uso no financieros, como llamar a funciones arbitrarias de contratos inteligentes, requieren un poco más de ingeniería y suelen ser específicos de la implementación.

Matriz de comparación

Hay varias formas en las que podemos comparar las cuatro implementaciones de direcciones ocultas que este post explora. Todas las implementaciones tienen diferencias sutiles y compensaciones, pero probablemente los puntos más importantes a destacar son la trazabilidad y la obfuscación del valor.

Si bien tanto Fluidkey como Umbra permiten transferir fondos a una dirección Ethereum estándar sin revelar la identidad del destinatario, aún preservan la trazabilidad de la transacción, lo que significa que el remitente es visible para cualquier persona que examine el historial de transacciones de la dirección oculta. Esto significa que si recibe fondos en una dirección oculta, la persona a la que decida enviar esos fondos verá de dónde provienen. Además, el valor real que se está transfiriendo también es visible. Railgun y Labyrinth ocultan al remitente, así como el valor que se envía, pero con el compromiso de que todo esto sucede dentro de un solo contrato, y no como una transacción normal a una dirección Ethereum normal.

La figura de abajo muestra cómo los protocolos que analizamos en esta publicación se comparan entre sí en estas dos dimensiones importantes de comparación.

Para explorar las diferencias un poco más en detalle, a continuación se muestra una matriz de comparación de los cuatro protocolos principales de dirección sigilosa en seis dimensiones principales:

1. Privacidad completa de extremo a extremo (solo el remitente y el destinatario ven el pago)
2. Secreto hacia adelante. El envío de fondos recibidos a través de transacciones furtivas no permite al segundo receptor ver de dónde provienen los fondos.
3. Sigue los estándares erc-5564 y erc-6538
4. Implementa una arquitectura modular extensible que permite la integración con dapps de terceros
5. ¿La implementación ofrece un SDK que los desarrolladores pueden usar para integrarse?
6. ¿Proporciona la solución un nivel de cumplimiento a través de algún tipo de soporte de desanonimización?
7. ¿El diseño admite la ofuscación del monto / valor que se está transfiriendo?

| Protocolo | Privacidad de extremo a extremo | Secreto adelante | Estándar abierto | Arquitectura modular | SDK | Soporte de desanonimización | Cantidad oculta |

|—————-|——————-|————————-|————————|———————————|———|—————————————|————————|

| Umbra | ✅ | ⛔️ | ✅ | ⛔️ | ⛔️ | ⛔️ | ⛔️ |

| Fluidkey | ⛔️ | ⛔️ | ✅ | ✅ | pronto | ✅ | ⛔️ |

| Labyrinth | ✅ | ✅ | ⛔️ | ✅ | ✅ | ✅ | ✅ |

|Railgun| ✅ | ✅ | ⛔️ | ✅ | ✅ | voluntario | ✅ |

Algunas de las otras sutilezas y diferencias se capturan con más detalle en la siguiente sección. Cada implementación tiene diferencias sutiles interesantes que pueden o no marcar la diferencia dependiendo de su caso de uso.

Por ejemplo: en Fluidkey: todas las transferencias van directamente a direcciones ocultas en la cadena, con Umbra: solo ETH va a direcciones ocultas en la cadena, mientras que los tokens van al contrato central, y con Railgun y Labyrinth, todas las transacciones van a contratos principales, no directamente a direcciones ocultas en la cadena.

Profundizando en las implementaciones de direcciones ocultas

Fluidkey

Fluidkeyes una implementación de erc-5564 que permite a los usuarios enviar, recibir, intercambiar y transferir ETH y tokens erc-20. En el momento de la escritura, Fluidkey está desplegado en Base, Optimism, Arbitrum, Polygon, Gnosis y la red principal de Ethereum.

Los usuarios interactún con Fluidkey a través de su interfaz web. Cuando inician sesión por primera vez utilizando su billetera, firman un mensaje de generación de claves del que se derivan sus claves de visualización y gasto. Estas mismas claves se regeneran de la misma manera cada vez que el usuario ingresa a la aplicación.

Hay algunas formas en que Fluidkey difiere de otras implementaciones. Una forma en que Fluidkey difiere de otras implementaciones de direcciones ocultas es que los usuarios comparten su clave de visualización privada con Fluidkey (en realidad una,BIP-32nodo derivado de la clave para ser pedante). Esto permite a Fluidkey generar direcciones furtivas para el usuario y también notificar al usuario cuando ha recibido pagos a esas direcciones. Sin embargo, significa que Fluidkey está en una posición de ver las transacciones entrantes y los saldos de un usuario, lo que supone un compromiso. Sin embargo, sigue siendo completamente auto-custodiado.

Otro aspecto interesante del diseño de Fluidkey es que despliega una cuenta de contrato inteligente para cada nueva dirección oculta. Esto sucede de manera contraria solo cuando se gastan fondos de una dirección oculta. La cuenta inteligente es una cuenta de seguridad 1/1 y permite cosas como el patrocinio de gas, lo que facilita la administración de las diferentes direcciones ocultas juntas. Hay detalles completos al respecto en su Paseo técnico.

Aunque Fluidkey tiene la desventaja de mantener la visibilidad de las cuentas de un usuario, esto puede ser potencialmente una ventaja en términos de cumplimiento, aunque el marco exacto de cómo Fluidkey manejará cosas como posibles solicitudes de aplicación de la ley en el futuro no está disponible públicamente aún. Sin embargo, están basados en Suiza y, aunque deben cumplir con las leyes locales, las leyes de protección de datos son muy claras y muy sólidas: debe haber un caso muy claro para compartir los datos y también debe ser revisado por un tribunal.ver esta publicaciónpara obtener una excelente visión general de las leyes de privacidad en Suiza).

Los usuarios también son totalmente libres de exportar sus transacciones o compartir sus claves de visualización con terceros (por ejemplo, su contador), lo cual puede ser extremadamente útil, especialmente para las empresas. Sin embargo, vale la pena tener en cuenta que con la especificación erc-5564, compartir la clave pública es 'todo o nada', lo que significa que no puede revelar transacciones individuales aisladas por sí mismas. Además, al igual que con todas las implementaciones de erc-5564, la rastreabilidad no se ve afectada, solo la capacidad de vincularla al usuario, lo que significa que el historial de transacciones de cada dirección oculta está expuesto a quien tenga la clave de visualización. Una característica no muy conocida de Fluidkey que ayuda a mitigar estos compromisos es la capacidad de rotar las claves de visualización, lo que permitiría a un usuario utilizar una nueva clave de visualización cada mes y compartir el acceso de visualización solo para meses específicos con un tercero.

Un buen beneficio del enfoque de Fluidkey es que la dirección oculta en sí no es generada por el remitente, sino que es generada por Fluidkey de forma pseudoaleatoria cada vez que se consulta ENS. Esto es mucho más rápido porque los usuarios no tienen que escanear eventos de anuncio para identificar transacciones en las que son los destinatarios. Esto también significa que el remitente no necesita una billetera de dirección oculta para generar una dirección oculta para el destinatario, simplemente envían fondos a una dirección como lo harían a cualquier otra dirección y eso es todo. Esto también significa que no hay un contrato de registro involucrado, lo cual es único en el diseño de Fluidkey y una ventaja importante.

Vale la pena decir que Fluidkey está comprometido a ser completamente autónomo, y han abierto su biblioteca Stealth Account Kit, y también hay varias interfaces de recuperación desarrolladas de forma independiente disponibles en caso de que Fluidkey desaparezca de la noche a la mañana, lo que significa que los fondos nunca quedarán bloqueados o atascados.

Abstracción de direcciones

Al utilizar de manera contrarreloj las cuentas de contrato inteligente, Fluidkey puede abstraer automáticamente la gestión de las direcciones ocultas individuales. Esto significa que si desea transferir una cantidad específica a un determinado destinatario desde sus saldos a través de varias direcciones ocultas, Fluidkey puede determinar automáticamente qué combinación de direcciones utilizar para obtener los fondos para la transferencia, gestionando todos los costos de gas y despliegues de contrato, todo en segundo plano. Fluidkey también permite a los usuarios ejercer cierto control sobre qué direcciones se combinan mediante una función genial llamada etiquetas, que permite al usuario etiquetar direcciones en diferentes categorías.

Resolución ENS

Fluidkey requiere que los usuarios creen nombres ENS que son específicos de Fluidkey. Estos nombres estáticos toman 2 formas: username.fkey.id y username.fkey.eth, uno de los cuales es una URL a la interfaz web para enviar fondos a alguien, y el otro es un nombre ENS estándar que se puede utilizar con billeteras.

La configuración del ENS utiliza un Resolver fuera de la cadena de ENS (también conocido como erc-3668: CCIP Read) para devolver direcciones ocultas. Cada vez que se consulta el resolutor fuera de cadena, genera y devuelve una nueva dirección oculta para el nombre ENS correspondiente. Esta es una característica interesante ya que permite a un usuario tener un único nombre ENS legible por humanos y al mismo tiempo mantener la privacidad de las direcciones ocultas, ya que las direcciones ocultas generadas no se pueden vincular con el nombre ENS de manera retrospectiva.

Costo

Fluidkey es gratuito y no cobra ninguna tarifa. Existe el costo de implementar un contrato de Safe a cada dirección que tenga fondos cuando se desea gastar esos fondos. Sin embargo, aunque es relativamente costoso en mainnet, en L2 es realmente insignificante, generalmente menos de 1 centavo, incluso al combinar múltiples direcciones ocultas en una sola transferencia.

También pueden patrocinar el gas a través de las implementaciones seguras: calculan cuánto va a costar el gas y lo toman del saldo de los usuarios, incluso si es un token. En este caso, un relayer implementa la caja fuerte y transfiere el token en nombre del usuario.

Umbra Cash

Umbraes una implementación de eip-5564 + eip6538 porScopelift. Cuando un usuario inicia sesión en la aplicación Umbra, pasa por una fase de configuración, en la que firma un mensaje, del cual se derivan las claves de gasto y vista y la correspondiente meta-dirección sigilosa. Luego registran esta meta-dirección sigilosa en su dirección de billetera principal en un registro en cadena. Aquí es donde la implementación difiere de Fluidkey.

La implementación de Umbra de erc-5564 es la más cercana a la especificación, ya que no tienen acceso a las claves del usuario. Si bien esto significa que Umbra (o cualquier otra persona) no puede ver los fondos de los usuarios, también significa que, para enviar fondos, el remitente debe tener una billetera compatible con erc-5564 (o la aplicación Umbra) para generar su dirección meta oculta.

Cuando alguien quiere enviarCuando alguien quiere enviar fondos a un usuario, normalmente usarán la aplicación Umbra para hacerlo. Básicamente, la aplicación Umbra buscará la meta-dirección sigilosa registrada a un nombre ENS / dirección de billetera y generará una dirección sigilosa. Los destinatarios pueden iniciar sesión en la aplicación Umbra y buscar cualquier fondo que les hayan enviado a direcciones sigilosas que les pertenezcan desde la última vez que iniciaron sesión. Gracias a un almacenamiento en caché inteligente, esto parece tardar solo 10-15 segundos para un escaneo semanal, aunque los usuarios también pueden especificar opcionalmente un rango de bloques para estrechar el escaneo. Umbra v2 incluirá el uso de viewtags, lo que acelerará aún más el proceso.

Relayer

Un problema con las direcciones Stealth que hemos mencionado anteriormente es que, para que el destinatario pueda gastar los fondos que se enviaron a una dirección Stealth, dicha dirección necesitará tener ETH u otro token de gas necesario para pagar las tarifas de transacción. En la mayoría de las redes, si la dirección Stealth recibió ETH en primer lugar, esto generalmente no es un problema. Sin embargo, si la dirección Stealth recibió un token ERC-20 o NFT, entonces el acto de financiar la dirección con ETH para pagar el gas puede vincular la dirección a otras direcciones del usuario, eliminando su privacidad.

Para solucionar esto, Umbra utiliza una construcción que implica un intermediario. Cuando se envía cualquier activo que no sea ETH a un usuario de Umbra, en realidad se envía a un contrato especial en lugar de enviarlo directamente a la dirección oculta. Los usuarios pueden gastar los fondos enviados a sus direcciones ocultas enviando una meta-transacción (desde la aplicación de Umbra) al intermediario de Umbra, que transferirá los fondos fuera del contrato inteligente en nombre del usuario. El intermediario deducirá algunos tokens para cubrir los costos de las tarifas de gas, y solo se admiten inicialmente cierta cantidad de tokens.

Costo

El contrato de Umbra también aplica una pequeña tarifa al transferir fondos en redes con comisiones de transacción bajas, con el fin de desincentivar el correo no deseado. La lógica es que el correo no deseado aumentaría el costo de escanear las transacciones para identificar las relevantes, por lo que se considera un compromiso aceptable.

Redes compatibles

Umbra se encuentra actualmente desplegado en la mainnet de Ethereum, así como en Optimism, Polygon, Gnosis Chain y Arbitrum.

El contrato de registro de Umbra tiene un diseño interesante. El método de implementación utiliza create2 y el implementador estándar de create2, y la dirección del contrato inteligente es la misma en cualquier red. Esto significa que si el contrato existe en una red determinada, entonces el cliente puede estar seguro de que es el contrato correcto. El cliente puede configurarse para agregar redes, y cualquiera puede implementar en cualquier red. Han canonizado el bytecode y el contrato no tiene propietario, lo que permite la implementación sin permisos de contratos de registro y anuncio en cualquier cadena por cualquier persona.

Umbra v2

Scopelift está desarrollando actualmenteversión 2 de Umbra, que introduce una nueva arquitectura modular que permite extender los contratos principales para admitir nuevos estándares de tokens o casos de uso no relacionados con pagos. Utilizando esta nueva arquitectura, los desarrolladores de terceros pueden construir módulos para cualquier tipo de estándar de token, por ejemplo, erc-1155, erc-7621, soporte para pagadores erc-4337 u cualquier otra cosa que se te ocurra. Actualmente, el contrato principal de Umbra admite dos escenarios, uno para ETH y otro para erc-20. La V2 admitirá muchos escenarios diferentes.

Laberinto

Laberintoes un protocolo que no se basa en eip-5564 + eip6538, sino que en su lugar utiliza pruebas de conocimiento cero para agregar anonimato y privacidad a las transacciones. El libro blanco de Labyrinth lo describe como un middleware “zkFi”: “zkFi ofrece una solución empaquetada que actúa como un middleware de privacidad con cumplimiento incorporado“. El cumplimiento incorporado se refiere a la “Desanonimización Selectiva” de Labyrinth, que es una solución sofisticada que permite desanonimizar ciertas transacciones a actores autorizados específicos, es decir, autoridades legales como interpol, etc., manteniendo al mismo tiempo transparencia y apertura.

Los contratos inteligentes centrales que utiliza Labyrinth incluyen un grupo multi-transaccional y multi-activo que permite al usuario realizar transacciones con múltiples activos en una sola transacción. Para gastar activos, un usuario escanea la red y obtiene datos de notas encriptadas, descifra las notas y filtra los activos que desea gastar. Posteriormente, el usuario crea un ZKP que incluye las transacciones y una firma de la clave de firma asociada con las notas de las que quiere gastar transacciones.

Parte de los contratos principales de Labrynth incluyen un contrato de conversión, que se comunica con contratos de proxy modulares, que básicamente son proxies para contratos externos. Por ejemplo, si un usuario quiere usar Labyrinth para interactuar con Uniswap, el usuario crearía una transacción que usaría el contrato de conversión para llamar a una operación de intercambio en un pool de Uniswap a través del contrato de proxy de Uniswap.

El protocolo zkFi de Labyrinth utiliza "notas" para hacer un seguimiento de los saldos y las transferencias. Una nota es esencialmente una estructura de datos que describe una cierta cantidad de algún activo y a qué dirección pertenece. Un cliente almacena la información necesaria para recrear una nota y la utiliza para gastar activos. Se almacena un compromiso con la nota (un hash de la identificación del activo, el propietario y el valor) en un árbol de Merkle en cadena. De hecho, Labyrinth utiliza dos árboles de Merkle, uno para las notas y otro para las direcciones raíz.

La estructura de datos de la nota contiene lo siguiente:

• assetId: Identificador del activo (ETH, WBTC, MATIC, etc.) que representa el valor de esta nota.
• valor: Valor o cantidad que representa la nota.
• leafIndex: El índice de hoja del árbol de compromiso de Merkle donde se insertará esta nota.
• enmascarado: Un factor enmascarado aleatorio.
• rootAddress: La dirección raíz de un usuario que tiene la autoridad para gastarla.
• revoker: El punto de clave pública del revoker elegido.

Notarás que la estructura de datos anterior no contiene ninguna referencia al propietario de los activos, lo cual es extraño, ya que el compromiso que se registra en el árbol Merkle de las notas es un hash del ID del activo, el valor y el propietario. De hecho, el propietario se calcula a partir de la dirección raíz, el revocador y un factor de enmascaramiento aleatorio, por lo que para los observadores externos, el propietario es en realidad una dirección recién creada para cada nueva transacción.

Pool protegido

Lo que es realmente interesante acerca de Laberinto, que también es ligeramente diferente de los protocolos basados en direcciones de sigilo, es que el pool de activos es en realidad un pool blindado, que utiliza el concepto de notas para crear una especie de pool de UTXO blindado que brinda confidencialidad hacia adelante a las transacciones. Recuerde que con las implementaciones de eip-5564, la entidad a la que un usuario transfiere fondos podrá ver de dónde provienen esos fondos. En otras palabras, Alice paga a Bob usando una dirección de sigilo, Bob paga a Charlie, por lo que ahora Charlie puede ver que Bob inicialmente recibió los fondos de Alice, y así sucesivamente. Esto no ocurre con el pool blindado de Laberinto.

Para entender cómo funciona este grupo protegido, necesitamos ver cómo se transfieren los fondos dentro del protocolo:

Los saldos de un usuario en la pool protegida son la suma de las notas de los respectivos activos. Para gastar esas notas, el usuario necesita revelar los “anuladores” de esas notas. Un anulador es único para una nota, y una vez que se gasta esa nota, el anulador se marca para evitar dobles gastos, y se crea una nueva nota a partir de esa nota gastada. Varias notas del mismo activo pueden combinarse y pueden crearse varias notas nuevas. El anulador es simplemente el hash de (𝑙,𝑐,𝛿), donde 𝑙 es el índice del compromiso de la nota en el árbol de Merkle de las notas, y 𝑐 es el compromiso y 𝛿 es un elemento aleatorio también conocido como factor de enmascaramiento.

Un destinatario de una transferencia de transacción furtiva identifica la transferencia a través de los mismos medios que eip-5564, en la medida en que escuchan los eventos emitidos por los contratos principales y determinan a qué direcciones furtivas podrán enviar fondos, registrándolos localmente. La identificación de los fondos entrantes también se acelera mediante el uso de etiquetas de vista y mediante el almacenamiento en caché y sincronización local de notas de forma asincrónica durante la vida útil de la aplicación.

Actualmente se está investigando para hacer más rápido el proceso de descubrir los fondos recibidos, toma como ejemplo esta propuesta de Aztec:Solicitud de propuestas: Protocolo de Descubrimiento de Notas - Aztec.

Para gastar los fondos, el usuario también tiene que generar una prueba de zk, a diferencia de las implementaciones erc-6654, que son básicamente direcciones normales de Ethereum. La generación de una prueba requiere una billetera compatible, y el rendimiento es relativamente bueno, tomando unos 20 segundos más o menos en un dispositivo Android de gama media.

Agrupador y Convertidor

Labyrinth ofrece algunas características interesantes que resuelven algunos problemas de las transacciones sigilosas. Las transacciones enviadas a los contratos básicos de Labyrinth se envían como operaciones de usuario a través de los agrupadores erc-4337. Esta configuración permite gastar notas sin ETH ni requerir tokens de gas para las transacciones, ya que el usuario puede aprovechar el pagador erc-4337 para pagar el gas en su nombre, lo que agrega una capa adicional de privacidad. La única excepción es el depósito inicial, que no se envía como una operación de usuario. Este uso del pagador erc-4337 también tiene el beneficio adicional de poder pagar el gas a través de los activos que se transfieren, incluso si son tokens erc-20, y para ello Labyrinth expone una API de oráculo de precios de gas.

Otra característica muy interesante que tiene Labyrinth es una arquitectura modular que permite que los contratos de conversión actúen como proxy para aplicaciones de terceros. Esto permite a los usuarios no solo transferir fondos utilizando transacciones furtivas, sino también interactuar con aplicaciones de terceros como DEXs (por ejemplo, Uniswap, Aave, Lido, etc.). Estos contratos proxy de “conversión” implementan básicamente una función que recibe una cierta cantidad de un activo y devuelve una cierta cantidad de otro activo, con la lógica subyacente que reside en algún contrato de terceros.

Solución de Cumplimiento

Labyrinth garantiza el cumplimiento y la adhesión a las regulaciones a través de un marco llamado Desanonimización Selectiva (SeDe).

Recuerde que la estructura de datos de una nota contiene un campo llamado “revocador”. El revocador es la dirección de una entidad específica que puede iniciar el proceso de desanonimización. El usuario debe elegir al menos un revocador de una lista predefinida. El revocador no es el único responsable de identificar actividades potencialmente ilícitas o ilegales, pero puede responder a las solicitudes de las agencias de cumplimiento de la ley.

Los revocadores no tienen la capacidad unilateral de desanonimizar las transacciones directamente, pero son responsables de iniciar solicitudes de desanonimización. Estas solicitudes se publican públicamente a los guardianes, que son un comité de entidades encargadas de la privacidad y el cumplimiento. Los guardianes deben responder a la solicitud votando si otorgan o no permiso para desanonimizar la(s) transacción(es). Si los guardianes pueden alcanzar un quórum y votar a favor, entonces el revocador puede descifrar los datos de la transacción, lo que les permite vincular la transacción en cuestión con las transacciones anteriores hasta que la cadena de transacciones haya sido completamente desanonimizada.

Este sistema crea una serie de controles y equilibrios, en la medida en que los guardianes no pueden decidir unilateralmente revelar los datos de la transacción, e incluso si coluden, no pueden hacer nada sin el revocador, y el revocador solo no puede hacer nada con el voto mayoritario de los guardianes.

Railgun

RAILGUNes un sistema de privacidad de transacciones sigiloso implementado en Ethereum, BSC, Polygon y Arbitrum. El protocolo es similar en ciertos aspectos a Labyrinth en la medida en que se basa en notas, que se almacenan en un árbol de Merkle como compromisos y forman un conjunto de UTXO, es decir, las notas pueden ser gastadas creando nuevas notas para otros destinatarios. Para gastar una nota, se agrega un anulador al estado de esa nota, evitando gastos dobles. Solo el propietario de una nota puede calcular su anulador, que se basa en el hash de la clave de gasto y el índice de las notas en el árbol de Merkle, lo que significa que solo el propietario de la nota puede gastarla (y solo puede gastarla una vez).

Las direcciones meta furtivas en Railgun utilizan el prefijo "0zk", y al igual que eip-5564, es una concatenación de la clave de visualización pública y la clave de gasto público. Sin embargo, Railgun utiliza claves Ed25519 en la curva BabyJubJub en lugar de ECDSA y secp256k1. De la misma manera que eip-5564, los usuarios escanean todos los eventos emitidos por los contratos de Railgun y utilizan su clave de visualización para determinar qué eventos representan transferencias a su billetera.

Railgun utiliza una red de emisores, que son básicamente retransmisores que aceptan meta-transacciones de los usuarios y transmiten la transacción real a la cadena de bloques correspondiente, pagando las tarifas de gas en nombre del usuario. Las interacciones directas con los contratos de Railgun provienen de esta red de emisores, protegiendo el anonimato de los usuarios finales. Las transacciones que se envían de los usuarios a los emisores están encriptadas con la clave pública específica del emisor y se comunican utilizando Protocolo Waku.

Railgun tiene una arquitectura modular que le permite interactuar con contratos inteligentes externos, lo que permite funcionalidades más allá de simples transferencias. Lo hace a través del contrato AdaptRelay, que protege y desprotege los tokens antes y después de interactuar con un contrato externo, por ejemplo, desproteger el token A, intercambiarlo por el token B en algún AMM, y volver a proteger el token B para devolverlo al propietario original.

Con la versión 3, Railgun planea aprovechar eip-4337 y también admitir meta-transacciones heredadas. Esperan que al mantener un mempool de usuarioop eip-4337 dedicado para Railgun, los resolutores independientes puedan participar como emisores. Actualmente están colaborando con Umbra en la investigación de esto, identificando casos límite y cómo abordarlos, consulte la sección Railgun v3 a continuación para obtener más detalles.

Tarifas

El protocolo Railgun cobra una comisión del 0,25% por depósitos y retiros. Estas comisiones se envían al tesoro de DAO y se pagan a lo largo del tiempo a los poseedores del token de gobernanza RAIL. Además de la comisión del 0,25% por depósito y retiro, los difusores generalmente aplican su propia comisión, que suele ser aproximadamente el 10% de la tarifa de gas para la transacción real en la cadena.

Gobernanza

Railgun tiene un sistema de gobernanza que permite enviar cualquier tipo de propuesta, y no se pueden realizar cambios en ninguno de los contratos principales (incluidos los contratos de tesorería y gobernanza) sin una propuesta de DAO. De manera inusual, las diferentes instancias de Railgun tienen su propia gobernanza. Por ejemplo, Railgun en Ethereum, Polygon y Binance Chain tienen sus propios sistemas de gobernanza y tokens separados.

SDK y Cookbook

Railgun ofrece un SDK completo y bien documentado que los desarrolladores de billeteras o dapps pueden usar para incorporar la funcionalidad de direcciones ocultas a través del soporte de Railgun. Railgun también cuenta con una comunidad mantenida por usuarios.libro de cocinacon “recetas” que permiten a los desarrolladores de dapp proporcionar módulos para Railgun que permiten a los usuarios interactuar con su dapp usando Railgun. Por ejemplo, un desarrollador puede escribir una receta para un DEX que permite a los usuarios con saldos de tokens en Railgun intercambiar tokens de forma privada.

RailGun v3

La próxima iteración de Railgun hará que las transacciones sean aproximadamente un 50% - 60% más baratas. Los otros cambios en la versión 3 son el cambio a la compatibilidad con eip-4337 userops a través de un mempool dedicado. Además, v3 proporcionará soporte para una arquitectura basada en intenciones, que permitirá a los solvers competir por la mejor ejecución, aunque los detalles son muy generales en el momento de escribir esto. Actualmente están trabajando con CowSwapen esto y planeo usar ganchos previos y posteriores para permitir que los solucionadores accedan a los fondos.

Railgun Connect

Probablemente el cambio más interesante que se propone es algo llamado Railgun Connect, que se describe como una herramienta similar a WalletConnect, en el sentido de que permite que las direcciones 0zk se conecten a la mayoría de las interfaces para uso privado, sin requerir que esas dapps proporcionen específicamente una integración explícita con Railgun a través de módulos personalizados.

Railgun Connect es una extensión del navegador, y lo que hace en realidad es bifurcar el estado de la cadena localmente utilizando HardHat bajo el capó, e inyecta su propio proveedor web3 en la dapp, con un punto final RPC de la versión local de HardHat de la cadena. Esto le permite llevar a cabo las interacciones con los contratos de las dapp como lo haría normalmente, registra las transacciones, luego las agrupa y crea una prueba snark, y la envía a los contratos reales de Railgun en la cadena real. Si bien esta descripción es un poco simplificada, transmite la idea general. Lo que esto hace es permitirle interactuar básicamente con virtualmente cualquier dapp (con algunos casos particulares para dapps que realizan procesamiento extra fuera de la cadena). La advertencia es que guardar el estado de la cadena localmente es una operación pesada, pero una vez hecho, significa que puede interactuar con dapps usando las direcciones ocultas de Railgun sin ver ninguna diferencia con el uso de una billetera normal.

Conclusión

Hay algunas propuestas interesantes para consagrar las direcciones furtivas en el protocolo Ethereum. Por ejemplo, Incoutiliza la idea de un "envoltorio" erc-20, que envuelve un contrato erc-20 normal y encripta todos los saldos. Las transferencias y aprobaciones se realizan en el estado encriptado a través de cifrado completamente homomórfico. Inco depende de precompilaciones que actualmente solo existen en su propia red, pero algún día podrían llegar a Ethereum.

También hay otra propuesta llamadaEIP-7503: Agujeros de Gusanos de Conocimiento Ceroque se basa en un diseño llamado 'proof-of-burn', aunque esto no parece estar teniendo mucho impacto, probablemente porque requiere una actualización del EVM, sin la cual realmente solo se puede implementar a nivel de token, utilizando un diseño erc-20 que admite específicamente eip-7503 (o si un L2 decide agregar soporte a sus opcodes EVM).

Aztecaes quizás la tecnología de privacidad más sofisticada que existe, pero requiere que los usuarios transfieran fondos a Aztec para poder usarla, lo cual puede o no ser una experiencia de usuario inaceptable para la mayoría de los usuarios. Sin embargo, si la demanda de privacidad en las transacciones básicas crece entre los usuarios de Ethereum, entonces Aztec podría tener una propuesta de valor única que lo convierte en una capa 2 muy valiosa a medida que las dapps y los usuarios migren a una plataforma que les brinde privacidad por defecto.

Semejantemente Intmaxes un Ethereum L2 (basado en un diseño de Plasma) que se enfoca en la privacidad y también tiene un aspecto de cumplimiento normativo al verificar la legitimidad de los fondos individuales a través de pruebas de AML basadas en ZKP e imponer límites en los montos de las transacciones. Intmax tiene limitaciones en cuanto a proporcionar privacidad para las transferencias mientras que las operaciones de contratos inteligentes de EVM no son privadas. Sin embargo, a diferencia de Aztec, los contratos inteligentes se pueden escribir en Solidity, lo cual puede ser preferido por algunos desarrolladores (dependiendo del caso de uso).

Soporte de billetera

Si bien estamos viendo una mayor adopción de los protocolos de dirección oculta, lo cual es prometedor, aún existen varios desafíos. El desafío más importante es que aún no cuentan con un soporte completo en las billeteras principales de Ethereum (al menos por ahora). Las billeteras principales probablemente deberán tomar varias decisiones si van a brindar soporte para las direcciones ocultas. Algunas de estas decisiones incluyen:

• ¿Brindarán soporte parcializado para una sola implementación, o construirán y mantendrán una especie de agregador integral en varios protocolos? Lo último probablemente será prohibitivamente costoso en términos de desarrollo y mantenimiento.
• ¿Habrá consideraciones regulatorias, y necesitarán tomar una postura sobre el alcance y el mecanismo para la desanonimización selectiva (es decir, como la de Laberinto)?
• Las direcciones ocultas requieren un componente en cadena con respecto al contrato de registro (excepto Fluidkey), por lo que esto significa que cada red de EVM debe ser admitida explícitamente por la billetera (aunque el diseño de Umbra facilita la implementación sin permisos del registro).
• Las direcciones ocultas complican las integraciones existentes con exploradores de bloques (por ejemplo, Etherscan). Por ejemplo, el botón 'Ver en el explorador' no funcionará para una meta-dirección oculta, donde la billetera muestra el saldo agregado. Este problema también puede existir para transferencias. Será necesario considerar los diferentes casos especiales como este.
• Dependiendo de la implementación subyacente, un usuario solo podrá utilizar la dirección oculta de manera efectiva con un conjunto específico de dapps, es decir, aquellos que son compatibles con el protocolo subyacente. Esto será posible con arquitecturas modulares de direcciones ocultas. Sin embargo, no todas las dapps serán compatibles, y esto deberá comunicarse de alguna manera al usuario. Es algo más fácil con eip-5506, pero aún tiene sus complicaciones y casos especiales, y esto a menudo puede filtrarse a través de la UX de la billetera.

También hay margen para mejorar la higiene de la privacidad del usuario, consulte este documento: “Análisis de la Anonimidad del Esquema de Dirección Oculta Umbra en Ethereumpara mostrar cómo los autores pudieron desanonimizar con éxito el 48,5% de las transacciones encubiertas en la red principal de Ethereum. Las heurísticas que utilizaron para hacer esto no tenían nada que ver con los protocolos y se basan más en la higiene de la privacidad, por ejemplo, un usuario envía fondos a una dirección encubierta que controla y luego envía esos fondos de vuelta a la dirección desde la que los envió originalmente, pensando erróneamente que la trazabilidad se ha roto. En general, los autores identificaron 6 heurísticas diferentes que se pueden utilizar para desanonimizar transacciones de direcciones encubiertas, principalmente todas basadas en no seguir las mejores prácticas. Sin embargo, estos son problemas críticos de UX que deben abordarse.

En general, soy bastante optimista sobre las direcciones ocultas y la privacidad en Ethereum en general. Creo que hemos logrado un progreso bastante impresionante y descubierto algunos desafíos que se pueden solucionar fácilmente. Estoy seguro de que las carteras principales encontrarán la manera de brindar el nivel de soporte necesario para las direcciones ocultas, lo que permitirá a los usuarios utilizarlas con un mínimo de fricción y pensamiento, brindando el nivel normal de privacidad que los usuarios esperan y merecen.

¡Un gran reconocimiento a todos los equipos que han dedicado tiempo y esfuerzo en investigar y construir infraestructuras de direcciones ocultas, incluyendo los cuatro protocolos de los que he hablado en esta publicación. ¡Su arduo trabajo y tenacidad marcarán una gran diferencia para Ethereum!

Renuncia:

1. Este artículo es un reprin de [ Medio]. Todos los derechos de autor pertenecen al autor original [Simon Brown]. Si hay objeciones a esta reimpresión, por favor contactar a la Aprender Gateequipo y ellos lo resolverán rápidamente.
2. Renuncia de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. El equipo de gate Learn realiza traducciones del artículo a otros idiomas. A menos que se mencione, copiar, distribuir o plagiar los artículos traducidos está prohibido.