Consejos de lectura

· Antes de leer este artículo, necesitas tener un conocimiento básico de MEV

· Estar familiarizado con las transacciones de Ethereum y comprender qué contiene una transacción y cómo se incluye finalmente en el bloque

· Conoce el Árbol de Merkle y el papel de la prueba de conocimiento cero

· haga clic para leer: MEV (5): Un ecosistema MEV más justo (Parte 1)

El artículo anterior presentó (1) el diseño del Flashbot SGX Builder, que aumenta la equidad del Bloque Constructor a través de hardware confiable, y (2) el diseño del Chainlink FSS, que previene MEV al descentralizar los roles de ordenación de transacciones.

Este artículo discutirá (3) el diseño de Encrypted Mempools, que tiene como objetivo reducir o eliminar MEV al proporcionar privacidad para transacciones a través de métodos criptográficos.

Mempools encriptados

Dos objetivos: protección de MEV y resistencia a la censura

Si existe una herramienta que permita a los usuarios cifrar sus transacciones antes de difundirlas y descifrarlas solo cuando se incluyan en el bloque, los usuarios no tendrán que preocuparse por verse afectados por MEV. El Buscador de MEV no puede ver en absoluto el contenido de la transacción, y los usuarios no necesitan preocuparse por que sus transacciones sean denegadas de ingresos debido a ser objetivo de proponentes o violar sanciones gubernamentales. La piedra angular para construir esta herramienta es la criptografía.

Las mempools encriptadas utilizan la criptografía para (1) encriptar el contenido de la transacción del usuario para proteger su privacidad y (2) verificar la validez de la transacción cuando está encriptada, evitando que los atacantes generen un montón de transacciones encriptadas pero inválidas. Esto les impide lanzar un ataque de denegación de servicio en la cadena, ya que el proponente desperdiciaría espacio de bloque al incluir un montón de transacciones inválidas que solo se descubren en el último momento.

Consejo de lectura: La mera encriptación no puede garantizar plenamente la resistencia a la censura, porque el Proponente que desea censurar aún puede negarse a aceptar cualquier transacción encriptada, por lo que la encriptación solo aumenta el costo de la censura (el Proponente renuncia a las tarifas de manipulación de todas las transacciones encriptadas). Para lograr una mejor protección contra la censura, es necesario utilizar una Lista de Inclusión como PBS.

Asegúrese de que las transacciones puedan descifrarse (Descifrado garantizado)

Después de cifrar la transacción, es importante asegurarse de que se pueda descifrar. No hacerlo puede crear una vulnerabilidad en un ataque de Denegación de Servicio (DoS). En dicho ataque, el atacante envía repetidamente transacciones cifradas que no se pueden descifrar. Como resultado, el nodo debe retener estas transacciones hasta que expiren, lo que lleva a una acumulación de estas transacciones inútiles en la pool de transacciones del nodo.

Hay algunas formas de asegurar que las transacciones puedan ser descifradas:

1. Confianza pura (En vuelo)

2. Hardware confiable, enclave

3. Cifrado/Descifrado de umbral

4. Retraso de encriptación/desencriptación

5. Testigo de Encriptación/Desencriptación

△ Varias formas de garantizar que las transacciones puedan ser descifradas y sus ejemplos. La complejidad aumenta de izquierda a derecha, siendo la confianza pura la más simple y la desencriptación de testigos la más difícil.

Fuente de la imagen:https://www.youtube.com/watch?v=XRM0CpGY3sw

Compromiso-revelación

¿El mecanismo de compromiso-revelación también puede lograr el mismo propósito? El usuario comienza ingresando su contenido de transacción en una función hash para obtener un valor hash, conocido como el compromiso. Una vez que el proponente garantiza la inclusión del compromiso de transacción del usuario en el bloque, el usuario procede a revelar el contenido completo de la transacción.

Consejo de lectura: La forma de compromiso puede ser como el Proponente en PBS prometiendo que se incluirá en el bloque del Constructor a través de la firma. Es un compromiso garantizado. Si el Proponente viola la promesa, será castigado.

△ El proponente promete recibir el compromiso de la transacción de Alice

