MEV-Boost, el protocolo de sidecar actual para la extracción de MEV en Ethereum, depende en gran medida de actores centralizados llamados repetidores.

Proponemos una arquitectura alternativa que permite la comunicación directa y criptográficamente privada entre constructores y proponentes. Se basa en una forma novedosa y no interactiva de cifrado de umbral "silencioso" que puede utilizar los pares de claves BLS existentes de los validadores.

Básicamente, nos aprovechamos del comité de certificación para la privacidad y disponibilidad de datos mediante el cifrado de propuestas de bloque a una fracción de certificadores para la ranura. Sus certificaciones forman la clave de desencriptación; una vez que se ha certificado el umbral deseado, se puede desencriptar el bloque.

Nuestra construcción aborda la privacidad entre los constructores y los proponentes, pero no garantiza por sí sola la validez del bloque. Puede combinarse con otros mecanismos para reproducir completamente las funcionalidades proporcionadas por los repetidores, tanto la privacidad como la validez del bloque. Por ejemplo, esquemas de prueba como pruebas de Entorno de Ejecución Confiable (TEE) o pruebas de conocimiento cero (ZK), o mecanismos criptoeconómicos para colateralizar los constructores.

Al eliminar la necesidad de repetidores para proporcionar privacidad al constructor y garantizar la validez del bloque, nuestro objetivo es reducir la latencia y mejorar la descentralización y resistencia a la censura de Ethereum.

MEV-Boost y el papel de los Repetidores

MEV-Boost es un protocolo auxiliar que intermedia entre los constructores de bloques y los proponentes. El papel principaldel repetidor es proporcionar dos garantías:

• Privacidad para los constructores: El repetidor asegura que los proponentes no pueden ver el contenido del bloque y robar el MEV encontrado por el constructor.
• Seguridad para los proponentes: El repetidor garantiza que el constructor pague el valor prometido al proponente en la oferta del constructor y que el bloque sea válido (por ejemplo, todas las transacciones pagan gas intrínseco).

La dependencia de los repetidores, sin embargo, introduce una centralización significativa. Aproximadamente el 90% de los bloques en Ethereum se entregan a través de solo un puñado de repetidores. Esto plantea algunos riesgos:

• Centralización: Los constructores pueden ser eficientes en cuanto a latencia al colocarse junto a repetidores en lugar de reflejar la distribución geográfica de los proponentes. Esto socava directamente la descentralización geográfica y la resistencia a la censura que de otro modo obtendríamos de un conjunto de validadores grande y distribuido a nivel mundial.
• Ingresos: La latencia promedio de procesamiento de bloques de extremo a extremo de los repetidores eficientes es de aproximadamente 5-20 milisegundos. Luego, hay una latencia de comunicación entre el proponente y el generador. Saltarse los repetidores reducirá la latencia, disminuirá los riesgos de ejecución entre dominios (por ejemplo, CEX/DEX) y, en última instancia, aumentará las recompensas de MEV de los proponentes.

TEE-Boost

Una de las propuestas líderes para reemplazar repetidores es “TEE-Boost“, que se basa en TEE (Entornos de Ejecución Confiables). Tenga en cuenta que los TEE no son esenciales para nuestro esquema; es solo útil utilizar TEE-Boost como un ejemplo pedagógico de los problemas que pretendemos resolver.

Concretamente, TEE-Boost permite a los constructores utilizar TEE para crear pruebas que demuestren a los proponentes la honestidad de sus ofertas y la validez de sus bloques sin revelar el contenido real de los bloques a los proponentes. Los proponentes pueden verificar estas pruebas sin ejecutar los TEE ellos mismos en hardware de consumo.

Sin embargo, TEE-Boost tiene un problema de disponibilidad de datos: los constructores solo comparten pruebas TEE y encabezados de bloque con los proponentes, no el contenido real del bloque,^[1]y puede optar por no liberar el contenido del bloque incluso después de que el proponente firme el encabezado (por ejemplo, si las condiciones del mercado cambian desfavorablemente). Los enfoques sugeridos para resolver este problema de DA son:

• [ ] TEE-Escrow: Un TEE-escrow recibe el bloque del constructor antes de que el proponente lo firme y lo libera una vez que ven el encabezado firmado.
• [ ] Capas de Disponibilidad de Datos: Los constructores publican cargas de bloques cifrados en una capa de Disponibilidad de Datos (DA).

Ambos enfoques tienen inconvenientes. La solución de custodia TEE replica la dinámica de latencia de centralización similar a la de los repetidores existentes.^[2]El uso de una capa DA externa introduce una suposición extra-protocolo y conlleva la dinámica de latencia de ese protocolo externo (que también es probablemente desfavorable).

1. En teoría, si los proponentes también tuvieran acceso a TEEs, los constructores podrían cifrar sus bloques en un TEE ejecutado por el proponente. El TEE del proponente solo desencriptaría el bloque después de que lo hubieran firmado. Sin embargo, creemos que TEE-Boost no considera este diseño porque requeriría que los proponentes (validadores) ejecuten TEEs. Queremos que los validadores puedan ejecutarse en hardware estándar.↩

2. La dinámica de latencia se puede evitar si los proponentes mismos ejecutan TEE-Escrow como un sidecar ubicado junto a su nodo validador. Sin embargo, nuevamente, no queremos que los validadores ejecuten TEEs.↩

Criptografía de umbral para lograr privacidad de constructor

Proponemos una solución elegante al problema DA de TEE-Boost: cifrado de umbral al comité de atestadores. Específicamente, el umbral del constructor cifra el bloque a una fracción especificada del comité de atestadores para ese slot. Una vez que se recopilan suficientes atestaciones, el bloque se vuelve descifrable y disponible.

La tecnología habilitadora central esCifrado de umbral silencioso. Esta técnica criptográfica permite el cifrado de umbral sin requerir una fase interactiva de Generación de Clave Distribuida (DKG), que las construcciones anteriores requerían. En cambio, la clave pública conjunta se calcula de manera determinista a partir de las claves públicas BLS ya existentes del atestador más algunos "indicios" (discutidos más adelante).

Esto logra una comunicación directa de un salto entre el constructor y el validador con privacidad criptográfica. No se requiere que los validadores ejecuten ellos mismos TEEs ni que administren ningún material de clave nuevo.

Mecánica:

El constructor construye un bloque y lo encripta al comité de atestadores.

El constructor construye una prueba de TEE que demuestra tres cosas al comité del atestador: que la oferta es honesta, el bloque es válido y está encriptado correctamente.

El constructor comunica el bloque cifrado del umbral y la prueba TEE (que incluye el valor de la oferta) al proponente.^[3]

El proponente firma el bloque cifrado del constructor ganador y divulga esta propuesta al conjunto de validadores.

Una vez que la fracción especificada (por ejemplo, n/2 o 2n/3) del comité de atestadores n para la ranura atestigua el bloque, este se descifra.

El bloque descifrado continúa con la finalización normalmente.

1. El efecto en los requisitos de ancho de banda del proponente necesitaría ser estudiado. Los proponentes de bajo ancho de banda podrían limitar las necesidades verificando pruebas antes de solicitar el cuerpo del bloque, o con otras técnicas de filtrado heurístico y descarga inteligente. Esta es una pregunta abierta, pero parece probable que no sea más difícil de resolver que los problemas normales de spam de la mempool.↩

Consideraciones

Rendimiento

Las características de rendimiento del cifrado de umbral silencioso son bastante favorables. Aquí

n es el tamaño máximo del comité que deseamos apoyar y t es el umbral para la descifrado.

Tanto el cifrado como el descifrado parcial son de tiempo constante. Con una implementación ingenua, el cifrado toma <7 ms, y esto se puede paralelizar. El descifrado parcial toma <1 ms.

