Privacidad en Ethereum – Dirección secreta (dirección de sigilo)

Fuente: Comunidad Denglian

introducir

Un punto importante que enfrenta los usuarios de cifrado de Web3 es la falta de privacidad.Todas las transacciones son visibles en los libros de contabilidad públicos y están cada vez más asociadas con un nombre de ENS claramente visible, lo que hace que los usuarios sean menos motivados al realizar ciertas actividades o los lleva a funcionar de una manera que aumente la fricción de la experiencia del usuario.Un ejemplo es simplemente transferir fondos de billeteras calientes a billeteras frías o viceversa.Es posible que los usuarios no quieran que una billetera esté conectada a otra porque no quieren que se vea su equilibrio de billetera en frío.Actualmente, las direcciones de Ethereum no funcionan como cuentas bancarias privadas, ya que todos pueden ver su billetera, y cada vez más, también se verán sus actividades sociales (SBT, pruebas, actividades en varios DAPPS, etc.).Debido a esto, Vitalik llama privacidad a lo que Ethereum debe atravesarUna de las tres principales transformaciones tecnológicas, para ser útiles para los usuarios comunes.

Utilizando soluciones de privacidad existentes como Tornado Cash, la experiencia no es ideal por varias razones.En primer lugar: los usuarios se preocuparán razonablemente que su dirección esté en la lista negra en intercambios centralizados u otras plataformas.En segundo lugar, la experiencia de usuario interactiva con servicios como Tornado Cash no es amigable y en realidad solo es adecuada para usuarios altamente calificados.

Las direcciones secretas proporcionan a los usuarios una privacidad similar a lo que dan por sentado en una cuenta bancaria privada y se implementan de una manera fácil de entender.Además, la innovación en torno a las direcciones ocultas significa que podemos hacer esto de una manera que cumpla con las regulaciones contra el lavado de dinero en múltiples jurisdicciones.

Necesidades de privacidad de los usuarios

Aunque la investigación sobre las actitudes de privacidad hacia la privacidad por parte de los usuarios de Web y Web3 no es extensa, los siguientes estudios se encontraron a través de búsquedas en la web, y los resultados son más o menos consistentes, lo que indica una clara necesidad de privacidad de transacciones.

1. Una encuesta realizada en 2022, publicada por Simin Ghesmati et al.Privacidad percibida por el usuario en blockchainEn el documento, se afirma queLa mitad de los encuestados dijo que la privacidad de la transacción es muy importante para ellos«

2. Otro estudio interesante vino de 2022, publicado enFronterasEl título esActitudes políticas, económicas y gubernamentales de los usuarios de blockchain, Este estudio es más completo, y se investigó un total de 3.710 usuarios de criptografía.Los resultados muestran que aproximadamente una cuarta parte de los encuestados dijeron que su privacidad era «La característica más importante en blockchain y criptomonedas«.

1. En términos de actitud general hacia la privacidad,ConsensoA publicadoWeb3 y Crypto Global Survey 2023, en la que una encuesta en línea de 15.158 personas de 15 países cubrió varios temas relacionados con la web, no solo el cifrado.La encuesta encontró que el 83% de los encuestados creía que la privacidad de los datos era importante, mientras que solo el 45% dijo que confía en el uso actual de sus datos e información personal por parte de los servicios de Internet.

2. Un esquema de compensación de servicios financieros del Reino Unidoinvestigación, publicado en abril de 2023, destacando que el 9% de los encuestados lo hará «Un deseo de anonimato/privacidad«Como la razón por la que invierten en criptomonedas.

Adopción de acuerdos de transacción secretos

FerrocarrilLos datos de uso son impresionantes, y el uso del protocolo parece haber crecido constantemente con el tiempo, alcanzando más de $ 70 millones en valor bloqueado total (TVL) y $ 2 mil millones en volumen de negociación a partir de noviembre de 2024.

TVL (USD) Railgun en la red principal de Ethereum – Fuente: RailGun – Desfillama

UmbríaEl número de usuarios también ha aumentado constantemente (el número de personas que registraron direcciones secretas a sus ENS), que se acercan a casi 77,000 a noviembre de 2024:

Umbra Número acumulativo de personas registradas (cadena cruzada)-Fuente: Dune.com

Si observamos el protocolo de privacidad más conocido (y ahora desafortunadamente notorio) en Ethereum, Cash Tornado, podemos ver que a pesar de que la dirección del contrato se incluye técnicamente en la lista SDN de OFAC, todavía se está utilizando en grandes cantidades.

La siguiente figura muestra el TVL de Cash Tornado con el tiempo.Podemos observar que desde el pico alrededor de octubre de 2021, la primera disminución importante en TVL coincidió con la venta general en el mercado de criptográficos, y la segunda disminución importante ocurrió en agosto de 2022, que coincidió con la lista de efectivo de tornados de OFAC en la lista SDN , la tercera disminución significativa corresponde a la rediseño de OFAC en noviembre de 2022.Sin embargo, a pesar de las sanciones, el uso de efectivo de Tornado ha estado creciendo constantemente desde entonces, con TVL acercándose a $ 600 millones.Este es un fuerte testimonio de la necesidad de privacidad de transacciones básicas en Ethereum.

TVL (USD) Tornado Cash en Ethereum Red principal – Fuente: Tornado Cash – Defillama

La situación actual de las direcciones ocultas