Aunque Commit-reveal y la encriptación pueden servir al mismo propósito de ocultar el contenido de la transacción del usuario y prevenir la extracción y censura de MEV, Commit-reveal no puede garantizar la descifrado ya que el poder radica en las manos del usuario. El usuario tiene la opción de no revelar el contenido, ya sea intencional o accidentalmente.

Requerir a los usuarios que adjunten un depósito y perder el depósito cuando terminen sin Revelar puede empeorar la ya mala experiencia del usuario de Commit-reveal.

△ Alice no necesita revelar su transacción

1. Confianza pura (En vuelo)

El usuario cifra la transacción y la envía al rol centralizado. El rol centralizado luego descifra la transacción y se asegura de que no se filtrará antes de ser incluida en el bloque. Los usuarios suelen confiar en el rol centralizado y consideran las transacciones como cifradas hasta que se incluyen en el bloque, aunque el rol centralizado descifra la transacción inmediatamente después de recibirla.

Consejo de lectura: Este rol centralizado sería, por ejemplo, Constructor de PBS, Proponente, o Secuenciador/Operador de Rollup.

2. Hardware de confianza, Enclave

Funciona igual que la confianza pura, pero mejor que la confianza pura porque los usuarios confían en un hardware confiable y en el código del programa que ejecuta, en lugar de confiar en una persona, una organización o una empresa.

3. Cifrado/Descifrado de Umbral

Chainlink FSS también utiliza cifrado y descifrado de umbral, pero en Chainlink FSS los administradores de las claves de umbral son Oráculos de Chainlink, mientras que en Memorias cifradas los administradores (llamados Keypers) pueden ser Validadores de L1 o L2 (suponiendo que L2 también tiene En el caso de Validador descentralizado).

El cifrado/descifrado por umbral tiene varias desventajas:

• Suposición de mayoría honesta fuerte: Se debe asumir que más de la mitad de los Keypers son honestos. Si son deshonestos, pueden descifrar y ver las transacciones de usuario a voluntad, revisar las transacciones o extraer el MEV de las transacciones.
• Falta de responsabilidad: Mientras un número suficiente de participantes de Keyper colaboren, pueden descifrar la información. Sin embargo, cuando los participantes de Keyper conspiran, no tenemos forma de saber cuáles están involucrados en la conspiración. Sin poder identificar a los actores maliciosos, es imposible diseñar un mecanismo de castigo para Keyper. Por lo tanto, debemos confiar en la suposición de que la mayoría de los participantes de Keyper son honestos.
• Debilitamiento de la vitalidad: si hay demasiados Keyper desconectados, habrá un recuento insuficiente de Keyper en línea, lo que evitará la descifrado y la producción de bloques. Esto hará que la cadena se detenga. Esto entra en conflicto con el mecanismo PoS de Ethereum, que enfatiza que la cadena seguirá produciendo bloques incluso en caso de una tercera guerra mundial, y eventualmente logrará la finalidad. Se puede inferir que la probabilidad de que Ethereum PoS utilice el descifrado con un umbral no es alta.

Porque el cifrado y descifrado de umbral requiere muchos cambios, L2 es más adecuado para este enfoque que L1.

Este artículo propone el diseño y las consideraciones para la implementación en L1. Los proyectos que están probando este diseño pueden consultar Shutter Network. Para obtener más información, por favor revisa:https://ethresear.ch/t/shutterized-beacon-chain/12249

4. Encriptación/desencriptación de retardo

El cifrado con retraso garantiza que el texto cifrado pueda descifrarse automáticamente después de un cierto período de tiempo. Sin embargo, el proceso de descifrado no es realmente automático y requiere que alguien actúe como el descifrador y realice cálculos continuos. Después de un cierto período de tiempo, determinado por la dificultad del cifrado, los cálculos pueden completarse y el descifrado puede lograrse con éxito.

El concepto detrás del cifrado de retraso es similar a la Función de Retraso Verificable (VDF), ambos pertenecientes a la familia de la Criptografía de Liberación Temporal.

VDF nos permite verificar rápidamente F(x): un resultado de "cómputo secuencial que consume tiempo". Esto es similar a la Prueba de Trabajo (PoW), pero el cálculo de VDF es un proceso secuencial, a diferencia de PoW, que puede acelerarse a través de la computación paralela. El descifrador de VDF solo puede realizar cálculos repetidos paso a paso.