El tamaño del texto cifrado es un factor aditivo constante, 768 bytes, más grande que el texto plano (para cualquier n y t).

La agregación de desencriptaciones parciales (es decir, desencriptación) depende del tamaño del comité. Con n=1024, una implementación ingenua tarda menos de 200 ms. Esperamos que con n=128 (el tamaño del comité de certificación para cada ranura), esto se reduzca en un factor de 10 y que la implementación pueda ser optimizada aún más.

Es importante destacar que el tiempo de cifrado es el número clave de rendimiento para comparar con la latencia del repetidor. Esto es lo que el constructor debe calcular en la "ruta crítica" de la producción de bloques. Es menor que la latencia de procesamiento de bloques del repetidor existente y evita la comunicación multi-salto.

Publicación de Datos

El cifrado de umbral silencioso no es completamente gratuito. Sí requiere una cadena de referencia común de la forma: (g,g^τ,g^τ2,...,g^τn−t) similar to what’s used for the KZG polynomial commitment scheme.

Además, cada validador con una clave pública BLS de la forma gsk publica un conjunto de elementos de grupo que llamamos "pistas": (g)^sk⋅τ,...,g^sk⋅τn−t). Estas pistas solo son necesarias para agregar claves públicas y descifrar textos cifrados. La encriptación solo utiliza una clave pública agregada de tamaño constante.

Al momento de escribir esta publicación, hay aproximadamente 1 millón de validadores. Si establecemos n=128 y t=n/2, cada validador necesita publicar ≈ 3 KB de pistas. Por lo tanto, almacenar las pistas de todos los validadores requiere 3 GB.

Este requisito probablemente disminuirá sustancialmente con el tiempo.activación de MaxEB, lo que permite a los validadores que controlan >32 ETH mantener saldos más grandes bajo el mismo par de claves (en lugar de dividirlos en múltiples depósitos de 32 ETH). La reducción en el conjunto de validadores que se logrará está en debate. Parece posible que podamos llegar a ~1GB.

Por último, dependiendo de los futuros cambios en la arquitectura de consenso de Ethereum (por ejemplo, reducciones adicionales en el tamaño del conjunto de validadores o el enrutamiento alternativo de la finalidad), el tamaño de las pistas que deben almacenarse podría disminuir aún más.

Vivacidad

Ethereum quiere permanecer activo incluso en condiciones adversas de red. Un problema con este esquema es la posibilidad de bloques que no se pueden descifrar porque la fracción especificada del comité está desconectada.

Una solución es permitir que el constructor decida sobre la fracción aceptable (𝑡) del comité para el descifrado. Existe un equilibrio entre la privacidad (la posibilidad de desagrupación y robo de MEV) y la probabilidad de que el umbral del comité esté en línea. Es maximizar los ingresos para los constructores incluir sus bloques, en lugar de ser separados, por lo que deben determinar una configuración de umbral optimizada.^[4]

Además, el uso de este esquema de cifrado debería ser opcional. En condiciones de red adversas, en las que no haya un comité de un tamaño aceptable disponible de manera constante, los proponentes y constructores podrían recurrir a utilizar repetidores, autocompilación, o cualquier otro mecanismo que sea preferible dado el tipo de entorno adverso.

1. La afirmación específica aquí es que es EV negativo para un bloque del constructor ser bifurcado (no reciben ingresos de él), y altamente negativo EV para ser desagregado. Si le das al constructor la capacidad de elegir t en [0,128], deberían estar naturalmente incentivados a seleccionar t lo suficientemente alto como para que haya muy bajo riesgo de desagregación y alta probabilidad de estar satisfechos (al menos t miembros del comité estén en línea). Algunos bloques probablemente serían bifurcados incluso bajo condiciones normales de red, pero señalaríamos que esto ya sucede con los juegos de sincronización, y la viabilidad de la cadena sigue siendo aceptable.↩

