EIP-7503: Agujeros de gusano de conocimiento cero para transacciones privadas de Ethereum

EIP-7503: Zero-Knowledge Wormholes es una propuesta de mejora de Ethereum (EIP) que introduce un mecanismo para realizar transferencias que preserven la privacidad en Ethereum. Si bien hemos visto muchos esfuerzos para hacer que las transferencias dentro de la cadena sean privadas, incluidos los mezcladores de criptomonedas como Tornado Cash, EIP-7503 es una solución de capa de protocolo que hace que Ethereum sea privado de manera predeterminada .

Esta es una consideración importante: los enfoques de privacidad de la capa de aplicación como Tornado Cash son de “inclusión voluntaria”, lo que a menudo tiene implicaciones negativas para los usuarios. Las aplicaciones centradas en la privacidad también son más susceptibles a la censura; por ejemplo, muchos usuarios (especialmente ciudadanos estadounidenses) no han podido interactuar con Tornado Cash después de que la Oficina de Control de Activos Extranjeros (OFAC) incluyera en la lista negra las direcciones de contrato del protocolo en 2022 .

A pesar de las sanciones de la OFAC, Tornado Cash sigue funcionando por varias razones:

1. Los contratos principales que implementan la funcionalidad de mezcla de activos de Tornado Cash son inmutables y se almacenan permanentemente en la cadena. tornado.cash El sitio web se desconectó, los proyectos independientes han reutilizado el código de contrato de la implementación original de Tornado Cash para crear nuevas variantes como Tornado Cash Nova .
2. El protocolo Tornado Cash es en su mayor parte “ingobernable”. El equipo fundador de Tornado Cash eliminó los controles administrativos después ejecutando una actualización de emergencia para reparar un error que habría permitido a los atacantes crear pruebas válidas de depósitos falsos y drenar fondos (depositados legítimamente). Por lo tanto, el equipo fundador no podía activar unilateralmente un interruptor de seguridad y verse presionado para "apagar" el protocolo a pesar de sus arresto en 2023 .

Los factores antes mencionados significan que la gente todavía puede usar Tornado Cash hoy, incluso si los análisis sugieren que los productores de bloques en Ethereum están abandonando las transacciones que interactúan con los contratos del protocolo . Sin embargo, al igual que en los días previos a las sanciones de la OFAC, no todas las transacciones enrutadas a través del protocolo mezclador de Tornado Cash han sido legítimas. Para ilustrarlo, un artículo de Arkham Intelligence sugiere que al menos dos ataques de alto perfil en 2023 (el exploit de $ 197 millones de Euler Finance y el robo de $ 60 millones de Anubis DAO) fueron financiados por fondos retirados de Tornado Cash, o utilizaron el mezclador para blanquear fondos robados y ocultar transferencias salientes.

Dado que Tornado Cash no ha resuelto el problema de los actores maliciosos que abusan de la privacidad en la cadena, ¿por qué querríamos implementar una función para realizar transferencias privadas a nivel de protocolo? ¿No es eso riesgoso ? ¿Por qué es necesario tener transacciones privadas en primer lugar? ¿No son las cadenas de bloques como Ethereum ya anónimas e "imposibles de rastrear"?

Todas estas son preguntas legítimas, que analizaremos en este artículo. Ofreceremos una descripción general de la importancia de la privacidad financiera y exploraremos por qué las cadenas de bloques públicas como Ethereum no pueden garantizar la privacidad sin realizar cambios. Luego, analizaremos el enfoque de EIP-7503 para permitir pagos privados en Ethereum y analizaremos las posibles ventajas y desventajas de adoptar EIP-7503.

¡Vamos a sumergirnos!

Preparando el escenario: ¿Por qué debería importarnos la privacidad en la cadena?

Cuando hablamos de “transacciones privadas” o “transacciones anónimas” en el contexto de los pagos electrónicos entre pares (P2P), describimos dos cualidades: imposibilidad de rastrear e imposibilidad de vincular . Ambas cualidades están descritas por Nicolas van Saberhagen en el informe técnico de CryptoNote :

• Imposibilidad de rastrear : una transacción es imposible de rastrear si un observador externo no puede identificar de manera confiable al remitente. Supongamos que Alice es amiga de Bob y Carol y Alice recibe dos tokens a través de una transferencia; la imposibilidad de rastrear significa que nadie puede saber quién (Bob o Carol) envió los tokens a Alice.

• No vinculable : una transacción no se puede vincular si un observador externo no puede identificar de forma fiable al destinatario. Si Bob y Carol envían tokens a Alice en transacciones separadas, la no vinculabilidad significa que nadie puede saber si Bob y Carol enviaron tokens a la misma persona.

  
  

La mayoría de las soluciones de privacidad en cadena (si no todas) se pueden clasificar en función de los requisitos antes mencionados que satisfacen. Los mezcladores de criptomonedas , CoinJoin y las firmas de anillo se ocupan principalmente de ocultar información sobre las direcciones de envío y hacer que los fondos sean imposibles de rastrear. La identidad del remitente se protege mediante diferentes mecanismos, pero cualquiera puede ver quién recibió los fondos.

En comparación, los protocolos centrados en la privacidad como Monero , Zcash , Liquid Network y Aztec v1 ofrecen variantes de transacciones "protegidas" o "confidenciales" y garantizan la imposibilidad de vincular las transacciones. Una transacción protegida o confidencial es difícil de vincular a un destinatario específico porque los detalles de la dirección del destinatario (así como la cantidad y el tipo de token transferido) se mantienen en secreto. Las direcciones ocultas son otro enfoque para preservar la imposibilidad de vincular: los usuarios generan una dirección efímera (de corta duración) para un depósito, lo que bloquea los intentos de vincular dos transferencias a la misma dirección.

Los enfoques antes mencionados para mejorar la privacidad de las transacciones tienen fortalezas y debilidades únicas, que exploraremos brevemente más adelante. Pero, por ahora, centraremos nuestra atención en una pregunta fundamental: "¿Por qué es importante la privacidad financiera?" Dado que estamos dedicando tiempo y esfuerzo a analizar una propuesta para llevar transacciones privadas y anónimas a Ethereum, también podríamos exponer la lógica para habilitar la privacidad de las transacciones en Ethereum.

La privacidad financiera es importante porque la privacidad es un derecho humano básico . El derecho a la privacidad confiere a cada individuo el poder de decidir qué información desea compartir públicamente y conservar el control de cómo, cuándo y dónde se comparte la información de identificación personal (PII). La “información de identificación personal” es una categoría amplia que incluye cualquier información que pueda usarse para descubrir la identidad de un individuo, incluidos los detalles de las actividades financieras (por ejemplo, historial de compras, transferencias electrónicas y ganancias).

A continuación se presentan algunos ejemplos de cómo las personas pueden ejercer sus derechos a la privacidad (financiera):

• Comprar anticonceptivos por Internet sin que tu familia te pregunte por qué no quieres aumentar el número de personas en el Día de Acción de Gracias del año que viene. Imagina que los bancos divulgaran información sobre las transacciones por Internet para que la abuela Beth supiera que Cheryl la estaba privando activamente de tener nietos. ¿Qué tan incómodas serían las cosas?
• Donar a una organización benéfica sin revelar detalles de cuánto donaste o si donaste algo. Esto es importante si estás donando a una causa benéfica que aún puede generar dudas en ciertos círculos, o si odias hacer una actuación y atraer atención (innecesaria) hacia tus actividades filantrópicas.
• Donar a una causa política con la que no quieres que se te asocie públicamente. Tomemos como ejemplo el caso de Vitalik Buterin (originario de Rusia), que donó a las fuerzas ucranianas que luchan contra la invasión rusa. Dada la nacionalidad de Vitalik, una donación pública probablemente habría desencadenado una crisis de relaciones públicas innecesaria, por lo que los fondos se enviaron a través de Tornado Cash .
• Realizar pagos sin revelar detalles de su situación financiera a personas malintencionadas. No quiere que alguien sepa que ganó $X en ingresos brutos el año pasado, lo que le da suficiente información para crear un plan para robar ese dinero (por ejemplo, mediante estafas y otras tácticas de ingeniería social).
• Pagar a los empleados sin revelar información sobre sus ingresos. Tal vez prefiera mantener en privado los detalles de las actividades financieras de su empresa o sus empleados quieran mantener esa información en privado.

Estos ejemplos ofrecen casos prácticos de uso de la privacidad financiera, pero también ponen de relieve un detalle que los críticos de los derechos a la privacidad a menudo no reconocen: la privacidad no es algo que creamos que necesitamos hasta que es demasiado tarde. La respuesta habitual de “¿qué estás ocultando?” no reconoce ciertas situaciones en las que las partes involucradas desean filtrar poca o ninguna información sobre una transacción financiera. E incluso si las personas quisieran ocultar cosas por razones arbitrarias, ¿por qué molestarse, siempre que su deseo de secreto no ponga en peligro la salud y la seguridad públicas?

Es mejor tener y no necesitar que necesitar y no tener. — Franz Kafka

Solución al problema de privacidad de Ethereum con EIP-7503

Contrariamente a las primeras descripciones de los defensores y los críticos, las cadenas de bloques públicas como Ethereum y Bitcoin están lejos de ser anónimas o privadas. Estos dos términos suelen confundirse, pero significan dos cosas diferentes:

• La privacidad significa que sus acciones secretas pueden rastrearse hasta su identidad pública, pero los detalles de sus acciones están ocultos. Supongamos que envía un correo electrónico cifrado mediante una herramienta PGP ( Pretty Good Privacy ): los servidores de correo saben que envió un correo electrónico a otra parte (identificable), pero no pueden leer el contenido del correo electrónico. Esta es una acción secreta porque nadie más sabe que envió un correo electrónico, excepto el destinatario.