△ Con VDF puedes verificar el resultado de un cálculo que me llevó 10 segundos completar, digamos, en 0.01 segundos, y no tenía forma de paralelizar mi cálculo. Fuente de la imagen:https://techtelegraph.co.uk/verifiable-delay-functions-on-bitcoin

El cifrado y descifrado retardados también son cálculos continuos como VDF y no pueden acelerarse a través de operaciones paralelas. Sin embargo, se debe considerar que alguien acelerará el proceso de descifrado a través de la optimización de hardware. Por lo tanto, si desea adoptar esta tecnología y aplicarla en un entorno público real, debe asegurarse de que nadie tenga una brecha de hardware enorme y pueda completar el descifrado con anticipación (y el descifrado se realiza en privado, por lo que es difícil de detectar).

Actualmente, la Fundación Ethereum y Protocol Labs ya están colaborando en la investigación de chips ASIC VDF, con la esperanza de exportar el hardware informático más avanzado al mercado, para que nadie pueda tener ventajas de hardware dispares y descifrar en secreto de antemano. Para obtener más información, consulte: https://filecoin.io/blog/posts/collaboration-with-the-ethereum-foundation-on-vdfs/

Consejo de lectura: VDF también se puede utilizar para aumentar la no manipulabilidad de los números aleatorios de Ethereum.

La ventaja del cifrado y descifrado retardados en comparación con el cifrado y descifrado de umbral es que no necesita confiar ni depender del funcionamiento normal de un grupo de Keypers, y se descifrará automáticamente cuando llegue el momento. Sin embargo, este tiempo de descifrado impuesto también es una desventaja del descifrado retardado: las transacciones cifradas deben tomar un período de tiempo para ser descifradas, lo que significa que hay un retraso fijo para que las transacciones de usuario se carguen en la cadena. Además, la competencia de hardware también es un riesgo que no se puede ignorar en este método. Es difícil saber si alguien ha desarrollado un chip más rápido para descifrar.

5. Encriptación/Desencriptación de Testigos

Imagina que un texto cifrado no se descifra mediante una clave o una computación secuencial, sino que solo se puede descifrar cuando se cumple cierta "condición", como "cuando se resuelve esta ecuación" o "cuando se resuelve esta ecuación". Una vez que el texto cifrado se incluye en el bloque, se puede descifrar el texto y así sucesivamente.

Consejo de lectura: "Saber la clave para descifrar un texto cifrado" o "saber los resultados de cálculos continuos" es en realidad una condición.

A través del cifrado de testigos, no solo podemos lograr los efectos del cifrado de umbral y del cifrado retardado, sino que también podemos combinar estos dos métodos de descifrado. Por ejemplo, podemos establecer las condiciones como 'Condición 1: 'Un grupo de Keypers acuerda descifrar este criptotexto' o Condición 2: 'Después de cinco minutos'': Si todos los Keypers están en línea, podemos cumplir rápidamente con la Condición 1 para descifrar el criptotexto. Sin embargo, si no hay suficientes Keypers en línea, al menos podemos asegurarnos de que podemos cumplir con la Condición 2 y descifrar probando a través de VDF que 'han pasado cinco minutos'.

△ Suficientes Keypers pueden ser descifrados en línea (arriba) o después de suficiente tiempo (abajo)

Siempre que se demuestre que se cumplen las condiciones, se puede lograr el descifrado. La prueba se puede realizar a través de métodos como las pruebas de conocimiento cero, que pueden verificar de manera eficiente cálculos complejos (asumiendo que las operaciones requeridas para probar las condiciones son complejas) u ocultar información (asumiendo que el probador no quiere revelar cierta información durante el proceso de prueba). Sin embargo, aunque el cifrado de testigos es muy potente, la tecnología actual no es suficiente para proporcionar ningún uso práctico.

△ La madurez de las diferentes tecnologías de cifrado y descifrado. El cifrado y descifrado de testigos (Witness) no es lo suficientemente maduro. Fuente de la imagen:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_591

Manipular y realizar operaciones en el texto cifrado a través de cifrado homomórfico

Los párrafos anteriores presentaron diferentes formas de garantizar que las transacciones puedan ser descifradas, pero ¿cuándo pueden ser descifradas las transacciones? La respuesta es: después de que la transacción se incluya en el bloque y se determine el orden. Pero, ¿cómo ensambla el Constructor de Bloques un bloque a partir de un montón de tonterías, o incluso ensambla eficientemente un bloque altamente rentable? La respuesta es: Cifrado Homomórfico (HE).