Bloques no disponibles

Alternativamente, el comité puede estar en línea, pero un constructor puede ser capaz de crear una situación en la que el bloque no pueda ser descifrado o sea inválido al descifrarlo (por ejemplo, con pruebas fraudulentas).

Desde la perspectiva del protocolo, está bien bifurcar estos bloques. El conjunto de validadores más amplio simplemente no podía dar fe de ellos ni de ningún bloque que hiciera referencia a ellos. Es probable que la mejor manera de manejar este tipo de error sea hacer que el cliente de consenso sea consciente de la posibilidad y pueda fallar con gracia. Se necesitarían más estudios sobre cómo se necesitaría exactamente.

Estructura del mercado

El constructor ganador conoce el contenido del bloque antes que otros hasta que se alcance el umbral, lo que podría crear una ventaja injusta en los espacios posteriores. Sin embargo, se supone que el comité de validadores debe actuar antes del final del siguiente espacio, y la mayoría del valor del bloque está al final del espacio, por lo que los efectos de esta ventaja deberían ser lo más mínimos posibles.

Pruebas puramente criptográficas

A largo plazo, puede ser posible reemplazar las pruebas TEE con pruebas de conocimiento cero (ZK). Actualmente, las pruebas ZK son demasiado lentas, pero los avances en criptografía, software y hardware especializado (ASIC) podrían eventualmente hacer que la generación de pruebas ZK sea factible dentro de las restricciones de latencia necesarias. Es importante destacar que las pruebas ZK que acompañan a los bloques ya son un Parte fundamental del plan a largo plazo de Ethereum.

Adopción

Con el tamaño actual del conjunto de validadores y la tasa de crecimiento, este esquema puede no valer la cantidad de datos que se requiere publicar en L1. Sin embargo, Ethereum ya planea reducir sustancialmente el recuento de conjuntos de validadores con MaxEB.

La mejor aproximación probablemente sería una actualización junto o después de MaxEB en la que los clientes de consenso sean conscientes de la posibilidad de semántica de bloques encriptados y se anime a los validadores a publicar pistas. Por ejemplo, después de MaxEB, podría ser necesario que los validadores recién ingresados publiquen pistas, y a los validadores más antiguos se les podría dar un incentivo para actualizar.

Los constructores comenzarían a usar el mecanismo una vez que una fracción suficiente del conjunto de validadores lo adoptara para tener un tamaño de comité suficiente (es decir, una privacidad aceptable y una probabilidad de descifrado).

Si nuestro enfoque realmente tiene una latencia favorable en comparación con la repetición de múltiples saltos, el mercado debería adoptarlo sin necesidad de que el protocolo imponga el uso o consagre una parametrización específica.

Razón

Los repetidores son una de las fuentes más significativas de centralización en Ethereum, creando oportunidades para buscar alquiler y distorsionar la descentralización geográfica del protocolo.

Necesitamos quitar los relés y creemos que esta es una forma relativamente elegante de hacerlo. Requiere cambios en la capa de consenso, pero no se requiere nuevo hardware o material clave por parte de los validadores.

El inconveniente es que es un cambio complejo en la capa de consenso para un mecanismo que (si se opta por él, como se sugiere) puede o no ser adoptado por el mercado. Sin embargo, muchos cambios potenciales en el flujo de MEV plantean preguntas similares de adopción y optimización de ingresos (por ejemplo, listas de inclusión). Y puede haber otros casos de uso futuros que dependan de que el conjunto de validadores tenga disponible una infraestructura de cifrado de umbral.

Descargo de responsabilidad：

1. Este artículo se reproduce de [ paradigma]. Todos los derechos de autor pertenecen al autor original [.Charlie NoyesGuru, Vamsi Policharla]. Si hay objeciones a esta reimpresión, por favor contacte alAprendizaje de la puertaequipo y lo manejarán rápidamente.
2. Descargo de responsabilidad por 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.