• El anonimato significa que sus acciones públicas están desvinculadas de su identidad pública. Para utilizar el ejemplo anterior: un hipotético servicio de correo electrónico anónimo peer-to-peer podría ocultar el origen y el destino de un correo electrónico cifrado, al tiempo que mantiene un registro público de todos los correos electrónicos enviados a través de la red. Esta es una acción pública, ya que el registro de alguien que envía un correo electrónico es visible para todos los participantes de la red, pero las direcciones de correo electrónico son cadenas hash ( 0xdeadbeef ) y no nombres ( [email protected] ).

  
  

Ethereum no es privado porque la cadena de bloques mantiene un registro de cada transacción, que incluye cuánto se transfirió y qué acciones en la cadena ejecutó la transacción. Ethereum tampoco es anónimo, porque la información sobre las cuentas que realizan transacciones en la cadena de bloques (identificadas por direcciones ) es pública. No puedes usar un nombre real como "Alice Hopkins" para tu cuenta de Ethereum, pero usar la misma dirección para cada transacción permite que la investigación forense de la cadena de bloques correlacione las transacciones con tu identidad en el mundo real, utilizando técnicas como el monitoreo de direcciones IP , la agrupación de direcciones y el análisis de gráficos .

Por lo tanto, Ethereum se describe con precisión como un sistema seudónimo que no puede garantizar el anonimato ni la privacidad, lo cual es malo para una plataforma que se espera que se convierta en la capa de liquidación para la futura Internet del Valor. Para ponerlo en contexto, los bancos ya brindan cierto nivel de privacidad a los usuarios al almacenar datos financieros en bases de datos centralizadas con estrictos mecanismos de control de acceso para evitar el acceso no autorizado.

Se trata de una “pseudoprivacidad”, ya que el banco y el proveedor de la infraestructura de la base de datos tienen acceso a esta información y pueden hacer lo que quieran con ella (por ejemplo, congelar los pagos a determinados países para cumplir con las sanciones basadas en el análisis del destino de una transferencia). Pero en un caso clásico de “elegir entre el diablo y el mar azul profundo”, es probable que el individuo medio elija algo de privacidad en lugar de ninguna privacidad, lo que descarta la posibilidad de abrir una cuenta de Ethereum y que todas las acciones dentro de la cadena sean visibles para el mundo.

Muchos han reconocido este problema, especialmente porque aleja a los usuarios de las tecnologías descentralizadas como Ethereum y los lleva a soluciones centralizadas que ofrecen garantías de privacidad ligeramente mejores a expensas de la resistencia a la censura y la transparencia (entre otras). Por ejemplo, The Three Transitions de Vitalik ofrece un gran argumento sobre la importancia de la privacidad para las perspectivas de adopción masiva de Ethereum:

Sin el tercero [una transición a transferencias que preserven la privacidad], Ethereum fracasa porque tener todas las transacciones (y POAP, etc.) disponibles públicamente para que literalmente cualquiera las vea es un sacrificio de privacidad demasiado alto para muchos usuarios, y todos pasan a soluciones centralizadas que al menos ocultan un poco sus datos. — Vitalik Buterin

La EIP-7503 es un esfuerzo por remediar algunos de los problemas descritos anteriormente, en particular la falta de anonimato para los remitentes de transacciones. La propuesta introduce un medio para que las direcciones destruyan deliberadamente Ether (ETH) enviando fondos a una dirección que no se puede gastar y generen una prueba ZK-SNARK para autenticar un depósito en la dirección que no se puede gastar. Si esta prueba pasa la verificación, se acuña una cantidad de tokens ETH (igual al saldo de la dirección que no se puede gastar) en una nueva dirección elegida por el usuario, rompiendo el vínculo entre las direcciones de envío y recepción involucradas en la transferencia de fondos.

La EIP-7503 toma prestadas ideas de los protocolos de privacidad existentes para impulsar transacciones que preserven la privacidad en Ethereum. Por ejemplo, la propuesta dificulta el seguimiento de los fondos recibidos en una transacción de acuñación hasta una fuente particular al convertir todo el conjunto de direcciones de Ethereum con un saldo de ETH y transacciones salientes cero en un conjunto de anonimato . No se puede identificar fácilmente la dirección A responsable de quemar el ETH que la dirección B volvió a acuñar en la siguiente transacción: A podría ser una de los millones de direcciones que tienen un saldo distinto de cero pero que no han iniciado una transacción de Ethereum.

Esto es similar a la idea de mezclar fondos de diferentes fuentes en un solo fondo y permitir que los depositantes retiren fondos del fondo usando una dirección diferente. Sin embargo, EIP-7503 se compara favorablemente con los mezcladores de criptomonedas como Tornado Cash porque proporciona una negación plausible . La negación plausible es un concepto que exploraremos más adelante, pero todo lo que necesita saber por ahora es que le permite a usted (un usuario que realiza una transferencia privada EIP-7503) negar haber realizado alguna vez una transacción privada.

La negación plausible es una característica importante de EIP-7503 que impide que los observadores externos desanonimicen a los remitentes de transacciones privadas. Esto puede evitar que se repita el fiasco de Tornado Cash, en el que ciertas direcciones fueron incluidas en la lista negra y se les restringió el acceso a dapps, exchanges y protocolos DeFi porque los análisis forenses en cadena revelaron interacciones históricas con Tornado Cash, incluso si algunas de esas cuentas habían interactuado con Tornado Cash por razones benignas (por ejemplo, hacer donaciones privadas).

EIP-7503 también toma elementos de otros protocolos centrados en la privacidad como Zcash y Aztec v1 al usar pruebas criptográficas para validar transacciones sin exponer los detalles de las mismas. Validar transacciones de una manera que preserve la privacidad garantiza que Ethereum pueda admitir transferencias privadas de manera segura sin socavar el modelo de seguridad existente que depende de la red distribuida de nodos que reejecutan cada transacción para confirmar su corrección. Exploraremos los detalles de cómo EIP-7503 usa ZK-SNARKs bajo el capó para admitir la ejecución segura de transferencias privadas en Ethereum en secciones posteriores (entre otras cosas).

Advertencia *: A pesar de distinguir entre privacidad y anonimato, utilizaré “privado” y “anónimo” indistintamente a lo largo de este artículo para simplificar las cosas y evitar confusiones para los lectores acostumbrados a pensar en los dos conceptos como uno solo. Además, la EIP-7503 incluye elementos de anonimato (romper los vínculos entre remitentes y destinatarios) y privacidad (una extensión propuesta a la propuesta actual permitirá a los usuarios ocultar los montos de depósito y retiro).*

Una descripción general de EIP-7503: agujeros de gusano de conocimiento cero

A un alto nivel, EIP-7503 funciona de la siguiente manera:

1. Los usuarios “queman” ETH enviándolo a una dirección cuyo saldo no se puede gastar

Una dirección no se puede gastar si nadie tiene acceso a la clave privada necesaria para firmar una transacción (válida) que gaste dinero del saldo. Esto es similar a enviar fondos a la dirección cero : la cuenta no tiene clave privada, lo que hace que cualquier activo que reciba sea irrevocable o “quemado”.

La dirección cero es la cuenta más rica de Ethereum, con más de 280 millones de dólares en tokens. A excepción de unos pocos usuarios desafortunados que envían fondos a la dirección cero por accidente, la gran mayoría de los usuarios que envían tokens a la dirección cero crean un contrato (que requiere establecer la dirección cero como receptor) o retiran esos tokens de circulación a propósito.

El estándar de token ERC-20 original no especifica funciones para reducir el suministro de un token, lo que significa que los tokens más antiguos como WETH (Wrapped Ether) no tienen forma de garantizar que los usuarios saquen los activos envueltos de la circulación antes de retirar el depósito original. Sin embargo, enviar tokens WETH a la dirección cero los hace inutilizables y simula una reducción en el suministro circulante de WETH cada vez que se retira ETH del contrato de envoltura WETH. Si se pregunta cómo WETH mantiene una relación 1:1 con ETH nativo, aquí tiene la respuesta.

La EIP-7503 utiliza un mecanismo similar para permitir a los usuarios quemar ETH y acuñar tokens en una dirección diferente en Ethereum con un pequeño cambio. En lugar de pedirles a los usuarios que envíen fondos a una única dirección de quema, la EIP-7503 requiere que los usuarios generen una dirección de quema única para cada transacción antes de acuñar ETH en otra dirección.

2. Los usuarios crean una prueba de quema privada o "recibo de quema" que demuestra que quemaron cierta cantidad de ETH en una transacción anterior enviándola a una dirección de quema.

Enviar fondos a una dirección de correo electrónico (creada según la especificación EIP-7503) es el equivalente a arrojar dinero en efectivo a un agujero de gusano: nunca se puede recuperar. Pero se puede demostrar que se tiene conocimiento de algo que se envió al agujero de gusano utilizando un ZK -SNARK ( argumento sucinto de conocimiento cero); de ahí el término "agujeros de gusano de conocimiento cero".

La prueba de quema es privada porque un usuario solo tiene que demostrar que envió tokens a una dirección A que no se puede gastar sin revelar A en texto plano. Generar una prueba de quema requiere demostrar que la dirección de quema es realmente ingastable. ¿Por qué? Pedir a los usuarios que quemen ETH nativo antes de acuñar nuevos tokens ETH en la dirección del destinatario garantiza la paridad (en valor y fungibilidad) de ambos tipos de activos; si los usuarios pueden retirar fondos más tarde de la dirección de quema, la vinculación 1:1 entre ETH nativo y tokens ETH acuñados dejaría de existir.

3. Los usuarios acuñan tokens ETH enviando una prueba de quema privada a un nodo completo que acredita al usuario una cantidad equivalente al depósito transferido a la dirección de quema.