△ Ejemplo de cifrado homomórfico utilizado para votar: El contenido del voto ha sido cifrado, pero el texto cifrado aún puede ser sumado y descifrado después de que se calcule el resultado. Fuente de la imagen:https://twitter.com/khushii_w/status/1660278622291210242

Consejo de lectura: Si el cifrado y descifrado se realizan a través de confianza pura (en tránsito) o hardware de confianza, en realidad no espera hasta que la transacción se incluya en el bloque y se determine el orden antes de descifrar. Después de todo, todos confían en la otra parte, por lo que descifrarán y ordenarán la transacción inmediatamente después de recibirla. Esto puede acelerar la formación de bloques y no requiere recursos adicionales para realizar operaciones de cifrado homomórfico.

A través del cifrado homomórfico, podemos realizar operaciones en el texto cifrado sin descifrar la transacción. Podemos aplicar el proceso de operación de organizar transacciones y formar un bloque legal a estas transacciones cifradas sin descifrar la transacción, y obtener un bloque de transacción cifrado. Cuando el bloque se descifra, obtendremos un bloque completo y legal, en el que las transacciones se descifran y se ordenan en el orden anterior al cifrado.

△ A través del cifrado homomórfico, Block Builder puede ensamblar un bloque completo y legal a partir de transacciones cifradas

Consejo de lectura: Hay niveles de cifrado homomórfico, como el cifrado homomórfico parcial (Partially HE) y el cifrado homomórfico completo (Fully HE). El cifrado homomórfico parcial solo puede sumar o multiplicar el texto cifrado, mientras que el cifrado homomórfico completo puede sumar y multiplicar el texto cifrado (básicamente, se puede realizar cualquier operación).

△ La tercera columna: La madurez de las diferentes tecnologías de cifrado y descifrado que admiten FHE. Excepto en vuelo y enclave, que no requieren HE y, por lo tanto, se consideran admitidos, los demás aún no están disponibles. Fuente de la imagen:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_620

Lo anterior presenta diferentes mecanismos para cifrar y descifrar transacciones. Cada uno de ellos tiene diferentes ventajas y desventajas, pero al final, todo lo que pueden hacer es ocultar el contenido de la transacción y asegurarse de que se pueda descifrar cuando se cumplan las condiciones. Una vez que el contenido de la transacción está oculto, puede evitar ser descifrado. Extracción de MEV y riesgo de censura.

Pero los datos de la transacción en sí tendrán metadatos relevantes, como el iniciador de la transacción, la tarifa de transacción o la firma, que se utilizan para verificar la validez de la transacción. Además, la dirección IP del iniciador también es una forma de metadatos, e incluso el tamaño de los datos de la transacción. Todos estos metadatos tienen el potencial de filtrar la privacidad del usuario, por lo que también debemos proteger estos metadatos.

Asegúrese de que los metadatos no filtren la privacidad

La siguiente lista los diversos metadatos de transacciones encriptadas y las medidas de protección correspondientes, que requerirán técnicas criptográficas como el cifrado homomórfico y las pruebas de conocimiento cero.

1. dirección IP

2. Firma de transacción

3. Tarifas de transacción

4. Iniciador de transacción y su valor de Nonce

5. Tamaño de transacción

△ Los metadatos diferentes de las transacciones pueden filtrar la privacidad del usuario. Fuente de la imagen:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_709

dirección IP

La red a la que se conecta un usuario para enviar transacciones cifradas puede revelar la identidad del usuario en función de la dirección IP del usuario y puede ser censurada. La protección de la privacidad a nivel de red se basa en tecnologías como Tor.

Firma de transacción, tarifa de procesamiento, iniciador de transacción y su valor de Nonce

Estos metadatos se utilizan para probar la validez de la transacción, pero revelarán la identidad del usuario, por lo que deben estar encriptados. Una vez encriptados, debemos usar otras herramientas para probar la validez de las transacciones sin revelar esta información. De lo contrario, la red podría ser atacada por DoS y llenarse de un montón de transacciones inválidas que solo se descubren después de descifrarlas.