Este estudio identificó 4 soluciones principales producidas actualmente en la cadena EVM, que son:

• Fluida

• Umbría

• Laberinto

• Ferrocarril

Fluidkey y umbra se basan en los estándares de Ethereum, que son:

• ERC-5564: Acuerdo de dirección secreta

• ERC-6538: Registro de dirección de metal oculto

Labyrinth y Railgun se basan enprotocolo de zerocash(zcashTambién basado en esto), el protocolo utiliza un grupo de protección donde los usuarios depositan fondos.ZeroCash utiliza el concepto de «notas», que es básicamente una representación cifrada de valor, capaz de lograr transacciones privadas.Cada nota incluye un valor oculto, la clave del propietario y un número único (un invalidador), que utiliza ZK-Snarks para verificar la propiedad sin revelar detalles, transfiriendo así el valor en la nota.Cuando se gasta un proyecto de ley, se revela su invalidador para evitar el doble gasto, mientras crea nuevas facturas para el receptor, formando un sistema UTXO dentro del grupo de protección.

En un alto nivel, el principio básico de una dirección oculta es que un tercero puede enviar fondos a una dirección que nunca ha existido, y el destinatario previsto puede encontrar y controlar la dirección (es decir, los fondos se pueden gastar posteriormente).

El estándar ERC-5564 especifica un mecanismo en el que el receptor puede publicar una meta dirección oculta a partir de la cual se puede derivar una nueva dirección de Ethereum.Cualquier persona que desee enviar fondos al destinatario puede generar una nueva dirección de la dirección del elemento oculto y permitir que el destinatario aprenda sobre los fondos sin ninguna comunicación directa.Todas las direcciones ocultas se implementan en función de esta premisa básica.

¿Cómo funciona la dirección secreta?

La dirección del elemento secreto es esencialmente una conexión entre dos claves públicas comprimidas, llamada «clave de espensión» y la «clave de vista» respectivamente.La dirección secreta de Meta utiliza el formato de dirección específico de la cadena EIP-3770 y agrega el prefijo «ST:».Aquí hay un ejemplo de una dirección oculta:

ST: ETH: 0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c4644ba4a02c0521b6fe31714b2ca0efa159402574355b754e0b5t EC3507

Para simplificar, esta dirección secreta puede estar asociada con una dirección de Ethereum normal (y por lo tanto ENS), lo que facilita enviar fondos al propietario de la dirección secreta.Para enviar fondos, el remitente analiza la dirección anterior y utiliza el estándar EIP-5564 para crear una clave pública temporal a partir de la cual se deriva la dirección secreta.El remitente envía los fondos a una nueva dirección oculta, generalmente a través de un contrato de singleton donde el receptor de todas las direcciones ocultas escucha los eventos.El contrato emite un evento de «anuncio», al que el destinatario puede suscribirse.Cada vez que se emite un evento de anuncio, el destinatario verifica la clave pública temporal en el anuncio, la combina con su clave de vista privada para determinar si tienen la capacidad de gastar los fondos enviados a la dirección oculta.Si es así, la billetera/cliente que usan recordará la dirección oculta y los fondos correspondientes y los agregará al saldo mostrado del usuario.Para gastar estos fondos, pueden firmar la transacción utilizando una clave de gasto privado.

El siguiente cuadro describe todo el proceso más claramente:

Recuerde que este proceso es completamente no interactivo, lo que significa que no hay una comunicación directa entre el remitente y el receptor, lo que significa que en realidad no hay un vínculo entre el remitente y el receptor que un tercero puede observar.

Sin embargo, para que esto funcione correctamente, el receptor debe informar al remitente de su dirección secreta.Una forma de hacer esto es usarFormulario de registro de la dirección del elemento oculto EIP-6538.Este es un contrato de singleton que permite a los usuarios registrar una meta dirección secreta a una dirección de Ethereum normal, que el remitente puede buscar.Esto permite que el remitente analice la dirección normal de la ENS y luego busque las meta direcciones ocultas relevantes del registro.

El esquema rompe el vínculo entre el remitente y el receptor, lo que les permite evitar que todo el mundo conozca sus asuntos.Sin embargo, hay algunas cosas a tener en cuenta:

• Cuando el destinatario gasta los fondos, el objeto que transfieren los fondos verá que los fondos provienen del remitente original (es decir, pueden ver la dirección donde se transfieren los fondos y quién envió los fondos a esa dirección antes).Esto significa que las cadenas de transferencia permanecen intactas y rastreables, pero solo no están relacionadas con los destinatarios involucrados (a menos que el destinatario haga algo como enviar fondos a una dirección no oculta que se sabe).Tenga en cuenta que esto solo funciona con implementaciones ERC-5564 y no con RailGun o Labyrinth.

• Otro efecto secundario del problema anterior es que para mantener una privacidad óptima, los usuarios pueden necesitar mantener sus fondos en la dirección secreta a la que originalmente fueron enviados hasta que realmente los necesitan, en lugar de fusionarlos bajo una sola dirección.Esto representa la sobrecarga adicional de las direcciones de recordar y, posteriormente, el gasto de fondos en esas direcciones, ya que la cantidad que desea transferir debe tomarse de la cartera de fondos para varias otras direcciones.

• Para transferir fondos de esa dirección, el destinatario debe proporcionar un ETH a la dirección para pagar el gas, que puede desanonimizar al destinatario.Este es un problema conocido con las direcciones ocultas y una de las razones por las que muchas implementaciones admiten EIP-4337 y pagadores.