EIP-7503 introduce un nuevo tipo de transacción en la EVM (Máquina Virtual Ethereum) que acepta una prueba de quema y un destinatario como entradas y genera nuevos tokens ETH en la dirección de envío si la prueba se verifica correctamente. Para evitar la generación de ETH dos veces para la misma transacción de quema, se adjunta un valor "anulador" especial a cada prueba de quema para rastrear el uso de la dirección.

Si el ETH enviado a una dirección que no se puede gastar se vuelve a acuñar correctamente, el anulador evita que un usuario deshonesto genere una nueva prueba de quema válida para los fondos enviados previamente a la dirección (es decir, ataques de doble acuñación). Es importante destacar que el anulador identifica una dirección usada sin filtrar información sobre la dirección en texto sin formato.

Con esa introducción de alto nivel, ahora podemos adentrarnos en los detalles de bajo nivel de la implementación de EIP-7503. En las siguientes secciones se analizarán los detalles clave de la implementación de EIP-7503, como:

• Generación de la dirección no utilizable
• Generación de pruebas de quema privadas
• Verificación de pruebas privadas de quema
• Acuñación de ETH para destinatarios de transferencias privadas

Generando la dirección no utilizable

Una dirección Ethereum normal son los primeros 20 bytes del hash Keccak256 de la clave pública generada a partir de la clave privada de la cuenta (la clave privada es un número entero generado a partir de una frase mnemotécnica o semilla). Tanto las claves privadas como las claves públicas se generan utilizando el algoritmo de firma digital de curva elíptica (ECDSA). El ECDSA es un tema complejo ("complejo" es mi eufemismo preferido para "tiene muchas matemáticas"), pero aquí hay algunos recursos, clasificados desde principiantes hasta expertos en el tema:

• Una introducción (relativamente fácil de entender) a la criptografía de curva elíptica (Blog de Cloudflare)
• Algoritmo de firma digital de curva elíptica (Wikipedia)
• Algoritmo de firma digital de curva elíptica (Wiki de Bitcoin)
• ECDSA: Firmas de curvas elípticas (Criptografía práctica para desarrolladores)

La clave pública se obtiene multiplicando la clave privada (llamada secreta o s para abreviar) por un valor “generador” especial G para producir un nuevo valor con la forma pubKey = privKey * G . La dirección se genera ejecutando la clave pública a través de la función hash Keccak256 y tomando los primeros 20 bytes de la cadena hash. En notación pseudomatemática, la operación se ve así: A = K(s * G) , donde A es la dirección, s es la clave secreta o privada y G es el punto generador en la curva elíptica.

La dirección, la clave pública y la clave privada sirven para propósitos muy diferentes:

• La dirección se comparte públicamente e identifica la cuenta que recibe los fondos transferidos en una transacción.
• La clave privada se utiliza para firmar un mensaje que indica a la red que transfiera tokens del saldo de una dirección y debe mantenerse en secreto.
• La clave pública permite verificar que la firma de una transacción fue generada por la clave privada correspondiente.

El último elemento de la lista apunta a un detalle sutil: solo es posible gastar fondos enviados a una dirección si usted controla la clave privada, es decir, si conoce la clave privada que se utilizó para generar la clave pública, de la que se derivó la dirección. Si no conoce la clave privada de una dirección, o si la clave privada está controlada por otra persona, no puede gastar fondos desde esa dirección.

¿Cómo sabemos si el saldo de una dirección A no se puede gastar? Podemos empezar eligiendo aleatoriamente un valor aleatorio de 20 bytes para A y aprovechando una propiedad especial de las funciones hash criptográficas conocida como resistencia de preimagen . En términos simples, la resistencia de preimagen significa que no podemos encontrar un valor x tal que H(x) (el hash de x ) sea el mismo que A si A se eligió aleatoriamente. En notación pseudomatemática, esta afirmación tiene la forma: H(x) ≠ A .

A es la imagen del hash (la salida de la función hash) y x es la preimagen de la función hash (la entrada a la función hash). Encontrar el valor de x para H(x) = A es difícil debido a (a) la gran cantidad de números enteros posibles (b) la forma en que una función hash manipula las entradas para producir una salida. Por lo tanto, la única forma en que puede "adivinar" un valor para x que resulte en A es si tiene una enorme cantidad de poder de cómputo y suficiente tiempo libre para realizar una enorme cantidad de cálculos para encontrar H(x) = A