Cuando un nodo recibe una transacción cifrada, primero debe (1) confirmar que el iniciador de la transacción realmente inició la transacción, es decir, verificar la firma de la transacción y, a continuación, (2) confirmar que el iniciador tiene suficiente ETH para pagar la transacción (saldo del usuario ≥ precio del gas * límite de gas) y (3) verificar el valor del nonce del remitente para evitar ataques de reproducción de transacciones.

Prueba de conocimiento cero

Podemos usar pruebas de conocimiento cero para demostrar que las transacciones pasan estos controles sin revelar esta información. Una prueba de conocimiento cero consta de información pública (Entrada Pública), información privada (Testigo Privado) y la declaración que la prueba quiere demostrar (Declaración).

△ Por ejemplo, la información pública (entrada pública) es una transacción encriptada (texto cifrado tx), la información privada (testigo privado) es una transacción no encriptada (texto cifrado tx), y la declaración (declaración zk) que debe ser probada por esta prueba de conocimiento nulo es "esta "Las transacciones encriptadas son legales" (tx cifrado válido). Fuente de la imagen:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_391

Por ejemplo, si Alice quiere demostrarle a Bob que tiene más de 10 ETH, pero no quiere revelar su dirección, puede usar una prueba de conocimiento cero para demostrarle a Bob que su dirección realmente tiene un saldo de más de 10 ETH.

"Demostrar que la dirección de Alice tiene un saldo de más de 10 ETH" es la declaración (declaración zk) que se debe probar con esta prueba de conocimiento cero. Para generar esta prueba, Alice debe proporcionar su dirección y probar que tiene la clave privada de la dirección (por ejemplo, usando la clave privada para generar una firma), y también debe proporcionar el saldo de ETH de esta dirección, por ejemplo, usar una Prueba de Merkle para demostrar cuánto ETH tiene esta dirección en el bloque 1001.

La dirección, la firma y la prueba de Merkle no pueden ser reveladas y son información privada (testigo privado).

Cuando se produce esta prueba, Bob puede verificar esta prueba con la Raíz de Merkle (llamada Raíz de Estado) del árbol de estado del bloque 1001. Cualquiera conoce la Raíz de Estado de cada bloque, que es información pública (entrada pública).

La única información que Bob conoce es la información pública de State Root y los resultados de verificación. No sabrá ninguna de la información privada de Alice.

△ Alice proporciona dos entradas privadas: Merkle Proof y firma; Bob proporciona la opinión pública de la raíz estatal. La declaración zk puede verificar que Alice tiene una dirección y el saldo de la dirección es > 10 ETH

(1) Verificar la firma de la transacción

La verificación de la firma de la transacción consta de dos partes: (a) el iniciador de la transacción es legítimo y (b) la firma de la transacción está firmada por el iniciador de la transacción.

(a) Principalmente para verificar que la dirección de Ethereum del iniciador de la transacción es una dirección legal y no un número aleatorio. Esto se demostrará a través de una Prueba de Merkle que la dirección existe en el árbol de estado de Ethereum.

(b) Verifica que la firma de la transacción esté firmada por la clave privada del iniciador de la transacción.

△ Esta prueba verifica (a) la dirección del remitente de la transacción (a través de la prueba Merkle de la clave pública del remitente) y (b) que la firma dentro de la transacción sea legítima (la firma se incluirá en el texto sin formato de la transacción). El texto sin formato de la transacción es la información sin procesar no encriptada de la transacción, que es la información privada proporcionada por el iniciador de la transacción.

Fuente de la imagen:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_736

Consejo de lectura: El texto rojo en la imagen de arriba se refiere a lo que significa este certificado después de pasar la verificación (es decir, "la firma de la transacción es legal"). No es parte de la declaración zk. La parte azul es información relacionada con la transacción en sí, incluidos los datos de transacciones cifrados (públicos) y los datos de transacciones no cifrados (privados). La parte verde son los datos adicionales requeridos para completar la prueba, tanto pública como privada.

△ Demuestra que la dirección del iniciador de la transacción existe en el árbol de estado de Ethereum y que el iniciador de la transacción realmente tiene la clave privada del lugar

(2) Confirme que el iniciador de la transacción tiene suficiente ETH para pagar la comisión de manejo