• Una desventaja del esquema de direcciones ocultas es que el receptor necesita monitorear la cadena de bloques para obteneranuncioy verifique cada anuncio para determinar si recibieron los fondos.Obviamente, esta es una sobrecarga poco realista para la mayoría de los usuarios, especialmente cuando reciben fondos de múltiples redes.Para que este proceso sea más eficiente, el estándar especifica una «etiqueta de vista», un hash truncado derivado de un secreto compartido que puede usarse para descartar rápidamente las transacciones que obviamente no están destinadas a ser enviadas a ellos.Al usar la etiqueta View, el rendimiento en el escritorio no es tan malo, pero puede ser más notable en los dispositivos móviles.El único momento en que la caída de rendimiento es realmente obvio es si la billetera se está recuperando, en cuyo caso la billetera necesita escanear cada dirección desde la implementación del contrato en la cadena, que requiere mucho tiempo.

• Para resolver este problema, los usuarios pueden optar por compartir una clave de visualización privada con un tercero de confianza.Este servicio de terceros puede monitorear una variedad de redes y notificar a los usuarios cuando reciben fondos.Por supuesto, esto trae una compensación: si bien los terceros no pueden gastar fondos de los usuarios (no tienen una clave de gasto privado), pueden ver todos los fondos enviados a un destinatario específico, lo que significa que los usuarios necesitan para confiar en su privacidad.Fluidkey hace esto por defecto.

• El protocolo de dirección secreta estándar, a saber, ERC-5564, está diseñado para facilitar la transferencia de protección de la privacidad, sin embargo, los casos de uso no financieros (como llamar a funciones de contratos inteligentes arbitrarios) requieren más ingeniería, a menudo específicas de la implementación.

Matriz de comparación

Podemos comparar las cuatro implementaciones de dirección ocultas discutidas en este artículo de varias maneras.Todas las implementaciones tienen diferencias y compensaciones sutiles, pero quizás el punto más importante es el borde de la trazabilidad y el valor.

Si bien tanto Fluidkey como Umbra permiten que los fondos se transfieran a las direcciones de Ethereum estándar mientras rompen cualquier enlace a la identidad del destinatario, aún conservan la trazabilidad de las transacciones, lo que significa que el remitente estará en contra de cualquier persona que verifique el historial de transacciones de la dirección secreta, es visible .Esto significa que si recibe fondos en una dirección oculta, la persona a la que decide enviar estos fondos verá de dónde son.Además, el valor real de la transferencia también es visible.RailGun y Labyrinth ocultan el remitente y el valor del remitente, pero a costa de esto, todo ocurre dentro de un solo contrato en lugar de una transacción normal a una dirección de Ethereum normal.

La siguiente figura muestra la comparación mutua de los protocolos que discutimos en este artículo sobre estas dos importantes dimensiones comparativas.

Para explorar estas diferencias con más detalle, aquí están la matriz de comparación de los cuatro principales protocolos de dirección oculta en seis dimensiones principales:

1. Completa de privacidad de extremo a extremo (solo remitente y receptor Ver información de pago)

2. Confidencialidad hacia adelante.Los fondos recibidos a través de las transacciones de ocultación no permiten que un segundo destinatario vea la fuente de los fondos

3. Siga los estándares ERC-5564 y ERC-6538

4. Implementa una arquitectura modular escalable que permite la integración con DAPP de terceros

5. ¿La implementación proporciona un SDK que los desarrolladores pueden usar para integrar?

6. ¿La solución proporciona cumplimiento de algún tipo de soporte de desanimización?

7. ¿El diseño admite la ofuscación de la cantidad/valor transferido?

La siguiente sección captura algunos otros matices y diferencias con más detalle.Cada implementación tiene matices interesantes, que pueden o no afectar su caso de uso.

Por ejemplo: en fluidkey: todas las transacciones se transfieren directamente a la dirección oculta en la cadena, mientras que Umbra **: ** solo ETH se transfiere a la dirección oculta en la cadena, y los tokens se transfieren al contrato central como el contrato. Labyrinth, todas las transacciones son transferidas al contrato central, en lugar de directamente a la dirección oculta en la cadena.

Discusión en profundidad sobre la implementación de direcciones ocultas

Fluida

Fluidaes una implementación de ERC-5564 que permite a los usuarios enviar, recibir, intercambiar y puente tokens ETH y ERC-20.Al momento de escribir, Fluidkey se ha desplegado en la base, el optimismo, el árbitro, el polígono, la gnosis y los mainets de Ethereum.

Los usuarios interactúan con FluidKey a través de su interfaz de usuario web.Cuando inician sesión por primera vez con su billetera, firman un mensaje de generación de claves desde el cual deducen 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.

Fluidkey tiene varias formas diferentes a otras implementaciones.Una de las diferencias es que los usuarios comparten su clave de visualización privada con fluidkey (en realidad unaBip-32Derive nodo).Esto permite a FluidKey generar direcciones ocultas para los usuarios y notificar a los usuarios cuando reciben el pago de esas direcciones.Sin embargo, esto también significa que Fluidkey tiene la capacidad de ver las transacciones y equilibrios de ganancias de los usuarios, lo cual es una compensación.Sin embargo, Fluidkey sigue siendo completamente autocustody.