Si bien esta no es una clase de Criptografía 101, la explicación anterior captura una propiedad clave de los sistemas de criptografía modernos. La propiedad de resistencia a la preimagen de las funciones hash también juega un papel clave en EIP-7503: si A es un valor aleatorio de 20 bytes, tenemos una confianza razonable de que un usuario no puede derivar la clave privada s no tiene forma de gastar fondos desde la dirección. Es decir, es imposible calcular A = H(h(s * G) , donde A es la dirección de grabación, s es la clave privada o secreta y G es el punto generador (nota pequeña: k(s * G) es equivalente a x del párrafo anterior).

Pero esta estrategia no es completamente infalible. Por ejemplo, ¿cómo podemos determinar que A es realmente aleatorio y no es el resultado de calcular s * G ? Si un usuario elige A de forma independiente, necesitamos confiar en el usuario o crear procedimientos complejos para verificar que A fue elegido aleatoriamente; si elegimos A , no necesitamos confiar en un usuario, pero existe una probabilidad nada despreciable de que alguien tenga suerte y adivine correctamente x . Dado que x = s * G , este conocimiento puede permitir al usuario derivar la clave privada s y gastar desde la dirección supuestamente no gastable.

Obviamente, esto no es óptimo y resalta la necesidad de un mecanismo más seguro para generar direcciones que no se puedan gastar. Afortunadamente, las funciones hash criptográficas tienen otra propiedad que podemos aprovechar: la resistencia a colisiones . En términos simples, la resistencia a colisiones significa que no se puede encontrar H(x) = H(y) , donde x e y son entradas diferentes; es decir, el cálculo de hashes para diferentes valores de entrada no puede "colisionar" y producir el mismo resultado.

La resistencia a colisiones es importante para prevenir la falsificación (entre otras cosas): dos personas que hacen hash con dos entradas diferentes siempre tendrán cadenas hash diferentes y una no puede afirmar que posee la entrada que solo conoce la otra persona. Otra versión de la resistencia a colisiones es que no se puede encontrar H1(x) = H2(x) , donde H1 y H2 pertenecen a familias diferentes de funciones hash. En otras palabras, el cálculo del hash de x utilizando algoritmos hash diferentes no puede "colisionar" y llegar al mismo resultado.

Para entender por qué esto es posible, inventaremos un ejemplo artificial para explicar a continuación cómo funcionan las funciones hash.

Interludio: Funciones hash criptográficas para novatos

Usaremos un ejemplo artificial para explicar cómo funcionan las funciones hash criptográficas y cómo se garantizan propiedades importantes como la resistencia a colisiones y la resistencia a ataques de preimagen . Sin embargo, esta explicación simplifica en exceso ciertos conceptos en aras de la brevedad y la accesibilidad (lea un artículo sobre funciones hash si aspira a ser criptógrafo):

Alice, Bob, Cheryl y Max pertenecen a partidos políticos rivales: Alice y Bob son miembros del Partido Azul, mientras que Cheryl y Max pertenecen al Partido Rojo. Los partidarios incondicionales del Partido Azul y del Partido Rojo quieren compartir información entre ellos sin filtrar detalles confidenciales a los miembros del partido rival y crean de forma independiente diferentes códigos para cifrar los mensajes.

El código de Blue Party se conoce como algoritmo de doble letra, mientras que Red Party utiliza una variante llamada algoritmo de triple letra. El código es muy simple: reemplazamos las letras por números cuando escribimos mensajes: cada número en la cadena del mensaje se refiere a una letra en una posición particular del alfabeto. El bit de "cifrado" proviene de la forma en que elegimos los números para representar los alfabetos:

• En el código de “Doble Letra” de Blue Party, dividimos cada número por dos y usamos el número resultante (n) para encontrar la letra en la posición n del alfabeto. Por ejemplo, podemos cifrar “BOY” como 4-30-50 : 4/2 = 2 (“B” es la 2.ª letra del alfabeto); 30/2 = 15 (“O” es la 15.ª letra del alfabeto); 50/2 es 25 (“Y” es la 25.ª letra del alfabeto).
• En el código de “Triple Letra” de Red Party, dividimos cada número por tres y usamos el número resultante (n) para encontrar la letra en la posición n del alfabeto. Por ejemplo, podemos cifrar “BOY” como 6-45-=75 : 6/3 = 2 (“B” es la 2.ª letra del alfabeto); 45/3 = 15 (“O” es la 15.ª letra del alfabeto); 75/3 = 25 (“Y” es la 25.ª letra del alfabeto).

Este ejemplo utiliza cifrado para el mismo mensaje, pero podemos esperar que los miembros del Partido Azul y del Partido Rojo intercambien mensajes diferentes en la práctica (por ejemplo, “Max es un idiota” (Alice → Bob) y “Los miembros del Partido Azul son perdedores” (Cheryl → Max), etc.). Sin embargo, cifrar el mismo mensaje con códigos diferentes es útil para explicar la resistencia a colisiones en las funciones hash criptográficas:

Cuando se cifra “BOY” utilizando el algoritmo de “Doble Letra” del Partido Azul y el algoritmo de “Triple Letra” del Partido Rojo, los resultados son muy diferentes ( 4-30-50 y 6-45-75 , respectivamente). Un miembro del Partido Azul no puede generar 6-45-75 , a menos que utilice el algoritmo de cifrado del Partido Rojo; tampoco puede un miembro del Partido Rojo producir 4-30-50 como cadena de mensajes, a menos que utilice el algoritmo de cifrado del Partido Azul. Dado que cada partido guarda los detalles del algoritmo de cifrado, sabemos que un miembro del partido rival no puede descifrar un mensaje que no estaba destinado a él.

Las funciones hash criptográficas son diferentes de los algoritmos de cifrado: las funciones hash son unidireccionales y no tienen forma de derivar las entradas de la salida, mientras que los algoritmos de cifrado como los del ejemplo tienen una clave para descifrar las entradas de la función de cifrado. Pero las funciones hash y los algoritmos de cifrado tienen similitudes, especialmente en el área de resistencia a colisiones. Al igual que no pudimos encontrar la misma salida (un mensaje cifrado) para una sola entrada utilizando diferentes algoritmos de cifrado, no podemos encontrar la misma salida (un hash) para una sola entrada utilizando diferentes funciones hash.

Podemos explotar la resistencia a colisiones de las funciones hash para generar direcciones demostrablemente no gastables para quemar activos como lo requiere EIP-7503. Primero, pedimos a los usuarios que elijan un valor secreto s (la clave privada para una cuenta Ethereum), calculen el hash Keccak256 de s * G para derivar la clave pública y realicen un hash de la clave pública para derivar una dirección A. Luego, le pedimos al usuario que genere una nueva dirección B mediante el hash del valor secreto s con una función hash diferente denotada como H y tomando los primeros 20 bytes de la salida como la dirección.

¿Nuestro objetivo? Queremos terminar con K(x) ≠ H(x) , donde K representa la función hash Keccak256 y H representa una función hash de una familia diferente de funciones hash. Por razones de rendimiento, queremos que H sea “compatible con ZK” (es decir, verificar el resultado de H(x) dentro de un circuito debería ser barato y rápido).

No podemos conocer la clave pública de B porque la dirección se generó aleatoriamente en lugar de calcular el hash Keccak256 de s * G (clave privada multiplicada por el generador), lo que significa que la clave privada de B también es incognoscible. Si no conocemos la clave privada de B , no podemos producir firmas válidas para un mensaje que gasta el saldo de B. Con un proceso demostrablemente aleatorio para generar direcciones que no se pueden gastar, ahora tenemos una forma para que los usuarios quemen ETH antes de volver a acuñar activos.

Generando la prueba de quema privada

¿Cómo demostramos que un usuario en particular envió ETH a una dirección que no se puede gastar y que la dirección que no se puede gastar fue creada por ese usuario? La primera comprobación es necesaria para evitar la acuñación fraudulenta de ETH (no acuñamos nuevos tokens ETH a menos que tengamos pruebas de que un usuario ha quemado ETH anteriormente), pero la segunda comprobación también es importante: necesitamos saber que el usuario creó una dirección; de lo contrario, requeriríamos un dato (por ejemplo, el hash de la transacción de quema) para confirmar que un usuario no está tratando de reclamar el depósito de otra persona.

Dado que queremos evitar filtrar información sobre la participación de un usuario en el protocolo de privacidad, permitimos que los usuarios creen una prueba de conocimiento cero que demuestre el conocimiento de s (el valor secreto codificado para derivar la dirección de grabación) sin publicar s públicamente. La prueba de conocimiento cero afirma el conocimiento del usuario de una dirección B que se deriva del resultado de H(s) : dado que s se eligió en secreto, otra persona no puede calcular un valor diferente H(x) tal que H(s) = H(s) . Esto se debe a la propiedad de resistencia a colisiones de las funciones hash descrita anteriormente.

Ocultar s evita que actores maliciosos canjeen el depósito de un usuario al enviar una prueba que confirme el conocimiento del secreto s (usado para generar una dirección que no se puede gastar) al verificador EIP-7503. Esta sección pasa por alto por qué podemos crear una prueba de conocimiento cero que demuestra que H(s) = A sin requerir que el verificador calcule H(s) de forma independiente. Pero puedes leer Programas aritméticos cuadráticos de Vitalik: de cero a héroe y mi artículo sobre ZK-EVM para obtener algunos antecedentes sobre el uso de ZK-SNARK para demostrar la validez de un cálculo sin revelar las entradas.

Describimos la prueba de conocimiento cero que valida la transferencia de fondos de un usuario a una dirección que no se puede gastar (también conocida como dirección de quema ) como una "prueba de quema" o "recibo de quema". La prueba de quema prueba las siguientes afirmaciones:

• El usuario conoce una dirección A y el valor secreto s que se ha codificado para obtener A (es decir, H(s) = A ). Esto verifica que la dirección no se pueda gastar al confirmar que A es el resultado de codificar s con una función hash (compatible con ZK) diferente de la función hash Keccak256 utilizada para generar direcciones Ethereum que se puedan gastar.

• La dirección A tiene un saldo positivo de ETH igual o mayor que b ( b ≥ b' ). Esto verifica que la cantidad que un usuario intenta enviar a la dirección receptora sea la misma que la cantidad depositada en la dirección que no se puede gastar.

  
  

Si bien probar el punto 1 es relativamente sencillo, probar el punto 2 requiere afirmar ciertas cosas sobre el estado de Ethereum. En particular, debemos probar que (a) la dirección que no se puede gastar existe en el trie de estado canónico de Ethereum y (b) el saldo declarado de la dirección que no se puede gastar coincide con el saldo asociado con la dirección en el trie de estado. Esto requiere pasar una prueba de Merkle para la dirección A como entrada al circuito que genera la prueba de quema.

La prueba de Merkle consiste en las hojas del trie Patricia de Merkle (MPT) necesarias para calcular la ruta desde la hoja que estamos intentando probar (la dirección A ) hasta la raíz del trie de Merkle (la raíz del trie también es parte de la prueba de Merkle). Necesitamos evidencia de que la raíz de estado (que se utiliza para verificar la prueba de Merkle) también es canónica, por lo que requerimos que el usuario pase un encabezado de bloque B como una entrada adicional al circuito. Este conjunto de información permite que un verificador con recursos limitados verifique de manera eficiente la inclusión de la dirección A en el trie de estado y valide el balance b de A.

Nota *: La especificación EIP-7503 recomienda derivar la prueba de Merkle necesaria para demostrar la inclusión de la dirección de grabación en el trie de estado y validar el saldo de la dirección a través del método JSON-RPC eth_getProof introducido en EIP-1186 .

Generando anuladores para direcciones

Otra entrada al circuito ZK-SNARK que genera una prueba de depósito en una dirección que no se puede gastar es un anulador . El anulador es un valor que evita que un usuario use la misma prueba de quema para acuñar ETH dos veces . Sin un anulador, nada impide que un usuario inteligente reutilice una prueba de quema para retirar ETH varias veces: desde la perspectiva de un nodo que procesa transferencias privadas EIP-7503, estos retiros son válidos porque el saldo de la dirección que no se puede gastar nunca se reduce (solo puede aumentar).

El anulador se pasa como entrada al circuito de prueba ZK-SNARK para que una prueba de quemado se vuelva inválida una vez verificada con éxito. Logramos esta propiedad extrayendo el anulador (usado) de una prueba y almacenándolo en un árbol Merkle disperso (SMT). A diferencia de los árboles Merkle regulares que pueden probar de manera eficiente la inclusión de elementos, los árboles Merkle dispersos son eficientes para probar la no inclusión de elementos. Una discusión sobre los SMT está fuera del alcance, pero el artículo vinculado anteriormente proporciona una excelente descripción general para los lectores interesados.

Un SMT es útil en este caso porque el procedimiento de verificación ZK-SNARK solo tiene que verificar que el SMT excluya el anulador adjunto a una prueba recién enviada. Si el anulador no está presente en el árbol de Merkle disperso, sabemos que el usuario no ha utilizado esta prueba de quema anteriormente y está retirando un depósito comprobablemente nuevo . Agregamos el anulador utilizado al SMT para realizar un seguimiento de la dirección de quema utilizada para volver a acuñar ETH sin exponer públicamente la dirección de quema.

¿Qué pasaría si simplemente almacenáramos direcciones de quema en un árbol Merkle y verificáramos que la dirección de una nueva prueba de quema no sea parte del árbol al procesar un nuevo retiro?

El uso de la dirección de quema simple como un anulador permite a los observadores externos exponer potencialmente al remitente de una transacción de quema al cotejar el historial de transacciones de la dirección con la lista de direcciones de quema almacenadas en la cadena. Una vez que la dirección de quema (inevitablemente) aparece como receptor en una de las transacciones iniciadas por el remitente, cualquiera puede probar que la persona que controla la cuenta quemó y volvió a acuñar ETH.

El uso del hash de la dirección de quema (que no se puede gastar) hace que sea difícil, pero no inviable, conocer los fondos transferidos de forma privada. Esto requiere un ataque de fuerza bruta que calcule el hash de cada dirección de Ethereum que exista actualmente hasta que uno de los hashes coincida con un anulador almacenado en el SMT. Una vez que se descubre la preimagen del hash del anulador (es decir, la dirección que no se puede gastar), se pueden implementar los pasos descritos anteriormente para rastrear la cuenta que envió fondos a la dirección que no se puede gastar en cuestión.

Podemos resolver este problema encontrando un mecanismo más seguro para generar anuladores. La estrategia adoptada en la especificación EIP-7503 actual es usar la misma función hash (compatible con ZK) para generar un anulador N mediante el hash de la dirección de grabación con el valor secreto s . En notación pseudomatemática, esto se ve así: N = H(A,s) , donde A es la dirección que no se puede gastar y s es el valor secreto que generó A inicialmente.

En este caso, el valor secreto s se describe como una sal . Este valor de sal aumenta esencialmente la dificultad de extraer información sobre las direcciones de quemado de los anuladores: si se conociera s , un observador podría realizar un ataque de fuerza bruta y ejecutar todas las combinaciones posibles de hash(burnaddress,secret) que produzcan un anulador N almacenado en la cadena. Pero el usuario mantiene s en secreto, lo que elimina de manera efectiva la posibilidad de encontrar la dirección de quemado correspondiente para un anulador usado.

Verificación de la prueba de quema privada

Ahora que sabemos qué afirmaciones intenta probar la prueba de quemado, tenemos una idea bastante clara de cómo funciona la verificación de pruebas. Para la primera afirmación ( h(s) = A ), el verificador necesita “entender” la lógica de la función hash utilizada para generar la dirección A —para saber que H(s) es efectivamente igual a A . Codificar la lógica de la función hash en el circuito verificador también hace cumplir el requisito de que A no se puede generar con la función hash Keccak256.

Para la segunda declaración ( A tiene un saldo positivo b de ETH), el verificador debe verificar una prueba de Merkle que demuestre la inclusión de A en el estado de Ethereum y valide los datos de la cuenta. El verificador de circuito también verifica que el encabezado del bloque B sea de la cadena canónica (antes de extraer la raíz del estado) llamando al código de operación BLOCKHASH con la entrada block.blockHash(blockNumber) , donde blockNumber hace referencia al encabezado del bloque B . Si B es parte de la cadena canónica de Ethereum, el hash devuelto por el código de operación BLOCKHASH debe coincidir con el hash del encabezado del bloque B .

Además, el circuito verificador autentica el anulador incluido en la prueba ZK-SNARK del usuario y confirma que el anulador no se ha utilizado anteriormente. La resistencia a colisiones de las funciones hash desempeña un papel de apoyo aquí al evitar los intentos de generar dos hashes anuladores diferentes N1 y N2 para la misma combinación burn address <> secret value . Si un usuario puede generar diferentes anuladores para la misma dirección, puede acuñar ETH dos veces, independientemente de si el árbol de Merkle disperso almacena un anulador para esa dirección o no.

Para garantizar que los proponentes de bloques puedan verificar las pruebas de quemado, EIP-7503 propone una modificación del EVM para implementar la verificación de compatibilidad de las pruebas ZK-SNARK. Los autores de EIP-7503 han probado la viabilidad de implementar la verificación en EVM de las pruebas de quemado mediante la creación de una versión del EVM habilitada para EIP7503 utilizando el marco Polaris EVM . Puede visitar el repositorio de GitHub dedicado al proyecto para obtener más detalles sobre el diseño del protocolo.

Acuñación de ETH a la dirección del destinatario

EIP-7503 introduce un nuevo tipo de transacción que genera ETH para un usuario que demuestra con éxito que depositó una cantidad específica en una dirección que no se puede gastar. El remitente de la transacción envía una prueba ZK-SNARK (junto con un anulador) y la red realiza una transición de estado que actualiza el saldo de la dirección de retiro (después de verificar la prueba de quema).

Aunque la EIP-7503 ofrece una negación plausible, se recomienda a los usuarios que eviten pagar por transacciones de acuñación con fondos de la misma dirección que envió ETH a la dirección de quema. Si Alice envía ETH a una dirección que no se puede gastar 0xm00la y luego envía una transacción para pagar por la misma cantidad de ETH que se acuñará en una cuenta separada, Bob no necesita ser Jimmy Neutron para vincular a Alice con la transacción de quema original.

Las secciones anteriores no lo mencionan, pero necesitamos que los usuarios incluyan la segunda dirección B (que recibirá ETH de la transacción de acuñación) como una entrada pública al circuito de prueba ZK-SNARK. Esto evita posibles casos extremos en los que usuarios honestos se adelantan mientras las transacciones de acuñación esperan en el mempool.

Recuerde que el verificador no verifica la identidad de la dirección de envío y evita deliberadamente el requisito de saber si la misma dirección que quemó ETH también está canjeando ETH en una transacción de acuñación. Esto es genial desde una perspectiva de privacidad, ya que significa que los usuarios pueden volver a acuñar ETH con una dirección recién generada, pero aumenta el riesgo de un ataque anticipado. Dado que la prueba codifica toda la información necesaria para pasar la verificación (incluido el conocimiento del valor secreto s ), cualquiera puede enviar una transacción de acuñación de imitación que tenga la misma prueba pero una dirección diferente para recibir ETH acuñado.

Afortunadamente, podemos exigir que la prueba de quema haga referencia a la dirección de retiro B y aplicar una regla del tipo: “una transacción de acuñación solo puede acuñar ETH en la dirección extraída de la prueba de quema”. El verificador verifica la equivalencia entre la dirección pasada como entrada pública al circuito ZK-SNARK y la dirección especificada en la transacción de acuñación. De esa manera, cada usuario tiene la certeza de que nadie puede tomar su transacción portadora de prueba del mempool y robar su retiro.

¿Por qué EIP-7503? El caso de las transferencias privadas en Ethereum

Transferencias y pagos privados

La EIP-7503 ofrece una forma sencilla para que los usuarios de Ethereum transfieran fondos sin crear (sin darse cuenta) un vínculo entre las direcciones de envío y recepción. Puede enviar ETH desde una billetera a una dirección que no se pueda gastar recientemente y retirar a otra billetera proporcionando la prueba de quema y el anulador para fines de verificación. Para un observador externo, existe exactamente cero correlación entre la cuenta que quema ETH y la cuenta que acuña ETH.

Un caso extremo puede aparecer si un usuario quema ETH en una transacción e inmediatamente acuña ETH en una nueva dirección: un experto en análisis en cadena puede darse cuenta rápidamente de que la misma persona debe controlar ambas direcciones. Sin embargo, EIP-7503 tiene una característica poderosa para evitar la desanonimización: negación plausible . Aquí hay una definición de negación plausible del Political Dictionary :

La negación plausible es la capacidad de negar cualquier participación en actividades ilegales o poco éticas, porque no hay evidencia clara que demuestre la participación. La falta de evidencia hace que la negación sea creíble o plausible. — Diccionario político

La negación plausible se originó en el turbio mundo de las operaciones de la CIA, donde los funcionarios negaban tener conocimiento previo de las acciones llevadas a cabo por sus subordinados. La falta de un registro de los hechos accesible al público significaba que los funcionarios de alto rango podían desautorizar a los agentes de campo y evitar la responsabilidad por los resultados de las acciones de estos (evitando así desastres masivos de relaciones públicas).

La negación plausible tiene un significado similar en el contexto de realizar transferencias privadas utilizando EIP-7503. Supongamos que su "billetera principal" quema 1,365 ETH y su "billetera secundaria" acuña 1,365 ETH poco después. Si su operación atrae la atención de detectives en cadena demasiado ansiosos, puede simplemente afirmar que otra persona acuñó 1,365 ETH para que parezca que estaba completando una transferencia privada.

¿Y si te hacen una pregunta como: "¿Por qué enviarías ETH a una dirección falsa sin la intención de transferir dinero en secreto?" Puedes afirmar que la transacción se produjo por error; después de todo, nadie puede negar que se ha perdido una cantidad terrible de ETH por errores tipográficos en las direcciones de los destinatarios (incluso yo he cometido ese error). Esto da un vuelco a toda la conversación porque, ¿quién más que una persona de corazón frío no empatizaría con la pérdida de una gran cantidad de ETH?

Este es un ejemplo un tanto trivial que captura la importancia de EIP-7503: la negación plausible garantiza que los usuarios habituales de Ethereum puedan realizar transferencias privadas sin revelar ninguna información concreta que pueda sugerir la participación en un protocolo de privacidad. A diferencia de los protocolos de privacidad de la capa de aplicación, EIP-7503 evita almacenar rastros de transacciones en la cadena y dificulta la asociación de transacciones de quema y acuñación con identidades del mundo real.

EIP-7503 no proporciona anonimato y privacidad completos porque la información sobre la transferencia de fondos a la dirección de quema (incluidos los montos transferidos) se registra en la cadena. Pero la capacidad de romper el vínculo entre las direcciones de envío y recepción en una transacción es bastante poderosa y reduce las preocupaciones en torno a la reutilización de direcciones.

En lugar de utilizar la misma dirección para recibir pagos, un usuario puede generar una nueva dirección de quema y solicitar que se envíen fondos a esta dirección. Dado que el usuario tiene conocimiento del valor secreto s , puede generar una prueba de quema válida que demuestre el control sobre la creación de la dirección de quema al verificador en cadena y "retirar" el depósito acuñando ETH en una dirección diferente. Esto es bastante similar al concepto de generar una dirección oculta para recibir transferencias y reduce las probabilidades de correlacionar diferentes transacciones con la misma entidad.

Podemos ver cómo las transferencias privadas estilo EIP7503 pueden ser beneficiosas en otros escenarios:

• Comerciantes : al aceptar pagos en direcciones de quema y luego emitir ETH en direcciones de retiro no vinculables, los comerciantes pueden evitar exponer información financiera. La función de transacción privada de EIP-7503 evita además que los observadores externos obtengan detalles, como cuánto recibe un comerciante por los productos o el tamaño de su base de clientes.
• Compradores : Al realizar pagos a la dirección de correo electrónico proporcionada por un comerciante (en lugar de enviarlos a la dirección de correo electrónico públicamente identificable del comerciante), los compradores evitan filtrar información relacionada con el historial de compras. La dirección de correo electrónico no se puede correlacionar con la cuenta “real” del comerciante, lo que dificulta los intentos de saber qué compró y a quién.
• Filantropía : las organizaciones benéficas y políticas pueden recibir fondos sin que la identidad del remitente quede registrada permanentemente en la cadena. Las personas pueden donar a determinadas causas sin comprometer su reputación pública.

EIP-7503 también se puede utilizar por razones no relacionadas con la privacidad :

1. Actualmente, los exchanges centralizados (CEX) deben generar una dirección única para recibir un depósito de un usuario y necesitan enviar transacciones que transfieran los saldos de cada dirección a una o más billeteras frías como parte de los procesos de seguridad operativa. Con EIP-7503, un operador de CEX puede crear una única dirección de quema que recibe depósitos de un conjunto de usuarios y generar una prueba de quema que retira todos los depósitos acumulados en la dirección de quema a la billetera fría en una sola transacción. Una reducción en la cantidad de transacciones necesarias para consolidar los depósitos de CEX en una billetera fría beneficia al operador de CEX (costos operativos reducidos) y a la red (menor cantidad de transacciones en cadena).
2. Cualquier entidad que procese una cantidad significativa de pagos en cadena puede aprovechar la EIP-7503 para mejorar la eficiencia operativa, por lo que los CEX no son los únicos beneficiarios. Los comerciantes, las organizaciones benéficas y los canales de pago nativos de criptomonedas son algunos ejemplos de organizaciones que utilizan la EIP-7503 para reducir los gastos operativos mediante la agregación de depósitos en direcciones de quema y la distribución de los costos de transacción entre múltiples depósitos. Este aspecto de la EIP-7503 tiene el efecto secundario deseado de crear incentivos financieros para unirse al conjunto de anonimato y aumenta la privacidad general de las cuentas que realizan transferencias privadas.

Equilibrar la privacidad con la utilidad y el cumplimiento normativo

La EIP-7503 ofrece un camino sencillo para consagrar la privacidad de las transacciones en Ethereum sin necesidad de realizar modificaciones importantes al protocolo. En particular, la EIP-7503 permitirá a Ethereum ofrecer privacidad en las transacciones sin enfrentar los problemas que enfrentan otras cadenas de bloques centradas en la privacidad, como Zcash y Monero.

Aunque ya he escrito en defensa de las monedas de privacidad anteriormente , no hace falta mucho para ver que las monedas de privacidad como ZEC (Zcash) y MNR (Monero) no pueden lograr el objetivo de introducir dinero descentralizado, privado y utilizable en la economía global. Con las presiones regulatorias que obligan a los exchanges a retirar de la lista las monedas de privacidad, a los propietarios les resultará cada vez más difícil aprovechar la privacidad que ofrecen Zcash, Monero y otros protocolos diseñados explícitamente para ocultar información de transacciones en contextos del mundo real. Este extracto deWhy Privacy Coins Haven't Taken Off de Haseeb Qureshi ofrece una buena introducción a los desafíos que enfrentan los proyectos de privacidad "hardcore" en la actualidad:

Las monedas de privacidad siempre han sido el primer objetivo de las inquisiciones regulatorias. Cuando se les pide a los reguladores que "no se queden ahí parados, hagan algo", el fantasma más fácil son las monedas de privacidad oscuras. Desde el punto de vista regulatorio, hemos visto una serie de exclusiones de monedas de privacidad en Corea del Sur , Japón , el Reino Unido y los EE. UU . Los gobiernos están continuamente tratando de apretar el nudo sobre las monedas de privacidad (ver aquí , aquí y aquí ).

Los lobbies de las criptomonedas han crecido; grandes sectores de la venta minorista y muchas instituciones ahora poseen BTC y ETH. Pero muy pocas instituciones están dispuestas a salir en defensa de las monedas de privacidad. En lugar de permitir que toda la industria se vea contaminada, muchas se conforman con dejar que las monedas de privacidad se conviertan en el chivo expiatorio. — Haseeb Qureshi ( ¿Por qué las monedas de privacidad no han despegado ?)

Parece que la EIP-7503 ha llegado en el momento justo en la evolución de Ethereum: con más usuarios que cualquier otra cadena de bloques y una gran cantidad de inversión institucional, es menos probable que Ethereum sufra el mismo destino que otros proyectos que han intentado proporcionar una funcionalidad de pagos privados en el pasado. ¿Restringirán algunos exchanges el comercio de Ether si los tokens ETH acuñados de forma privada comenzaran a circular? Tal vez. Pero una docena de otros exchanges estarían encantados de asumir esa responsabilidad: así es como se ve tener fuertes efectos de red .

¿Por qué digo que la EIP-7503 llegó en el momento justo? Hubo un momento en la historia de Ethereum en el que todo el mundo pensaba que era necesario dar soporte a la privacidad en la capa base de inmediato . Pero otros miembros de la comunidad señalaron (con razón) los posibles casos extremos asociados con la promoción de Ethereum como una "tecnología de privacidad". A continuación, se incluyen extractos de un antiguo hilo del foro Ethereum Magicians en el que se analiza la necesidad de aumentar la privacidad en Ethereum:

En los años siguientes, las intuiciones de Griffith han sido en su mayoría correctas, y muchas criptomonedas que respetan la privacidad por defecto se enfrentan a la perspectiva de convertirse en monedas marginales utilizadas únicamente por los ciberpunks de línea dura (un grupo que comprende menos del 0,00001% de la población mundial). En comparación, el valor y la ubicuidad de Ether (ETH) solo han aumentado hasta el punto en que "dar un paso hacia la tecnología de privacidad" mediante la adopción de EIP-7503 es menos riesgoso que hace cinco años.

Si se implementa una actualización para admitir transferencias privadas, tal vez para evitar la captura regulatoria inversa o minimizar la complejidad de la capa base, una alternativa adecuada es pasar la responsabilidad de implementar EIP-7503 a las capas 2 y 3 de Ethereum. Dada la hoja de ruta centrada en los rollups de Ethereum, implementar EIP-7503 en un rollup tiene sentido y aún conserva el objetivo de consagrar la privacidad en Ethereum (por ejemplo, similar a los rollups que implementan ERC-4337 para la abstracción de cuentas nativas).

Este enfoque para implementar EIP-7503 es más fácil porque cada cadena L2 ya tiene un contrato puente que genera ETH para los usuarios en L2. Con un mecanismo para generar tokens ETH en funcionamiento, los rollups solo necesitan agregar componentes para almacenar anuladores en la cadena y generar/verificar pruebas de quema para respaldar las transferencias privadas al estilo EIP7503. Un ejemplo de una cadena de Capa 2 (L2) con planes de integrar EIP-7503 en su infraestructura es Taiko , como se describe en esta Solicitud de comentarios (RFC).

Aquí, vemos que un protocolo como Taiko puede ofrecer privacidad en las transacciones (sin realizar grandes cambios en su infraestructura) al adoptar EIP-7503. Esto tiene un beneficio clave para los equipos de protocolo que no quieren desarrollar una capa 2 centrada en la privacidad a gran escala (como Aztec v2 ), pero desean proporcionar una imposibilidad de rastreo y vinculación básicas a los usuarios. Vale la pena leer la propuesta del equipo de Nethermind de implementar EIP-7503 en Taiko para tener una idea de cómo se puede implementar EIP-7503 en una capa 2 de Ethereum.

La EIP-7503 también equilibra la necesidad de privacidad con el cumplimiento normativo, lo que se alinea con el objetivo del movimiento “privacidad 2.0” de Ethereum: salvaguardar la privacidad del usuario, al tiempo que se garantiza que los actores maliciosos no puedan explotar la infraestructura de privacidad con fines nefastos. Según una implementación de la EIP-7503 descrita en Ethereum Research, los rollups que adoptan la EIP-7503 pueden evitar que se repita el problema de Tornado Cash al impedir de forma selectiva que los piratas informáticos y estafadores conocidos laven fondos mediante transferencias privadas.

Para lograr esta propiedad, requerimos que los usuarios pasen una lista de direcciones incluidas en la lista negra ( blacklist[] ) como entrada al circuito que genera pruebas de transacciones de quema ZK-SNARK. El circuito verifica que la dirección del usuario que recibe ETH no sea parte de las direcciones almacenadas en la lista negra al generar una prueba de quema: una transferencia a una dirección incluida en la lista negra fallará automáticamente ya que el circuito no puede generar una prueba si la entrada no satisface todas las condiciones de validez.

El mantenimiento de un registro de direcciones incluidas en listas negras introduce un cierto grado de centralización y posibles vectores de censura, pero si aceptamos que la autorregulación impulsada por la comunidad y desde abajo es mejor que la regulación centralizada y desde arriba, estos dispositivos para garantizar el cumplimiento de las normas pueden ser necesarios.

Gestión de nóminas privadas para organizaciones en cadena

La transparencia es una de las piedras angulares de las DAO (Organizaciones Autónomas Descentralizadas): a diferencia de las organizaciones tradicionales, donde los detalles de la remuneración financiera se ocultan a los inversores y las partes interesadas, los pagos de los contribuyentes en las DAO se registran públicamente en la cadena. Este registro de auditoría en la cadena proporciona una cantidad significativa de rendición de cuentas y reduce en gran medida la asimetría de información que puede resultar en una mala gestión financiera por parte de los administradores de las DAO.

Sin embargo, las DAO inevitablemente madurarán y comenzarán a operar como corporaciones (para bien o para mal), momento en el que cosas como mantener privados los detalles de la compensación de los contribuyentes pueden volverse deseables. EIP-7503 proporciona la infraestructura que las DAO necesitan para comenzar a realizar pagos privados a los principales contribuyentes, desarrolladores y contratistas independientes. En todos los casos, el destinatario solo necesita generar una dirección de quema para recibir pagos y retirarlos a la dirección de su elección.

¿Cómo harán los miembros de la DAO para que los administradores rindan cuentas si se implementan pagos privados a los contribuyentes y contratistas? Esto depende del nivel de privacidad que busca la DAO y del nivel de ocultamiento que pueden tolerar los miembros de la DAO. Por ejemplo, para demostrar que AliceDAO efectivamente pagó 20 ETH a Alice por el trabajo de la DAO y que ese dinero no se utilizó para fines alternativos, Alice puede proporcionar una prueba que demuestre que generó la dirección que no se puede gastar.

Por ejemplo, Alice puede revelar la clave privada s utilizada para crear la dirección no gastable. Dado que la dirección no gastable se anula después de la operación de acuñación, Alice puede revelar s sin incurrir en ningún riesgo. Un verificador externo derivará la dirección no gastable mediante el hash de s utilizando la misma función hash criptográfica que Alice utilizó inicialmente y comparará ambas direcciones. Si coinciden, el verificador sabe que Alice tenía acceso a la dirección de quema en el momento en que se envió la transacción. Sin embargo, no sabe qué dirección utilizó Alice para recibir los tokens ETH acuñados (preservando la privacidad de Alice hasta cierto punto).

Reducir la dependencia de los mezcladores de criptomonedas

El uso de un mezclador como Tornado Cash para romper vínculos entre direcciones de billetera es problemático porque crea una forma de culpabilidad por asociación . Recuerde que los mezcladores brindan anonimato al mezclar los fondos depositados por diferentes usuarios en un solo fondo del que cualquiera puede retirar sin tener que proporcionar ninguna otra información que no sea evidencia para autenticar un depósito histórico.

Cuantos más fondos se inviertan en un fondo de privacidad, más difícil será para un observador externo deducir quién es el propietario de qué; si actores maliciosos se suman al fondo, los participantes honestos pueden estar ayudando sin saberlo a los delincuentes a blanquear dinero al contribuir al conjunto de anonimato del protocolo. Probablemente, por eso las sanciones de la OFAC se extendieron (y aún se extienden) a las direcciones que interactuaron con Tornado Cash, incluso si esas direcciones no están asociadas con actores maliciosos conocidos (por ejemplo, bandas de phishing, piratas informáticos patrocinados por estados nacionales y explotadores de sombrero negro).

Los mezcladores como Tornado Cash también generan un problema de fungibilidad: los tokens retirados de un pool de mezcla pueden volverse “contaminados” y resultar imposibles de usar o intercambiar 1:1 con tokens “limpios” que no hayan pasado por un mezclador. Hay un hilo excelente en Reddit que analiza el problema de los fondos contaminados con más detalle, que recomiendo leer. Estos son algunos de los comentarios más esclarecedores de ese hilo:

Esto puede tener consecuencias en el mundo real: por ejemplo, muchas personas de alto perfil en la comunidad Ethereum se encontraron incapaces de interactuar con algunas interfaces de dapp después de que sus billeteras recibieran cantidades no solicitadas de ETH desde el pool de Tornado Cash. EIP-7503 se describe como un "mezclador sin contrato" y evita los problemas antes mencionados al usar transferencias regulares de EOA a EOA para quemar ETH e introducir la acuñación directa para facilitar los retiros del pool de anonimato (en lugar de usar un contrato inteligente).

Otro beneficio de un mezclador sin contrato es el tamaño del conjunto de anonimato. Con Tornado Cash (y protocolos similares como Railgun ), el conjunto de anonimato es más pequeño (correlacionándolo con el número de participantes) y se reduce con el tiempo. Por el contrario, EIP-7503 convierte todo el conjunto de direcciones gastables y no gastables en Ethereum en un conjunto de anonimato. Dado el gran espacio de direcciones, es seguro decir que los detectives en cadena que intentan saber de dónde proviene el ETH enviado al destinatario de una transferencia privada tienen un trabajo difícil por delante.

¿Existen inconvenientes en la implementación de EIP-7503?

A continuación se presentan algunos posibles inconvenientes de la implementación de EIP-7503:

Cuestiones de cumplimiento normativo

Si bien los análisis anteriores sugieren que es poco probable que Ethereum sufra el mismo destino que Monero y Zcash si comienza a admitir transferencias privadas, es imposible predecir realmente qué sucederá si se activa EIP-7503. A continuación, se incluye un comentario de un participante en el hilo de Ethereum Magicians que analiza las implicaciones para los reguladores:

Si bien se trata de una solución de privacidad nativa para Ethereum, la comunidad está comenzando a reconocer la importancia de caminar por la cuerda floja entre la privacidad/anonimato y el cumplimiento normativo después de las consecuencias de las sanciones dirigidas a Tornado Cash. Esta idea está influyendo particularmente en el diseño de una nueva generación de protocolos de privacidad como Privacy Pools y Nocturne :

• Los pools de privacidad permiten a los usuarios generar una “prueba de inocencia” que acredite la exclusión de su depósito de un pool que almacena depósitos de actores maliciosos. En otras palabras, un usuario puede interactuar con un mezclador y decir “No estoy ayudando a criminales y terroristas a lavar dinero”.

• Nocturne tiene planes de realizar la transición a un protocolo de prueba de inocencia, pero actualmente implementa varias medidas de seguridad para garantizar el cumplimiento . Esto incluye el filtrado de depósitos, demoras en el procesamiento de depósitos, límites de velocidad por dirección y un límite de velocidad global que limita el valor total de los depósitos que el protocolo puede procesar en un día.

  
  

Las soluciones de privacidad basadas en contratos inteligentes, como Nocturne y Privacy Pools, son capaces de implementar controles detallados y excluir de forma selectiva a los usuarios que se considere que participan en actividades ilícitas. Las soluciones de privacidad dentro del protocolo, como EIP-7503, no discriminan, una característica deseable que, sin embargo, podría crear problemas y abrir la puerta a que actores maliciosos abusen de la funcionalidad de las transacciones privadas.

Es (teóricamente) posible mejorar EIP-7503 agregando el dispositivo de lista negra descrito anteriormente, pero es probable que esto abra una caja de Pandora de problemas:

• ¿Quién se encarga de mantener la lista de direcciones incluidas en la lista negra? ¿Le pedimos a la OFAC que proporcione una lista de direcciones incluidas en la lista negra y corremos el riesgo de que un gobierno decida quién puede realizar transacciones privadas en Ethereum? ¿Corremos el riesgo de desencadenar una bifurcación polémica si un grupo de validadores se niega a censurar las transferencias desde una o más cuentas incluidas en el registro de direcciones incluidas en la blacklistedAddresses ?
• Si se implementa EIP-7503 mediante un rollup, ¿es la DAO la encargada de mantener el registro blacklistedAddresses ? ¿O el equipo fundador contrata los servicios de empresas forenses como Chainalysis, Elliptic y TRM Labs para que proporcionen información sobre qué direcciones deben tener restringidas para recibir transferencias privadas? ¿Qué problemas pueden surgir si una empresa con fines de lucro decide lo que sucede en la capa base de un rollup?
• Si un rollup decide eliminar los privilegios administrativos y hacer que los contratos de los verificadores y acuñadores no se puedan actualizar, ¿cómo se asegura de que los actores maliciosos no comiencen a mover fondos a través del protocolo? ¿Se puede abordar el filtrado selectivo de transacciones de explotadores conocidos en las capas superiores de la pila (por ejemplo, en el nivel del secuenciador o del validador)? ¿Cuáles son las cuestiones logísticas involucradas?

Estas son solo algunas preguntas que deberán responderse antes de que Ethereum (o Ethereum L2) adopte EIP-7503. Las criptomonedas aún se encuentran en aguas desconocidas, pero es útil realizar mucho Murphyjitsu , pensando en posibles casos extremos con anticipación, al tomar decisiones que tienen implicaciones significativas para la supervivencia a largo plazo del protocolo.

La desgracia pesa más sobre aquellos que sólo esperan buena fortuna. — Séneca

Centralización potencial asociada a los tokens ERC-20

La implementación de EIP-7503 requiere una actualización de la EVM para admitir un nuevo tipo de transacción que acepte un recibo de quema y acredite el saldo del destinatario con ETH quemado en la transacción anterior. Los clientes de ejecución también deberán actualizarse para admitir un árbol de Merkle disperso (SMT) para almacenar anuladores e implementar circuitos fuera de la cadena para generar y verificar pruebas de quema en nombre de los usuarios.

Reconociendo que una actualización puede ser inviable, los autores de EIP-7503 tienen una propuesta alternativa para implementar EIP-7503 usando un contrato de token ERC-20 . Los usuarios mantienen el mismo flujo de trabajo descrito en las secciones anteriores (enviar fondos a una dirección que no se puede gastar y generar un anulador), pero acuñan tokens ERC-20 después de enviar una prueba de quema en lugar de recibir tokens ETH. El contrato ERC-20 se integra con un contrato de verificador EIP-7503 especial que verifica las pruebas de quema en la cadena (el contrato ERC-20 también puede implementar el circuito de verificación).

Si bien un contrato ERC-20 simplifica la implementación de EIP-7503, este enfoque reintroduce el problema de la centralización y la censura. Podemos hacer que el token ERC-20 no se pueda actualizar ni gobernar como Wrapped Ether (WETH) para eliminar los vectores de centralización, pero eso no puede ayudar con problemas como la eliminación del token de las listas de exchanges.

Además, debemos tener en cuenta que es más fácil para los investigadores forenses en cadena identificar cuentas que interactúan con el contrato ERC-20 y colocar esas direcciones en una lista negra, si los reguladores deciden perseguir a las criptomonedas que más respetan la privacidad y que circulan en Ethereum. Dado que este es el problema que se pretendía resolver con la EIP-7503, puede resultar difícil ver cómo la propuesta de crear un “token ERC-20 privado” es una mejora.

Por otro lado, un token ERC-20 facilitará la implementación de una función de filtrado de transferencias que bloquee las transferencias a direcciones incluidas en la lista negra. Un desarrollador podría simplemente almacenar blacklist[] en el contrato y modificar transfer() para incluir una verificación de la identidad de la dirección que recibe los tokens en la transacción. Sin embargo, esta es una función que no podemos implementar a nivel de protocolo sin introducir algunos supuestos de confianza muy sólidos.

Aumento de los gastos generales de I+D

La EIP-7503 implica la construcción, prueba, auditoría y mantenimiento de una infraestructura criptográfica compleja y de vanguardia necesaria para respaldar transacciones anónimas y privadas. Al menos, la descripción de Nethermind de una implementación L2 de la EIP-7503 y la prueba de concepto de la cadena EIP-7503 de Nobitex Labs sugieren que se destinará una cantidad considerable de esfuerzo de ingeniería a la creación de circuitos ZK-SNARK para generar y verificar pruebas de la EIP-7503.

También es importante señalar que los primitivos criptográficos como ZK-SNARKs aún no han sido probados lo suficiente para que los desarrolladores de protocolos los implementen con absoluta confianza. Para ilustrarlo, Zcash corrigió un error que habría permitido a un usuario deshonesto proporcionar pruebas falsas de propiedad de activos y acuñar una cantidad infinita de tokens en 2018. También he hablado sobre el hecho de que el equipo de Tornado Cash haya escapado por poco de un posible exploit en 2019.

Un error en la implementación de EIP-7503 en Ethereum tendrá un impacto no trivial. Por ejemplo, un usuario que descubra accidentalmente una falla que permita eludir controles críticos realizados por el circuito que verifica una prueba de quema (por ejemplo, el balance de direcciones de quema y el uso de anuladores) puede aprovechar el conocimiento para acuñar cantidades infinitas de Ether y hacer caer el valor de mercado de ETH.

Otra área de complejidad proviene del requisito de que el verificador EIP-7503 verifique el encabezado de bloque B incluido en la prueba generada por el usuario. El EVM almacena hashes de los últimos 128-256 bloques, por lo que el verificador en cadena no puede verificar sin confianza los encabezados de bloque de un rango más amplio.

Para verificar la raíz del estado de los bloques más antiguos, será necesario implementar EIP-210 . EIP-210 propone crear un contrato inteligente a nivel de sistema que almacene hashes de bloques históricos y refactorice el código de operación BLOCKHASH para permitir que los clientes lean el contrato.

EIP-210 no es estrictamente necesario ya que los usuarios tienen al menos una hora ( 14 seconds * 256 blocks ) para generar y enviar una prueba que se pueda verificar con EVM. Aun así, dar a los usuarios la libertad de retrasar el canje de depósitos enviados a una dirección de quema mejora la experiencia del usuario y hace que el proceso de retiro sea más resistente a la agrupación de direcciones y técnicas de análisis similares.

Una alternativa es integrar un contrato de oráculo que requiera que los actores (incentivados) envíen encabezados de bloque históricos a un contrato en cadena. Esto es más fácil de implementar que crear un contrato inteligente a nivel de sistema y refactorizar un código de operación, pero requiere que los operadores de oráculos confíen en (a) publicar encabezados de bloque correctos (b) enviar encabezados de bloque con prontitud. Si ambas suposiciones no se cumplen, los usuarios honestos pueden no poder canjear depósitos y los actores maliciosos podrían publicar encabezados de bloque incorrectos para verificar las pruebas de Merkle en el caso de transacciones de quema inexistentes.

Reducción de conjuntos de anonimato

En el momento en que se activa la EIP-7503, el anonimato establecido para un usuario que acuña ETH en el bloque n.° 11000 incluirá todas las EOA de Ethereum con un saldo positivo de ETH y cero transacciones salientes. Esto es crucial para la propiedad de imposibilidad de rastrear las transacciones anónimas: si una transacción quema ETH, es imposible reconocerla como una transacción de quema porque una dirección que no se puede gastar parece una dirección de Ethereum normal.

Sin embargo, la cantidad de direcciones en las que el saldo de la cuenta permanece estático y no se envían transacciones se reducirá hasta un punto en el que solo las direcciones quemadas conformarán el conjunto de anonimato. Por lo tanto, el conjunto de anonimato comienza a parecerse a los conjuntos de anonimato de los mezcladores basados en contratos como Tornado Cash y las herramientas de privacidad de nueva generación como Privacy Pools y Railgun (lo que implica una reducción gradual de las garantías de privacidad de EIP-7503).

La única excepción son aquellas cuentas que reciben ETH porque el remitente transfirió fondos accidentalmente a una dirección inexistente; dichas cuentas permanecerán en el conjunto de anonimato EIP-7503 para siempre. Es posible que queramos considerar las direcciones en las que el propietario pierde la clave privada como parte del conjunto de anonimato, pero esto (afortunada y desafortunadamente) sucede raramente y esas cuentas generalmente tienen al menos una o más transacciones salientes. (Es difícil imaginar que el usuario más novato pierda las claves privadas antes de realizar cualquier transacción).

A pesar de las reducciones en el conjunto de anonimato, EIP-7503 sigue siendo útil por la negación plausible que ofrece. Supongamos que alguien crea una tormenta en el cripto-Twitter y acusa a Alice de quemar ETH a propósito (enviándolos a una dirección que no se puede gastar) con la intención de retirar fondos a una nueva dirección más tarde. Alice tiene una negación plausible y puede contrarrestar la acusación afirmando:

• “Envié ETH a la dirección por error. ¿Puedes demostrar que no cometí un error al escribir la dirección en MetaMask?”
• “Tengo la clave privada de la dirección pero no puedo compartirla. No me estarás pidiendo mi clave privada ahora, ¿verdad?”
• “Tengo la clave privada de la dirección, pero la perdí. ¿Puedes demostrar que no perdí mi clave privada?”

Puede que estas afirmaciones no resulten convincentes, pero así es como se ve la negación plausible en un contexto del mundo real. El Diccionario Jurídico lo expresa así:

“Plausible no significa confiable, posible o incluso probable. Plausible significa que se podría concluir que algo podría o no ser posible. Pero generalmente de manera teórica, superficial o sospechosa. Tampoco tiene que ser necesariamente una conclusión “razonable”. En su sentido más amplio, el término generalmente apunta a una falta de pruebas. Después de todo, la palabra inocente hasta que se demuestre lo contrario es la columna vertebral de nuestro sistema legal.

“Por lo tanto, si no hay pruebas, es plausible que lo nieguen. Básicamente, cualquier cosa ilegal o poco ética que pueda justificarse bajo una apariencia inocente y probable, sea verdadera o no, cae dentro de la negación plausible. Incluso si la plausibilidad de la negación es sospechosa”.

El único momento en el que un usuario puede estar vinculado de manera concluyente a una transferencia privada EIP-7503 es en el momento de procesar una transferencia a la dirección del destinatario. Sin embargo, los usuarios pueden tomar medidas para reducir o eliminar por completo la posibilidad de que observadores externos vinculen la transacción de retiro con la transacción de quema:

• En lugar de retirar a una dirección que se pueda gastar, Alice acuña ETH en otra dirección de quema para mantener los fondos en el anonimato establecido. Repetir el proceso de quema → acuñar → quemar → acuñar → repetir varias veces hace que sea más difícil detectar si la dirección final es una cuenta controlada por Alice.
• En lugar de retirar el monto total, Alice divide el retiro en dos o más transacciones. Retrasar o aleatorizar los retiros genera “ruido” que dificulta el análisis de la actividad de las transacciones y dificulta la vinculación de las transacciones de quema y acuñación con el mismo usuario.

Nota : La segunda técnica es una extensión propuesta de EIP-7503 y no parece ser factible con el diseño actual. Para que los usuarios dividan los retiros, es necesaria una función para dividir los anuladores de modo que nullifier 1 otorgue el derecho a acuñar una fracción del saldo de la dirección de quema, nullifier 2 otorgue el derecho a acuñar otra fracción del saldo, etc.

Conclusión

La EIP-7503 es una solución a uno de los problemas más subestimados de Ethereum: la falta de privacidad financiera. Si Ethereum va a reemplazar a los bancos algún día, necesita proporcionar un nivel de privacidad igual al que los usuarios disfrutan actualmente en el status quo. Si no es así, Ethereum no logrará una adopción masiva porque renunciar a la privacidad, incluso para obtener los beneficios de evitar la censura, es un sacrificio que la mayoría de las personas no pueden hacer.

La EIP-7503 aún se encuentra en la etapa de revisión y probablemente sufrirá cambios y mejoras de rendimiento. Además de la compatibilidad futura con el retiro de montos parciales, una característica útil es permitir a los usuarios combinar de manera recursiva múltiples pruebas de quema en un único SNARK que verifica los depósitos en diferentes direcciones de quema en una sola transacción de verificación. Esta característica mejora aún más el atractivo de la EIP-7503 para los CEX y los comerciantes que desean mantener una única dirección por depósito de usuario sin tener que enviar una prueba de quema individualmente para (potencialmente cientos o miles de) direcciones de quema.

Los usuarios habituales también pueden beneficiarse enviando tokens a múltiples direcciones de quema (en lugar de enviarlos a una única dirección que no se pueda gastar) y enviando la prueba agregada y el conjunto de anuladores para completar la transferencia privada. Al usar más de una dirección de quema, los remitentes pueden aleatorizar aún más la actividad de las transacciones y detener los intentos de rastrear las transacciones de quema hasta una sola persona. Esto complementa los principales beneficios que ya ofrece EIP-7503, como las autotransferencias privadas, las donaciones/pagos privados entre pares y la gestión privada de nóminas para las DAO en cadena.

Si disfrutaste leyendo este artículo, considera compartirlo con alguien a quien le pueda resultar informativo y suscríbete al boletín de 2077 Research para obtener más información detallada sobre las propuestas que surgen del ecosistema EIP. Seguiremos centrándonos en las soluciones de privacidad en Ethereum y planeamos publicar un análisis profundo de ERC-5564 (un estándar para generar direcciones ocultas y enviar transacciones con direcciones ocultas en Ethereum).

¡Manténganse al tanto!

Nota del autor: Este artículo también se publica aquí .