Al igual que en el ejemplo anterior de Alice y Bob demostrando que el saldo es > 10 ETH, el iniciador de la transacción debe proporcionar la Prueba de Merkle del saldo de su propia dirección, y la declaración a demostrar es “la saldo de la dirección ≥ la tarifa de la transacción.” La tarifa de la transacción es igual al precio del gas multiplicado por el límite de gas. Toda la información sobre el precio del gas y el límite de gas está incluida en los datos de transacción originales no cifrados (texto sin formato de tx). El texto sin formato de tx es información privada proporcionada por el iniciador de la transacción.

△ Esta prueba verifica que el saldo de la dirección del iniciador de la transacción (a través de la prueba de Merkle de saldo del remitente) es mayor o igual que la tarifa de la transacción (la información de la tarifa de la transacción está incluida en el texto sin formato de la transacción). Fuente de la imagen:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_743

△ Demostrar el equilibrio de la dirección del iniciador de la transacción > precio del gas

(3) Verifique el valor Nonce del iniciador de la transacción

Dado que el Nonce también se registra en el estado de Ethereum, la Prueba de Merkle también se utiliza para probar el valor actual de Nonce del iniciador de la transacción, y luego compararlo con el valor de Nonce especificado en la transacción para confirmar que la transacción no se ha reproducido.

△ Esta prueba compara el valor de Nonce de la dirección del iniciador de la transacción (a través de una prueba de Merkle de Nonce) y el valor de Nonce especificado por la transacción (el valor de Nonce especificado por la transacción está incluido en el texto sin formato de la transacción). Fuente de la imagen:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g19ee04031ad_0_327

△ Demostrar el nonce de la dirección del iniciador de la transacción = nonce de tx

Sin embargo, esta comprobación no puede evitar que los atacantes maliciosos generen múltiples transacciones con el mismo valor de Nonce (estas transacciones pueden superar todas la comprobación del valor de Nonce) para llevar a cabo ataques DoS, por lo que necesitamos agregar comprobaciones adicionales.

Requerimos que el iniciador de la transacción proporcione una Etiqueta de Repetición adicional para garantizar que solo habrá una transacción con el mismo valor de Nonce. La Etiqueta de Repetición es el valor hash del valor de Nonce y la clave privada del iniciador de la transacción: etiqueta de repetición = H (nonce, clave privada), por lo que diferentes valores de Nonce del mismo iniciador de la transacción corresponderán a una Etiqueta de Repetición única.

Por lo tanto, los nodos pueden usar la Etiqueta de Repetición para identificar si un iniciador de transacciones ha iniciado múltiples transacciones con el mismo valor de Nonce (las Etiquetas de Repetición de estas transacciones serán las mismas) y rechazar la segunda transacción con la misma Etiqueta de Repetición.

△ Esta prueba calculará la etiqueta de repetición y la comparará con la etiqueta de repetición proporcionada por la entrada pública. El valor de Nonce de la transacción se encuentra en el texto sin formato de la tx, y la clave privada está contenida en el testigo privado.

Fuente de la imagen:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_750

△ Demuestra que el nonce de la dirección del iniciador de la transacción = nonce de tx y etiqueta de repetición = H(nonce, clave)

O si consideramos que el iniciador de la transacción puede querer reemplazar la transacción con el mismo valor de Nonce con otra transacción, tal vez porque no quiere ejecutar la transacción original, o quiere aumentar el precio del gas para que la transacción pueda ser recogida más rápido .

En este momento, podemos introducir el valor de Slot de PoS en el cálculo de Replay Tag: replay tag = H(nonce, private key, slot). Por ejemplo, Bob envió una transacción con un Nonce de 5 en la ranura 1001 pero aún no se ha recibido, por lo que decidió duplicar el precio del gas de la transacción manteniendo otros campos sin cambios, y envió la transacción actualizada en la ranura 1005. Transacción, y debido a que la ranura ha cambiado, la etiqueta de reproducción es diferente y esta nueva transacción no se rechazará porque el valor de Nonce sea el mismo.

△ La entrada pública pasará valores de ranura adicionales para el cálculo de la etiqueta de repetición. Fuente de la imagen:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_757

5. Tamaño de transacción