Otro aspecto interesante del diseño de Fluidkey es que implementa una cuenta de contrato inteligente para cada nueva dirección oculta.Esto solo sucede cuando se utilizan fondos financiados por direcciones autoconcebradas.La cuenta inteligente es una cuenta segura 1/1 que permite operaciones como el patrocinio de gas, lo que facilita la gestión de diversas direcciones ocultas.Para obtener más información sobre esto, consulte suExplicación técnica.

Si bien Fluidkey retiene la visibilidad de las cuentas de los usuarios, esto puede ser una ventaja en el cumplimiento, aunque no se ha revelado el marco exacto sobre cómo FluidKey manejará posibles solicitudes futuras de aplicación de la ley.Están ubicados en Suiza y, a pesar de las leyes locales, las leyes de protección de datos son muy claras y poderosas: debe haber razones muy claras para compartir datos, y el asunto será revisado por el tribunal (Ver este artículoAprenda sobre una buena descripción de las leyes de privacidad suiza).

Los usuarios también pueden exportar completamente sus transacciones, o compartir sus claves de visualización con terceros, como contadores, que es especialmente útil para las empresas.Vale la pena señalar que, de acuerdo con la especificación ERC-5564, el intercambio de claves públicas es «todo o nada», lo que significa que no puede revelar transacciones individuales huérfanas solo.Además, como todas las implementaciones ERC-5564, la trazabilidad no está rota, solo la correlación con el usuario, lo que significa que el historial de transacciones de cada dirección oculta está disponible públicamente para aquellos que tienen la clave de visualización.Una característica menos conocida de FluidKey es la capacidad de rotar las claves de vista, lo que permitirá a los usuarios usar una nueva clave de vista por mes y compartir el acceso de vista para un mes específico con terceros solamente.

Una ventaja del método fluidkey es que la dirección oculta en sí no es generada por el remitente, sino que es generada pseudo aleatoriamente por Fluidkey cada vez que consulta ENS.Esto es más rápido porque los usuarios no tienen que escanear a través del evento de anuncio para identificar transacciones que son 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, solo necesitan enviar fondos como otras direcciones.Esto también significa que no hay contrato de registro involucrado, lo cual es único y una gran ventaja del diseño de Fluidkey.

Vale la pena mencionar que Fluidkey está comprometido con el autocontrol, y han abierto su biblioteca de kits de cuentas ocultos y, poco probable, Fluidkey desaparece durante la noche, hay varias recuperaciones de desarrollo independientes disponibles. estar bloqueado o atascado.

Abstracción de dirección

Al usar cuentas de contrato inteligentes, FluidKey puede administrar automáticamente las direcciones ocultas individuales.Esto significa que si desea transferir una cantidad específica de su saldo en cada dirección oculta a un destinatario específico, FluidKey puede calcular automáticamente la combinación de dirección utilizada para transferir fondos, manejando todas las tarifas de gas y las implementaciones de contratos, todo lo cual procede en segundo plano .Fluidkey también permite a los usuarios pasar unEtiquetaLa característica fría de la dirección a combinar permite a los usuarios marcar la dirección como categorías diferentes.

Análisis ENS

Fluidkey requiere que los usuarios creen un nombre ENS exclusivo de Fluidkey.Estos nombres estáticos vienen en dos formas: username.fkey.id y username.fkey.eth, uno es la URL a la interfaz web que envía fondos a alguien, y el otro es el nombre ENS estándar que se puede usar con la billetera.

Uso de configuración de ENSResolución de la cadena de ENS(también conocido comoERC-3668: READ CCIP) para devolver la dirección oculta.Cada vez que se consulta el resolución fuera de línea, genera y devuelve una nueva dirección oculta para el nombre de ENS correspondiente.Esta es una gran característica porque permite al usuario tener un solo nombre de ENS legible por el humano y al mismo tiempo conserva la privacidad de la dirección oculta, porque la dirección oculta generada no se remonta al nombre de ENS.

costo

Fluidkey es de uso gratuito y no hay carga.Cuando desea gastar dinero, cada dirección con fondos debe implementar una tarifa de contrato segura.Sin embargo, a pesar de ser relativamente costoso en la red principal, esto es realmente trivial en L2, generalmente menos de 1 centavo, incluso si múltiples direcciones ocultas se combinan en una sola transferencia.

