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.
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.
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
Esta investigación ha identificado 4 soluciones principales para las cadenas EVM en producción hasta la fecha, las cuales son:
Tanto Fluidkey como Umbra se basan en los estándares de Ethereum, que son:
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.
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:
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:
| 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.
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.
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.
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:
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.
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.
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:
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!
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.
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.
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
Esta investigación ha identificado 4 soluciones principales para las cadenas EVM en producción hasta la fecha, las cuales son:
Tanto Fluidkey como Umbra se basan en los estándares de Ethereum, que son:
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.
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:
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:
| 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.
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.
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.
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:
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.
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.
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:
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!