Algunos métodos de cifrado harán que el tamaño de los datos de transacción cifrados sea igual al tamaño antes del cifrado. Sin embargo, todavía hay una posibilidad de deducir cierta información a través del tamaño. Por ejemplo, los datos de transacción de una transacción realizada en Uniswap deben ser mayores que los datos de transacción de una simple transferencia de ETH. Por lo tanto, el tamaño de la transacción es igual a los metadatos que pueden filtrar la privacidad.

Un enfoque intuitivo es realizar una acción de relleno en los datos de transacción antes de encriptarlos, como rellenar con un montón de ceros hasta que el tamaño de la transacción se convierta en una potencia de dos, o incluso rellenarlo todo hasta que se convierta en un tamaño fijo. Esto reduce la probabilidad de que un observador identifique una transacción por su tamaño. Block Builder combinará las transacciones rellenadas en un bloque.

△ El blanco es relleno. Los acuerdos azul y naranja son del mismo tamaño, por lo que no hay forma de distinguirlos por su tamaño. Fuente de la imagen:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_860

Sin embargo, las desventajas de este enfoque son que (1) es ineficiente porque se desperdiciará mucho espacio en el bloque en el Relleno, y (2) es posible que no proporcione suficiente protección de privacidad. Por ejemplo, el tamaño de la transacción en rojo en la imagen de arriba (cuatro cuadrados) puede ser raro, por lo que aún se puede descifrar. Si todas las transacciones se rellenan a un tamaño fijo (como 64 bloques), la privacidad mejorará, pero se convertirá en un desperdicio relativamente de espacio de bloque.

△ La desventaja es la ineficiencia y la protección limitada de la privacidad. Fuente de la imagen:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_812

Un enfoque mejor es primero rellenar las transacciones a un tamaño fijo, pero se puede utilizar el cifrado homomórfico para eliminar el relleno.

Debido a que todas las transacciones se llenan a un tamaño fijo, todas las transacciones vistas por los observadores tendrán el mismo tamaño. El Bloque Constructor puede combinar transacciones encriptadas a través de una función y eliminar el relleno al mismo tiempo.

△ Utilice cifrado homomórfico para eliminar el relleno al combinar transacciones cifradas. Fuente de la imagen:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_908

Consejo de lectura: Block Builder con confianza pura o hardware confiable puede lograr el mismo efecto sin encriptación homomórfica (después de todo, todos confían en ello).

Cómo Block Builder construye bloques eficientes

Aunque podemos combinar eficientemente transacciones cifradas en un bloque a través de cifrado homomórfico, todavía hay algunos problemas por resolver, como (1) diferentes transacciones pueden leer y escribir en el mismo estado (por ejemplo, todas operan en Uniswap), lo que puede resultar en transacciones de menor rango con más probabilidades de fallar, y (2) el constructor de bloques no puede recopilar transacciones según el nivel de comisiones de manejo.

La solución ideal es ejecutar el EVM en cifrado homomórfico, al igual que poner un EVM en una caja negra para su ejecución, para que el Constructor de Bloques pueda simular la ejecución de transacciones a través del EVM para formar el bloque más eficiente y con el mayor ingreso. Sin embargo, la complejidad técnica de esta tecnología es demasiado alta y tomará mucho tiempo realizarla.

La alternativa es adjuntar una tarifa de manipulación encriptada y una Lista de Acceso encriptada a la transacción (la Lista de Acceso se utiliza para indicar en qué estados leerá y escribirá la transacción), y usar cifrado homomórfico para verificar la validez. De esta manera, el Constructor de Bloques puede determinar el orden de ingresos de transacciones a través de las tarifas de manipulación, y usar la Lista de Acceso para evitar que las transacciones se afecten mutuamente y resulten en una eficiencia de ejecución de transacciones reducida.

△ Se determina por la tarifa de manejo y la Lista de Acceso qué transacciones se deben recopilar y en qué orden se recopilan. Fuente de la imagen:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1133

La hora en la que se produce la transacción

Si estamos preocupados de que la hora a la que se envían las transacciones cifradas a la red p2p pueda filtrar la privacidad (por ejemplo, Alice realiza transacciones a UTC+8 00:00–04:00), podemos pedir a los Validadores que envíen regularmente un montón de Transacciones Falsas cifradas para confundir al observador.

La transacción ficticia deberá estar adjunta a una prueba de conocimiento cero para demostrar que fue enviada por el Validador y limitar la frecuencia para evitar que la red se llene de Transacciones Ficticias (los observadores no sabrán que se trata de una Transacción Ficticia, solo que es “legal y válida”).