También pueden hacer patrocinio de gas a través de implementaciones seguras (calculan la tarifa de gas y la deducen del saldo del usuario, incluso si se trata de un token, en cuyo caso el reenviador implementa seguras y transfiere tokens en nombre del usuario.

Umbra efectivo

UmbríaSíScopeliftImplementado EIP-5564 + EIP6538.Cuando los usuarios inician sesión en la aplicación Umbra, pasan por una fase de configuración en la que firman un mensaje desde el cual obtienen gastos y ven las claves y las meta direcciones de ocultación correspondientes.Luego registran esta meta dirección oculta en el registro en cadena de su dirección de billetera principal.Esta es la diferencia entre implementación y fluidkey.

La implementación de UMBRA de ERC-5564 es más cercana a la especificación porque no pueden acceder a la clave del usuario.Si bien esto significa que Umbra (o cualquier otra persona) no puede ver los fondos del usuario, sí significa que para recibir fondos, el remitente debe tener una billetera compatible con ERC-5564 (o aplicación Umbra) para generar su dirección oculta.

Cuando alguien quiereenviarCuando se dan fondos a los usuarios, generalmente usan la aplicación Umbra para completarla.Básicamente, la aplicación Umbra busca el meta-dirección oculta registrada en el nombre de la billetera de ENS y genera una dirección oculta.Los destinatarios pueden iniciar sesión en la aplicación Umbra y escanear para obtener los fondos enviados a su dirección oculta desde el último inicio de sesión.Gracias a un caché inteligente, esto parece tomar solo 10-15 segundos para escaneos semanales, aunque los usuarios también pueden optar por especificar un rango de bloque para reducir el escaneo.Umbra V2 incluirá el uso de etiquetas de vista, que acelerarán aún más el proceso.

Aposter

Uno de los problemas con la dirección oculta que mencionamos anteriormente es que para que el destinatario gaste los fondos enviados a la dirección oculta, la dirección debe tener ETH u otros tokens de gas necesarios para pagar la tarifa de transacción.En la mayoría de las redes, esto generalmente no es un problema si la dirección oculta inicialmente recibe ETH.Sin embargo, si se recibe un token o NFT ERC-20 por una dirección oculta, el acto de proporcionar gas a la dirección con ETH puede asociar esa dirección con otras direcciones del usuario, perdiendo así la privacidad.

Para evitar este problema, Umbra utilizó un involucradoAposterestructura.Cuando se envía un activo que no es de ETH a un usuario de Umbra, en realidad se envía a un contrato especial, en lugar de directamente a una dirección oculta.Los usuarios pueden gastar fondos enviados a su dirección oculta enviando metatransacciones (desde la aplicación Umbra) a los reenviados de Umbra, que transferirán fondos del contrato inteligente en nombre del usuario.El reenviador deducirá algunas fichas para cubrir el costo de las tarifas de gas e inicialmente solo respalda un cierto número de tokens.

costo

Los contratos de Umbra también cobran tarifas pequeñas cuando se transfieren fondos en redes con bajas tarifas de transacción para frenar el spam.La razón es que el spam aumenta el costo de las transacciones de escaneo para identificar transacciones relacionadas, por lo que esto se considera una compensación aceptable.

Redes compatibles

Umbra se implementa actualmente en el Ethereum Mainnet, así como el optimismo, el polígono, la cadena de gnosis y el árbitro.

El contrato de registro de Umbra tiene diseños interesantes.El método de implementación utiliza los implementadores Create2 y Standard Create2, y la dirección de contrato inteligente es la misma en cualquier red.Esto significa que si el contrato existe en una red determinada, el cliente puede asegurarse de que este sea el contrato correcto.Los clientes se pueden configurar para agregar redes, y cualquiera puede implementar en cualquier red.Han normalizado el Bytecode, y el contrato no tiene propietario, lo que permite a cualquier persona implementar contratos de registro y anuncio sin permiso en ninguna cadena.

UMBRA V2

Scopelift está actualmente en desarrolloLa segunda edición de Umbra, Esta versión introduce una nueva arquitectura modular que permite que las extensiones de contratos centrales admitan nuevos estándares de token o casos de uso de no pago.Con esta nueva arquitectura, los desarrolladores de terceros pueden construir módulos para cualquier tipo de estándares de tokens, como ERC-1155, ERC-7621, pagadores habilitados para ERC-4337, o cualquier otra cosa que se le ocurra.Actualmente, Umbra Core Contract admite dos escenarios, uno para ETH y el otro para ERC-20.V2 admitirá muchos escenarios diferentes.

Laberinto

Laberintoes un protocolo que no se basa en EIP-5564 + EIP6538, pero usa una prueba de conocimiento cero para agregar el anonimato y la privacidad a las transacciones.El libro blanco de Labyrinth lo describe como el «middleware» Zkfi «:»ZKFI proporciona una solución de empaque que actúa como un middleware de privacidad con cumplimiento incorporado«.

Los contratos inteligentes centrales utilizados por Labyrinth incluyen un grupo de transacciones múltiples y múltiples activos que permite a los usuarios intercambiar múltiples activos en una sola transacción.Para gastar activos, los usuarios escanean la red y obtengan datos de notas encriptadas, descifraran las notas y filtren los activos que desean gastar.Luego, el usuario crea un ZKP que incluye las claves de firma para la transacción y las notas asociadas con las transacciones que desea gastar.

Parte del contrato de Labyrinth Core incluye un contrato de conversión que se interactúa con contratos de representación modulares que esencialmente representan contratos externos.Entonces, por ejemplo: si el usuario desea interactuar con UNISWAP usando Labyrinth, el usuario construirá una transacción que invocará la operación de intercambio en el grupo de UNISWAP utilizando el contrato de conversión a través del contrato de proxy de UNISWAP.

El protocolo ZKFI de Labyrinth utiliza «notas» para rastrear saldos y transferencias.Un proyecto de ley es esencialmente una estructura de datos que describe un cierto número de activos y su dirección a la que pertenecen.El cliente almacena la información necesaria para reconstruir las notas y utiliza esta información para gastar activos.El compromiso con las notas (hash de ID de activo, propietario y valor) se almacena en el árbol de Merkel en la cadena.De hecho, Labyrinth usa dos árboles Merkel, uno para el boleto y otro para la dirección raíz.

La estructura de datos de la nota contiene lo siguiente:

• activo: El identificador del activo representado por esta nota (ETH, WBTC, Matic, etc.).

• valor: El valor o la cantidad representada por las notas.

• hojas de hojas: Esta nota se insertará en el índice del nodo de hoja de la promesa de Merkel Tree.

• cegador: Un factor de protección aleatorio.

• raíz: La dirección raíz del usuario con permiso de gastos.

• revocador: El punto clave público de laonorda seleccionada.

Notará que la estructura de datos anterior no contiene activosdueñoCualquier referencia a esto es extraña porque las promesas registradas en las notas Merkel Tree son la identificación de activos, el valor ydueñohash de.De hecho, el propietario se calcula a partir de la dirección raíz, el revocador y el factor de protección aleatorio, por lo que para los observadores externos, el propietario es en realidad una nueva dirección generada por cada nueva transacción.

Piscina de protección

Con respecto a Labyrinth, es particularmente interesante que sea ligeramente diferente del protocolo tradicional basado en direcciones ocultas, y el grupo de activos es en realidad un grupo de protección que utiliza las notas para crear un grupo de utxo protegido, proporcionando así un primero para las transacciones. .Recuerde que en la implementación EIP-5564, el objeto de transferencia del usuario podrá ver la fuente de estos fondos.En otras palabras, Alice le paga a Bob una dirección secreta, y Bob le paga a Charlie, por lo que Charlie ahora puede ver que Bob recibe los fondos de Alice inicialmente, y así sucesivamente.Este no es el caso con el grupo de protección de Labyrinth.

Para comprender cómo funciona este grupo de protección, necesitamos ver cómo se transfieren los fondos dentro del protocolo:

El saldo del usuario en el grupo de protección es la suma de las notas de los activos correspondientes.Para gastar estas notas, los usuarios deben revelar el «logotipo inválido» de esas notas.Un logotipo no válido está relacionado de manera única con una nota, y una vez que se gasta la nota, el logotipo no válido está marcado para evitar el doble de consumo y crear una nueva nota basada en la nota gastada.Se pueden fusionar múltiples notas para el mismo activo, y se pueden crear múltiples notas nuevas.Un identificador no válido es un hash de (?,?,?), ¿Dónde es el índice del compromiso en el árbol de Merkel?

Los destinatarios de las transferencias de transacciones secretas identifican la transferencia de la misma manera que EIP-5564, porque escuchan los eventos enviados desde el contrato central y determinan la dirección secreta a partir de la cual podrán enviar fondos y grabar esas direcciones localmente.La velocidad de identificar fondos entrantes también se ha mejorado aprovechando las etiquetas de vista y el caché asincrónico y las notas sincrónicas durante todo el ciclo de vida de la aplicación.

Actualmente se está investigando para acelerar el proceso de descubrimiento de recepción de fondos y echar un vistazo a esta propuesta de AZTEC:Solicitud de propuestas: Protocolo de descubrimiento de notas – AZTEC.

En términos de gasto de dinero, los usuarios también tienen que generar una prueba de ZK, que es diferente de la implementación ERC-6654 que es básicamente una dirección de Ethereum normal.Generar una prueba requiere una billetera compatible con un rendimiento relativamente bueno, y lleva unos 20 segundos en dispositivos Android de rango medio.

Packers and Converters

Labyrinth proporciona algunas buenas características que pueden resolver algunos puntos de dolor en las transacciones secretas.Las transacciones enviadas al contrato de Labyrinth Core se envían como operaciones de usuario a través del Packager ERC-4337.Esta configuración permite el gasto de notas sin la necesidad de tokens de gas ETH o transaccionales, ya que los usuarios pueden usar pagadores ERC-4337 para pagar gas por ellos, agregando una capa adicional de privacidad.La única excepción es el depósito inicial, que no se presenta como una acción del usuario.Otro beneficio de usar pagadores ERC-4337 es la capacidad de pagar el gas a través de los activos transferidos, incluso si son tokens ERC-20, por lo que el laberinto expone una API de precio de gas de gas.

Otra muy buena característica del laberinto es su arquitectura modular que permiteConvertidorLos contratos sirven como agentes para aplicaciones descentralizadas de terceros.Esto no solo permite a los usuarios transferir fondos utilizando transacciones ocultas, sino que también interactúa con aplicaciones descentralizadas de terceros (como DEX como UNISWAP, AAVE, LIDO, etc.).Estos agentesConvertidor«El contrato esencialmente implementa una función que recibe una cierta cantidad de activos y genera algunos activos. La lógica básica existe en un contrato de terceros.

Soluciones de cumplimiento

Labyrinth garantiza el cumplimiento y el cumplimiento regulatorio a través de un marco llamado desanimización selectiva (SEDE).

Recuerde que la estructura de datos de la nota contiene un campo llamado «Undoer».El Revoker es la dirección de una entidad específica que puede iniciar el proceso de desanimización.El usuario debe seleccionar al menos un revocador de la lista predefinida.El Revoker no es el único responsable de identificar posibles actividades ilegales o inapropiadas, sino que puede responder a las solicitudes de las agencias de aplicación de la ley.

El Revoker no tiene la capacidad de desanonimizar las transacciones directamente, pero son responsables de iniciar solicitudes de desanonimio.Estas solicitudes se publican públicamente a The Guardian, un comité sustantivo que monitorea la privacidad y el cumplimiento.The Guardian debe votar para decidir si permitir transacciones de desanimización.Si The Guardian puede alcanzar el quórum y votar por él, el Revoker puede descifrar los datos de la transacción, vinculando así la transacción relevante con la transacción anterior hasta que la cadena de transacciones sea completamente declética.

Este sistema crea una serie de cheques y equilibrios porque los guardianes no pueden decidir revelar datos de transacciones solo, e incluso si coluden, no pueden hacer nada sin el revocador, y el revocador solo no puede hacerlo con la mayoría de los votos guardianes solo. .

Ferrocarril

FerrocarrilEs un sistema de privacidad de transacción secreto implementado en Ethereum, Binance Smart Chain, Polygon y Arbitrum.El protocolo es similar en algunos aspectos al laberinto porque se basa ennotas, estas notas se almacenan como promesas en el árbol de Merkel, formando un conjunto UTXO, es decir, creando nuevas notas para que otros destinatarios gaste.Esto significa que solo el propietario de la nota puede calcular su identidad inválida, que a menudo se genera en función del hash de la clave de gastos y el índice de la nota en el árbol de Merkel.

Las meta direcciones ocultas en RailGun usan el prefijo de «0zk», similar a EIP-5564, que es una combinación de claves de visualización pública y claves de gasto público.Sin embargo, RailGun usa la tecla ED25519 en la curva BabyJubjub en lugar de ECDSA y SECP256K1.Al igual que EIP-5564, los usuarios escanean todos los eventos emitidos en el contrato de RailGun y usan su clave de vista para determinar qué eventos representan transferencias a su billetera.

Railgun utiliza unLocutorRed, estos emisores son realmente relés que reciben las metatransacciones del usuario y transmiten las transacciones reales a la cadena de bloques correspondiente para pagar las tarifas de gas en nombre del usuario.Las transacciones de los usuarios a los emisoras están encriptadas y utilizadasAcuerdo de WakuRealice la comunicación para proteger el anonimato de los usuarios finales.

RailGun adopta una arquitectura modular que le permite interactuar con contratos inteligentes externos, proporcionando funcionalidad más allá de las transferencias simples.PasaAdaptableEl contrato logra esto, que protege y desprotecta los tokens antes y después de interactuar con un contrato externo, por ejemplo, token A, intercambia token B en un AMM y protege el token B de regreso al propietario original.

En la versión 3, RailGun planea aprovechar EIP-4337 y admite metatransacciones tradicionales.Esperan permitir que los solucionadores independientes participen como emisoras manteniendo un grupo de memoria de usuario EIP-4337 dedicado para RailGun.Actualmente están trabajando con Umbra en este tema e identifican casos de borde y cómo resolverlos, consulte la sección RailGun V3 a continuación para obtener más detalles.

costo

El Acuerdo RailGun cobra una tarifa de 0.25% por depósitos y retiros.Estas tarifas se enviarán al almacén DAO, que se pagará con el tiempo a las partes interesadas de los tokens de gobierno ferroviario.Además de las tarifas de depósito y retiro del 0.25%, los emisores generalmente cobran sus propias tarifas, que generalmente son aproximadamente el 10% de las tarifas de gas para las transacciones reales en la cadena.

Gobernancia

RailGun tiene un sistema de gobierno que permite la presentación de cualquier forma de propuesta, y cualquier cambio en los contratos centrales, incluidos los contratos fiscales y de gobierno, debe realizarse con una propuesta DAO.Inusualmente, diferentes casos de ferrocarriles tienen su propia gobernanza.Por ejemplo, RailGun tiene sus propios sistemas de gobernanza independientes y fichas en la cadena Ethereum, Polygon y Binance.

SDK y libro de cocina

Railgun proporciona un SDK integral y bien documentado que los desarrolladores de billetera o DAPP pueden usar para construir funcionalidad de direcciones ocultas a través del soporte para RailGun.Railgun también tiene una comunidad mantenidalibro de cocina, proporciona una «receta» que permite a los desarrolladores de DAPP proporcionar módulos para RailGun, lo que permite a los usuarios interactuar con sus DAPP utilizando RailGun.Por ejemplo, un desarrollador podría escribir una receta para DEX para que los usuarios con saldos de tokens en Railgun puedan intercambiar tokens en privado.

RailGun V3

La próxima iteración de RailGun reducirá los costos de transacción en un 50% a 60%.Otros cambios en la versión 3 son soporte para usuarios de EIP-4337, implementados a través de un grupo de memoria dedicado.Además, V3 admitirá arquitecturas basadas en la intención que permiten a los solucionistas competir por la mejor ejecución, aunque los detalles siguen siendo muy alto a partir de la escritura.Actualmente están trabajando conCavaTrabajando juntos, planea usar ganchos delanteros y traseros para permitir que los solucionadores accedan a fondos.

RailGun Connect

Podría decirse que el cambio más interesante en la propuesta es una herramienta llamada RailGun Connect, que es similar a WalletConnect, lo que permite conectar las direcciones 0ZK a la mayoría de los front-dend para uso privado sin estos DAPPS proporcionando explícitamente la integración con RailGun a través de módulos personalizados.

Railgun Connect es una extensión del navegador que realmente utiliza el estado del Hardhat localmente para replicar el estado de la cadena e inyectar su propio proveedor Web3 en el DAPP, con un punto final RPC con una cadena de versiones de Hardhat local.Esto le permite interactuar con un contrato de DAPP como de costumbre, registrar las transacciones, luego lote y crear una prueba de snark y enviarlo al contrato de FerrokGun en la cadena real.Aunque esta descripción es un poco más simple, transmite la idea general.Esto le permite interactuar con casi cualquier DAPP (puede haber algunos casos de borde para DAPPS que requieren un procesamiento extra fuera de enlace).Cabe señalar que el estado de la cadena de guardado local es una operación que consume recursos, pero una vez que se completa, puede usar la dirección oculta de Railgun para interactuar con el DAPP sin ninguna diferencia al usar una billetera normal.

en conclusión

Hay algunas propuestas interesantes para establecer direcciones ocultas en el protocolo Ethereum.Por ejemplo,IncoSe utiliza el concepto de un «envoltorio» ERC-20, que encapsula un contrato ERC-20 normal y cifra todos los saldos.Las transferencias y las aprobaciones se realizan en estado cifrado a través del cifrado totalmente homomórfico.Inco se basa en precompiladores que actualmente existen solo en su propia red, pero pueden pasar a Ethereum en el futuro.

Hay otra propuesta llamadaEIP-7503: Hombos de gusano de conocimiento cero, que se basa en un diseño llamado «Prueba de quema», aunque esta propuesta no parece haber recibido mucha atención, probablemente porque requiere una actualización para el EVM, sin esta actualización, solo se puede implementar a nivel de token, Use un diseño ERC-20 que admita específicamente EIP-7503 (o si un L2 decide agregar soporte para su código de operación EVM).

aztecaProbablemente la tecnología de privacidad más compleja en este momento, pero requiere que los usuarios cierren fondos a AZTEC para usar, lo que puede no ser aceptable para la mayoría de los usuarios.Sin embargo, si la demanda de los usuarios de Ethereum de privacidad de transacciones básicas crece, AZTEC puede tener una propuesta de valor única para convertirse en un L2 muy valioso a medida que DAPPS y los usuarios migran a una plataforma que proporciona privacidad de manera predeterminada.

mismo,IntmaxEs un Ethereum L2 centrado en la privacidad (basado en el diseño de plasma), que también tiene un aspecto regulatorio de cumplimiento, verificando la legitimidad de los fondos individuales a través de ZKP basado en AML e imponer restricciones a las cantidades de transacciones.Intmax tiene restricciones para proporcionar privacidad para transferencias de dinero, mientras que las operaciones de contratos Smart Smart no tienen privacidad.Sin embargo, a diferencia de AZTEC, los contratos inteligentes se pueden escribir en solidez, que algunos desarrolladores pueden preferir (dependiendo del caso de uso).

Soporte de billetera

Si bien estamos viendo un aumento en la adopción de protocolos de direcciones ocultas, lo cual es una señal positiva, todavía hay muchos desafíos.El desafío más importante es que no son totalmente compatibles en las billeteras Ethereum convencionales (al menos aún no).Es posible que las billeteras convencionales deban tomar varias decisiones al proporcionar soporte para las direcciones ocultas.Estas opciones incluyen:

• ¿Proporcionarán soporte de defensa para una sola implementación, o construirán y mantendrán algún tipo de agregador integral en múltiples protocolos?Este último puede ser costoso en términos de desarrollo y mantenimiento.

• ¿Habrá consideraciones regulatorias y debemos tomar una posición sobre el alcance y el mecanismo de desanimación selectiva (como el caso del laberinto)?

• Las direcciones ocultas requieren un componente en la cadena, a través de un contrato de registro (excepto Fluidkey), lo que significa que cada red EVM debe ser compatible explícitamente por la billetera (aunque el diseño de Umbra facilita el despliegue sin permiso del registro).

• Las direcciones ocultas hacen que la integración existente con detectores de bloques, como Etherscan sea más complejo.Por ejemplo, la vista sobre el botón Detector no funcionará para ocultar meta direcciones porque la billetera muestra saldos agregados.Este problema también puede existir en la transferencia.Estos casos marginales deben considerarse cuidadosamente.

• Según la implementación subyacente, los usuarios solo pueden usar direcciones ocultas de manera efectiva con un conjunto específico de DAPPS, es decir, aquellos DAPP admitidos por el protocolo subyacente.La arquitectura de dirección de ocultación modular hará esto posible.Sin embargo, no todos los DAPP serán compatibles y los usuarios deben ser notificados de alguna manera.Esto es relativamente fácil cuando se usa EIP-5506, pero todavía hay casos de complejidad y borde que pueden penetrar en la experiencia del usuario de su billetera.

Hay margen de mejora en la prevención de una mala privacidad e higiene del usuario, consulte este artículo:Análisis de anonimato del esquema de direcciones de sigilo Umbra en Ethereum«, El autor Deanonymous 48.5% de las transacciones de sigilo en el Ethereum Mainnet. La dirección de envío inicial, creyendo incorrectamente que la trazabilidad se ha roto. ser abordado.

En general, soy bastante optimista sobre las direcciones invisibles y la privacidad en Ethereum.Creo que hicimos un progreso bastante impresionante y encontramos algunos desafíos muy remediables.Creo que las billeteras convencionales encontrarán formas de proporcionar soporte de dirección invisible para que los usuarios puedan usar fácilmente estas direcciones y disfrutar del nivel normal de privacidad que los usuarios esperan y merecen.

Gracias a todos los equipos que han invertido su tiempo y trabajo duro para investigar y construir infraestructura de dirección invisible, incluidos los cuatro protocolos que mencioné en esta publicación.¡Sus esfuerzos y tenacidad tendrán un gran impacto en Ethereum!