La transacción ficticia será identificada y descartada durante la operación de cifrado homomórfico del bloque del grupo.

△ Los validadores envían regularmente transacciones ficticias (grises) para confundir a los observadores, pero esto aumentará la carga en la red y los nodos. Fuente de la imagen:https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_1210

Mempools encriptados vs. FSS

El FSS en el artículo anterior también introdujo que el FSS también cifrará las transacciones primero y luego las entregará a Chainlink Oracle para su clasificación. El proceso de cifrado de transacciones por parte del FSS y la verificación de la validez de las transacciones cifradas es en realidad igual que los Mempools Cifrados, excepto:

• El cifrado de transacciones de FSS no menciona la protección de metadatos, mientras que Encrypted Mempools oculta los metadatos y utiliza una prueba de conocimiento cero para probar la validez de la transacción.
• FSS actualmente utiliza cifrado/descifrado de umbral y es descifrado conjuntamente por el Oráculo de Chainlink, lo que significa que debes confiar en el Oráculo de Chainlink. Las Memorias Transaccionales Encriptadas no especifican cómo ordenar, sino que se centran únicamente en cifrar transacciones y demostrar su validez con pruebas de conocimiento cero.
• En comparación con FSS, que solo enfatiza la "equidad", Encrypted Mempools pone más énfasis en "cómo ensamblar eficientemente el contenido del bloque y cómo permitir al Proponente ensamblar el bloque más beneficioso en lugar de decidir aleatoriamente el orden de las transacciones."

En el futuro, FSS también puede utilizar la tecnología en las Memorias Cifradas para mejorar o reemplazar sus transacciones de cifrado y descifrado.

Abordando MEV con Criptografía

Esta charla trata sobre Memorias Cifradas, donde el autor comparte cómo las técnicas criptográficas y las mejoras en la capa de consenso de Ethereum pueden ayudar a combatir los problemas causados por MEV. Para más detalles, por favor revisa:https://www.youtube.com/watch?v=mpRq-WFihz8

Resumen y aspectos destacados

1. El propósito de las Memorias Transaccionales Encriptadas es protegerse contra MEV y la censura mediante la encriptación de transacciones. Otros solo pueden saber que sus transacciones son válidas, pero no pueden saber qué acciones está realizando dentro de sus transacciones.

2. Sin embargo, para lograr una resistencia efectiva a la censura, debe utilizarse un mecanismo como la Lista de Inclusión de PBS. De lo contrario, el Constructor aún puede llevar a cabo la censura al negarse a recibir transacciones encriptadas.

3. No es fácil demostrar que una transacción encriptada es válida. Necesitas múltiples pruebas de conocimiento cero para demostrar la firma de la transacción, el valor de Nonce del iniciador de la transacción, tarifas de gestión suficientes, etc.

4. Además, es necesario evitar que metadatos como la IP, el tamaño de los datos de transacción o el tiempo de envío de la transacción revelen la privacidad de la transacción.

5. Por último, lo más importante es asegurar que las transacciones puedan ser descifradas —— Encriptación garantizada. Hay cinco métodos diferentes: Confianza pura (en vuelo), Enclave de hardware de confianza, Cifrado/Descifrado de umbral, Cifrado/Descifrado retardado y Cifrado/Descifrado de testigo. Cada método tiene sus propias ventajas y desventajas.

Datos de referencia y lecturas recomendadas

Mempools encriptadas

• https://www.youtube.com/watch?v=XRM0CpGY3sw
• https://docs.google.com/presentation/d/1eKt6nR15umuxcej8Nj-osiDm_4ZvG32FdfAqG2-1-cI/edit#slide=id.g1a0b1827f35_0_639
• Cómo la criptografía ayuda a resolver los problemas causados por MEV desde la capa de aplicación y la capa de consenso:https://youtu.be/jLHf6yw7b5Y?t=4139

Un agradecimiento especial a Steven Wu, Kimi Wu, Kevin Mai-Hsuan Chia y Anton Cheng por revisar y mejorar esta publicación.

Descargo de responsabilidad：

1. Este artículo está reimpreso de [ techflowpost]. Todos los derechos de autor pertenecen al autor original [Will 阿望；Diane Cheung]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.