Futuros de Ethereum II: resistencia a la censura

Este artículo sobre los futuros de Ethereum explora su lucha continua por la resistencia a la censura, examinando el impacto de la presión regulatoria, el papel de la separación entre proponentes y constructores (PBS) y posibles soluciones como los mempools cifrados para mantener la red neutral y descentralizada.

Ethereum ha adoptado la estructura PBS para mitigar los riesgos de centralización de las ganancias de MEV. En este sistema, los proponentes de bloques (nodos validadores regulares) delegan la construcción de bloques a constructores especializados, quienes optimizan el orden de las transacciones para maximizar la extracción de MEV. Luego, el proponente selecciona y firma el bloque más rentable antes de transmitirlo a la red.

MEV-Boost, un mecanismo de subasta de bloques fuera de la cadena, se utiliza ampliamente en Ethereum hoy en día para facilitar este proceso. MEV-Boost permite a los constructores especializados presentar ofertas a los proponentes, compitiendo para que sus bloques sean incluidos. Si bien el conjunto de validadores de Ethereum sigue siendo altamente descentralizado, construir un bloque, especialmente uno optimizado para MEV, es complejo y requiere muchos recursos. Dada esta alta carga computacional y de infraestructura, es más eficiente centralizar la construcción de bloques y mantener descentralizada la certificación de bloques.

Este es el principio básico de PBS: distribuye de manera justa una parte de las ganancias de MEV entre los validadores mediante la subasta que se lleva a cabo en cada bloque, al tiempo que garantiza que los validadores generales (incluidos los participantes locales) no se vean agobiados por las complejidades de la construcción de bloques. Al aislar esta función especializada, PBS preserva la descentralización de la red Ethereum en su conjunto y, al mismo tiempo, optimiza la eficiencia de la producción de bloques.

Sin embargo, dado que los desarrolladores exitosos requieren recursos significativos y un flujo de transacciones privilegiado, solo unos pocos ganan subastas de manera consistente. Algunos desarrolladores mantienen su dominio estableciendo acuerdos exclusivos con billeteras específicas, aplicaciones descentralizadas y proveedores de flujo de órdenes, lo que garantiza el acceso a transacciones de alto MEV que les dan una ventaja competitiva en las subastas de bloques. Como resultado, la competencia entre desarrolladores disminuye con el tiempo, lo que conduce a una estructura oligopólica.

En la actualidad, aproximadamente el 90 % de los bloques de Ethereum se construyen mediante MEV-Boost, y solo dos entidades (Beaverbuild y Titan Builder) construyen el 95 % de estos bloques. Esta concentración genera inquietudes sobre la resistencia a la censura, la equidad de las transacciones y la descentralización a largo plazo de la producción de bloques de Ethereum.

Aunque las interrupciones o el comportamiento malicioso de estos desarrolladores no afectan significativamente la seguridad de la red Ethereum, sí representan una amenaza grave para la resistencia a la censura. Si todos los desarrolladores de MEV-Boost deciden censurar las transacciones de usuarios específicos, esos usuarios solo podrán enviar transacciones a través de bloques producidos por validadores que no utilicen MEV-Boost, lo que representa aproximadamente el 10 % del total. Como resultado, procesar dichas transacciones tomaría un promedio de 10 bloques (aproximadamente 2 minutos).

Esta situación plantea dos cuestiones importantes:

1. Vulnerabilidades regulatorias

En primer lugar, podría hacer que Ethereum sea más vulnerable a las regulaciones. Por ejemplo, las sanciones a Tornado Cash impuestas por la OFAC en 2022 llevaron a que un número significativo de desarrolladores y validadores censuraran las transacciones asociadas con cuentas sancionadas por la OFAC.

2. Competencia desleal en protocolos como las subastas

En segundo lugar, la censura puede distorsionar los resultados de las subastas en cadena. Por ejemplo, considere una subasta en la que se vende un NFT al mejor postor en cada bloque. Un constructor de bloques podría censurar todas las demás ofertas y, al mismo tiempo, realizar una oferta muy baja, lo que le permitiría adquirir el NFT a un precio significativamente reducido.

Han surgido varias soluciones para abordar estos problemas. En este artículo, analizaremos estas soluciones en dos categorías principales y analizaremos qué forma podría adoptar la resistencia a la censura en el futuro de Ethereum.

Posible solución 1: Lista de inclusión

Antecedentes: Propuesta de lista de inclusión inicial, EIP-7547

La lista de inclusión es una solución que resiste la censura y que garantiza que determinadas transacciones se incluyan en un bloque. Normalmente, se puede implementar de la siguiente manera:

He aquí un modelo mental sencillo: antes de que un constructor construya un bloque, el proponente envía una orden con una 'Lista de inclusión' que indica: "Incluir estas transacciones en el bloque". Los constructores deben incluir estas transacciones en el bloque que crean y, si se construye un bloque sin las transacciones en la Lista de inclusión, se considera inválido.

En el caso de Ethereum anterior a PBS, el mempool, donde se almacenan las transacciones antes de ingresarlas en los bloques, se incluía en Ethereum como un componente no consensuado. Por lo tanto, desde la perspectiva de la capa de consenso de Ethereum, no se sabía de dónde provenían las transacciones contenidas en los bloques.

Una de las principales razones por las que MEV condujo a la censura es que mempool es un componente sin consenso, por lo que los desarrolladores que crearon el bloque tenían autoridad completa sobre qué transacciones censurar o incluir en el bloque.

Las listas de inclusión introducen un mecanismo que utiliza múltiples validadores para actuar como un "grupo de memoria en cadena" en la capa de consenso. De esta manera, la capa de consenso limita lo suficiente la autoridad de los desarrolladores para seleccionar transacciones y ofrecer resistencia a la censura.

Una de las propuestas más destacadas para la implementación de una Lista de Inclusión fue la EIP-7547 , Lista de Inclusión de Reenvío. Esta propuesta permitía a un proponente incluir hasta 16 transacciones en la Lista de Inclusión. El mecanismo de "reenvío" garantizaba que la Lista de Inclusión propuesta para el bloque N se aplicaría al bloque N+1.

Esta propuesta inicialmente estaba destinada a ser parte de la actualización Pectra de Ethereum, pero finalmente fue excluida y una de las razones fueron problemas de compatibilidad entre el mecanismo de reenvío y EIP-3074 .

EIP-3074 introduce una forma de abstracción de cuenta nativa que utiliza un código de operación llamado AUTHCALL, que permite que una cuenta ajuste los saldos de varias EOA (cuentas de propiedad externa). Este mecanismo puede debilitar fácilmente la lista de inclusión.

Por ejemplo, supongamos que Alice incluye una transacción (A) en la Lista de inclusión, donde su EOA envía ETH a Bob. Al mismo tiempo, crea otra transacción (B) utilizando AUTHCALL de EIP-3074 para transferir todos los saldos de su EOA a una cuenta diferente. Supongamos que la transacción B está incluida en el bloque N, mientras que la transacción A está incluida en la Lista de inclusión para el bloque N+1.

Aquí está el problema clave: cuando el proponente crea la Lista de inclusión, no sabe qué transacciones incluirá el generador en el bloque actual. En este escenario, la transacción B en el bloque N invalida la transacción A. En consecuencia, el generador del bloque N+1 no podría construir un bloque válido debido a la invalidez de la transacción A en la Lista de inclusión.

Se han hecho intentos para resolver este problema a través de restricciones adicionales dentro de la Lista de inclusión. Sin embargo, el problema central sigue siendo el mismo: EIP-3074 permite de manera inherente manipular los saldos en otras EOA. Las comprobaciones simples, como verificar la dirección "De", no pueden detectar interferencias entre las transacciones de la Lista de inclusión y otras transacciones. Esto se denomina el problema de disponibilidad de datos gratuitos, mencionado en el artículo "No Free Lunch - a new inclusion list design".

Aunque EIP-3074 se excluyó de la actualización de Pectra, se incluyó una funcionalidad similar, EIP-7702. Como resultado, estos problemas deben resolverse antes de que se pueda implementar EIP-7547 en la red principal de Ethereum.

Además, la EIP-7547 enfrentó desafíos adicionales, como la limitación de que solo un proponente podía crear una lista de inclusión por bloque. Estos factores dificultaron la aplicación de la EIP-7547 a la red principal de Ethereum tal como está. En consecuencia, la EIP-7547 fue excluida de la actualización de Pectra.

Foco

¿No hay solución para estos problemas? Recientemente, una solución llamada FOCIL (Fork-choice enforced Inclusion Lists) ha ganado una atención significativa dentro del ecosistema Ethereum y se considera una de las soluciones más probables para implementarse en la red principal de Ethereum. Propuesta como EIP-7805 , FOCIL introduce un mecanismo en el que no solo una sino varias entidades proponen listas de inclusión. Sus detalles y características son los siguientes:

En esencia, FOCIL adopta el concepto de lista de inclusión, lo que significa que alguien crea una lista de transacciones que deben incluirse en cada bloque y los proponentes deben incorporarlas. Sin embargo, FOCIL difiere de EIP-7547 en dos aspectos importantes:

1. En lugar de un proponente, un comité IL de 16 miembros propone independientemente Listas de Inclusión.
2. La Lista de Inclusión propuesta para el bloque N está incluida en el propio bloque N, no en el bloque N+1.

Detalles del mecanismo

La construcción de la Lista de Inclusión para el bloque N comienza cuando comienza la ranura para el bloque N-1. Un comité IL seleccionado al azar de 16 validadores recibe el bloque N-1, lo establece como su cabeza, construye sus respectivas Listas de Inclusión y las propaga a través de peer-to-peer.

El proceso de construcción finaliza 9 segundos después del intervalo N-1 de 12 segundos, después del cual el comité ya no puede agregar nada a la lista. Una vez que haya recibido estas listas a través de la red P2P, el constructor del bloque N debe incluirlas durante la construcción del bloque. Poco después del inicio del intervalo N, el bloque se entrega al proponente.

Los validadores que verifican el bloque N comparan las transacciones en las listas de inclusión que recibieron anteriormente con aquellas incluidas en el bloque N para garantizar el cumplimiento.

Ventajas de FOCIL sobre EIP-7547

En comparación con el EIP-7547 propuesto anteriormente, FOCIL ofrece los siguientes beneficios:

1. Mayor resistencia a la censura

Cada espacio implica un comité de IL de 16 validadores que construye la Lista de Inclusión. Esto proporciona una mayor resistencia a la censura que EIP-7547, donde solo un único validador era responsable.

2. Implementación perfecta

Al utilizar la API estándar forkChoiceUpdate utilizada por los clientes de consenso, las listas de inclusión se pueden integrar de manera más sencilla y fluida en el protocolo.

3. Resistencia a la censura en “tiempo real”

A diferencia de EIP-7547, donde la Lista de Inclusión propuesta para el bloque N+1 causa un retraso, FOCIL incluye la IL en el propio bloque propuesto para N, permitiendo que las transacciones se incorporen sin retraso.

Esta construcción simultánea de bloques y listas de inclusión garantiza la compatibilidad con mecanismos de abstracción de cuentas propuestos anteriormente, como EIP-3074 o EIP-7702. Los bloques anteriores no pueden invalidar transacciones en la lista de inclusión.

Los constructores reciben el IL antes de finalizar la construcción del bloque, lo que les permite excluir cualquier transacción que invalide el IL. Este proceso es sencillo: los constructores registran el nonce y el saldo de todos los EOA involucrados en el IL y actualizan estos valores cada vez que se producen cambios. Este método simple permite a los constructores verificar la validez de las transacciones del IL y completar la construcción del bloque con éxito.

Papel de FOCIL en los bloqueos

FOCIL permite hasta 16 listas de inclusión por bloque, y cada lista tiene un tamaño máximo de 8 KB (8192 bytes). Si no hay superposición en las transacciones propuestas por las 16 listas de inclusión, el tamaño máximo de las transacciones IL en un solo bloque podría alcanzar los 128 KB. Esta limitación está diseñada para minimizar el uso de recursos por parte de los validadores a medida que las listas de inclusión se propagan a través de la red P2P.

Entonces, ¿cuánto de un bloque de Ethereum podría construirse usando ILs bajo FOCIL? Históricamente, el tamaño promedio de un bloque de Ethereum ha sido de alrededor de 80-100 KB, con un máximo de aproximadamente 300 KB. Si no hay superposición en las transacciones propuestas por las 16 Listas de Inclusión, es teóricamente posible construir un bloque de Ethereum completo usando solo transacciones IL.

Sin embargo, este escenario es poco probable. Dado que las transacciones en la Lista de inclusión generalmente provienen del mempool público, existe una alta probabilidad de superposición a menos que los 16 miembros del comité de IL utilicen configuraciones completamente diferentes.

En resumen, se espera que las transacciones en las Listas de Inclusión de FOCIL ocupen entre el 6-10% y hasta el 100% de un bloque de Ethereum, con casos que se acercan al rango del 6-10% siempre que los miembros del comité de IL estén mirando el mismo mempool público.

Más allá de FOCIL: Combinando APS con FOCIL

Antecedentes de APS

Una de las razones por las que FOCIL se ha convertido en una solución líder es su potencial sinergia con las propuestas de separación entre el certificador y el proponente (APS), como los tickets de ejecución . ¿Qué es APS y cómo complementa a FOCIL?

APS propone separar los roles de proponente y certificador de bloques.

En Ethereum, la construcción de bloques bajo PBS implica dividir los roles entre los proponentes, que proponen bloques, y los constructores, que construyen el contenido de los bloques. Esto evita que los grupos de participación centralizados formados por alianzas entre proponentes y constructores monopolicen las ganancias de MEV y registren APR mucho más altos que los validadores regulares, lo que podría centralizar las operaciones de validación.

Este problema se resolvió mediante MEV-Boost y se propuso un sistema de retransmisión dentro del protocolo (ePBS) para abordar las preocupaciones restantes sobre la centralización. Sin embargo, ¿es PBS realmente la estructura óptima?

Una función fundamental de la capa de consenso de Ethereum es distribuir recompensas e imponer sanciones a los validadores. Si este proceso se centraliza, la cadena se verá afectada por entidades centralizadas, independientemente de los votos de los validadores. Por lo tanto, la capa de consenso debería seguir estando altamente descentralizada.

Sin embargo, la capa de ejecución no tiene las mismas restricciones. Tareas como la extracción de MEV y el ordenamiento de transacciones son inherentemente complejas y estratégicas, y requieren entidades centralizadas. Si estas tareas se impusieran a todos los validadores, la cadena se encaminaría hacia la centralización.

En este sentido, la filosofía de Ethereum es que “los participantes del consenso no deben verse incentivados a realizar tareas complejas para obtener beneficios individuales”.

A través de PBS, Ethereum separa a los validadores de los actores de MEV (constructores, buscadores) para distribuir las ganancias de MEV de manera uniforme en toda la red.

Aun así, los proponentes pueden emplear estrategias no convencionales para obtener beneficios adicionales:

1. Colusión entre proponentes y constructores

Los constructores ya están centralizados, pero los proponentes también muestran cierta centralización. Por ejemplo, Coinbase posee aproximadamente el 10 % del total de ETH en stake. Si Coinbase se confabulara con un constructor específico para aceptar solo sus bloques, esto introduciría un vector de centralización significativo en el ecosistema.

2. Juegos de cronometraje de proponentes

El tiempo de bloque relativamente largo de 12 segundos de Ethereum introduce una dinámica interesante llamada juegos de tiempo, donde los proponentes retrasan la publicación del bloque para maximizar las ganancias de MEV.

El MEV disponible en un bloque generalmente aumenta de manera lineal con el tiempo. Los proponentes pueden retrasar la propagación del bloque para maximizar su MEV y publicar justo antes de correr el riesgo de ser rechazados por el siguiente proponente.

Entonces, ¿cuánto puede retrasar un proponente la publicación de un bloque en un solo espacio (12 segundos)? Según las especificaciones del protocolo de Ethereum, para que el próximo proponente considere válido el bloque anterior, el bloque debe recibir votos del 40% de los validadores (certificadores) asignados al comité del espacio anterior.

En la red principal actual de Ethereum, el momento en el que se recibe el 40 % de los votos del validador se produce aproximadamente 3,8 segundos después del inicio del proceso.

Un proponente que intente jugar con el tiempo adoptaría una estrategia de retrasar la publicación del bloque tanto como sea posible, esperando hasta recibir suficientes votos (40% o más) para evitar el rechazo del siguiente proponente.

Sin embargo, el resultado no siempre coincide con las intenciones del proponente. Si el bloque no recibe el 40% de los votos, el siguiente proponente lo rechazará. En tales casos, los validadores que votaron por el bloque rechazado habrán votado por un bloque que no forma parte de la cadena canónica, lo que dará lugar a penalizaciones de reducción.

Si esta situación persiste, los validadores pueden retrasar sus votaciones para observar el estado de la red y asegurarse de que sus votos sean precisos. Este comportamiento puede aumentar la cantidad de reorganizaciones en la cadena.

En resumen, los juegos de tiempo de los proponentes pueden afectar negativamente los resultados del consenso de Ethereum y deben evitarse.

Papel de la APS

APS es la solución diseñada para abordar este problema. APS propone crear un proponente independiente para la capa de ejecución, separando por completo la capa de consenso de MEV.

Por ejemplo, una de las propuestas representativas de APS, Execution Ticket, introduce un "proponente de ejecución" distinto del proponente de la cadena de balizas. En este sistema, el protocolo genera y vende tickets de ejecución, que otorgan a sus titulares el derecho a ser seleccionados aleatoriamente como proponentes de ejecución para cada bloque. Estos proponentes de ejecución asumirán las partes del rol que actualmente desempeñan los proponentes de la cadena de balizas en MEV-Boost, recibiendo cargas útiles de ejecución y proponiéndolas.

La razón detrás de este diseño es que la centralización de los proponentes de ejecución no es problemática; de hecho, separarlos de la capa de consenso mejora el sistema general.

Entonces, ¿qué tareas manejaría el proponente de la cadena de balizas bajo APS?

Además de gestionar los depósitos, las recompensas y las penalizaciones del validador (transiciones de estado dentro de la cadena de balizas), el proponente de la capa de consenso tiene un papel clave adicional en APS: construir listas de inclusión y pasarlas a la capa de ejecución.

Es más conveniente que la lista de inclusión dependa del conjunto de validadores descentralizados de la capa de consenso en lugar de los proponentes de ejecución relativamente más centralizados. Esto ayuda a reducir la probabilidad de que los atacantes de censura se confabulen con los proponentes para censurar las transacciones.

Por lo tanto, las propuestas de APS como Execution Ticket sugieren un mecanismo en el que los validadores de la capa de consenso construyen listas de inclusión como parte del bloque de baliza. Estas listas luego sirven como base para que el proponente de la ejecución construya y proponga el bloque completo.

En resumen, las soluciones de resistencia a la censura basadas en listas de inclusión se alinean perfectamente con la visión de Ethereum para APS. En consecuencia, FOCIL se considera una de las soluciones más prometedoras para la resistencia a la censura.

Ventajas de FOCIL

FOCIL garantiza una resistencia efectiva a la censura mientras mantiene el uso de los recursos de la red en niveles razonables al limitar cada IL a 8 KB y tener un comité IL de 16 validadores (que es el mismo que el tamaño de un blob).

El gráfico que aparece a continuación ilustra cuánto tiempo tarda una transacción en incluirse en la cadena, dependiendo del porcentaje de validadores honestos en el comité IL. Incluso si solo el 15 % de los validadores del comité no censuran, las transacciones pueden incluirse inmediatamente. Esto demuestra cómo un pequeño comité de 16 validadores puede lograr una resistencia eficiente a la censura.

Posible solución 2: Múltiples proponentes/constructores concurrentes

¿Qué tal si permitimos que varios participantes propongan un bloque completo juntos? Este concepto se conoce como "Proponente simultáneo múltiple".

En lugar de que una sola entidad proponga un bloque a la vez, varias entidades proponen bloques simultáneamente para el mismo espacio.

En determinadas condiciones, la adopción de una solución de este tipo puede aumentar significativamente el coste de la censura. Ethereum tiene un mecanismo en el que se revelan simultáneamente los proponentes de 32 bloques en cada época. Esta configuración permite escenarios en los que alguien podría intentar "sobornar" a los proponentes para que censuren transacciones específicas. Pero ¿qué sucedería si los bloques no los propusiera una persona, sino N proponentes simultáneamente? En este escenario, el empleo de un mecanismo como las propinas condicionales permite introducir un "dilema del prisionero" entre los N proponentes, lo que aumenta drásticamente el coste de la censura.

Por ejemplo, imaginemos una situación en la que N proponentes tienen la tarea de crear un bloque, Alice les pide que incluyan su transacción y Bob intenta censurar la transacción de Alice. Alice puede ofrecer un soborno a los proponentes para que incluyan su transacción, mientras que Bob también puede sobornarlos para que la censuren. En esta situación, Alice puede adoptar una estrategia de soborno que aumente efectivamente el costo de censura de Bob, de la siguiente manera:

1. Si dos o más proponentes incluyen la transacción, Alice da una pequeña propina de t a cada uno de ellos.
2. Si sólo un proponente incluye la transacción, Alice le da una gran propina de T a ese proponente.

En este caso, los proponentes se encuentran en una situación similar a la del "dilema del prisionero". La estrategia óptima para cada proponente en este juego es incluir la transacción en lugar de censurarla. Para que Bob censure con éxito la transacción de Alice, tendría que sobornar a todos los N proponentes, lo que le costaría NT. Por otro lado, Alice solo necesita gastar como máximo Nt para asegurarse de que se incluya su transacción. Esto aumenta significativamente el costo de la censura.

Este concepto se puede implementar sobre PBS de varias maneras. Por ejemplo, varios proponentes podrían construir bloques simultáneamente, o varios constructores podrían construir bloques simultáneamente.

Esta sección presenta dos mecanismos para lograr esto dentro de la estructura del PBS:

1. BRAID - Proponente concurrente múltiple
2. BuilderNet - Múltiples constructores simultáneos

TRENZA

Descripción general de BRAID

BRAID es una solución resistente a la censura de Ethereum propuesta por Max Resnick, quien formó parte del Grupo de Mecanismo Especial.

El mecanismo se basa en un concepto simple pero poderoso: en lugar de ejecutar una sola cadena como lo hace Ethereum ahora, k cadenas LMD-GHOST sincronizadas se ejecutarían en paralelo. En otras palabras, con BRAID, k proponentes producirían simultáneamente sus propios bloques para cada ranura.

Cómo funciona BRAID

Surge una pregunta obvia: ¿cómo se procesan los k bloques? Dado que los bloques deben finalmente consolidarse en uno solo para mantener una única cadena de bloques, BRAID utiliza una regla de ordenación predefinida para fusionarlos.

Por ejemplo, los bloques podrían fusionarse eliminando los duplicados y ordenando las transacciones en orden descendente de tarifas. El bloque finalizado contendría entonces las transacciones consolidadas y ordenadas.

Ventajas y limitaciones

BRAID ofrece varias ventajas:

1. Fuerte resistencia a la censura

Al permitir que varios proponentes trabajen simultáneamente, BRAID aumenta significativamente el costo de la censura, ya que sería necesario sobornar a múltiples entidades.

2. Orden de transacción forzada

El mecanismo define explícitamente el orden de las transacciones, lo que lo hace adecuado para aplicaciones como subastas en cadena en tiempo real que son sensibles al orden de las transacciones.

Tenga en cuenta que esto no siempre es una ventaja, ya que evita que ciertas aplicaciones implementen sus reglas de secuenciación específicas de la aplicación.

Sin embargo, BRAID también tiene una limitación. Dado que todas las cadenas k deben permanecer sincronizadas, los validadores requieren recursos de red adicionales. Esto va en contra del objetivo de Ethereum de reducir los requisitos de los validadores.

Constructor Net

Descripción general de BuilderNet

BuilderNet es una solución propuesta por Flashbots para aumentar la resistencia a la censura al permitir que múltiples entidades actúen como constructores de bloques simultáneamente.

La versión inicial de BuilderNet implementa un modelo de múltiples operadores, en el que varias entidades operan un único constructor siguiendo diferentes pautas regulatorias. Esto garantiza una mayor resistencia a la censura en comparación con un constructor de un solo operador. BuilderNet representa un paso hacia la creación de una solución de múltiples constructores simultáneos.

La primera versión de BuilderNet es operada conjuntamente por Flashbots, Beaverbuild y Nethermind, y hay planes para incorporar más constructores en el futuro.

Planes futuros de descentralización para BuilderNet

El modelo actual de múltiples operadores aún aparece como un único constructor para los observadores externos, lo que limita el nivel de resistencia a la censura que puede lograr. Las futuras versiones de BuilderNet apuntan a descentralizar aún más su red y mejorar la resistencia a la censura a través de los siguientes cambios:

1. Intercambio de flujo de pedidos entre constructores

Las versiones futuras de BuilderNet descentralizarán el proceso de creación de bloques, lo que permitirá que un constructor recoja las transacciones censuradas por otro constructor. En teoría, mientras exista al menos un constructor que no censure, todas las transacciones de los usuarios podrán seguir incluyéndose en un bloque. Se espera que este enfoque convierta a BuilderNet en un verdadero modelo de constructor concurrente múltiple.

2. Infraestructura descentralizada

La versión actual de BuilderNet se basa en una infraestructura centralizada para el ingreso de transacciones y el almacenamiento de datos, y la participación requiere permiso. Las versiones futuras tienen como objetivo solucionar este problema haciendo que BuilderNet no requiera permiso.

TEE para una mejor experiencia de usuario y experiencia de usuario

BuilderNet también crea un entorno más fácil de usar para aplicaciones, billeteras, buscadores y usuarios al aprovechar entornos de ejecución confiables.

TEE garantiza que el software se comporte como se especifica en función de la confianza en el hardware, lo que evita que los desarrolladores omitan datos o modifiquen el código de manera arbitraria. Al usar BuilderNet, los buscadores obtienen mayores garantías al enviar paquetes a los desarrolladores, ya que TEE hace cumplir la ejecución de la lógica de distribución de recompensas para los buscadores que contribuyen a la construcción de bloques. Si la lógica de distribución de recompensas es lo suficientemente justa, esto proporcionará a los buscadores garantías económicas comparables a los contratos formales con los desarrolladores.

Además de los buscadores, las aplicaciones y las billeteras que apuntan a capturar MEV también pueden beneficiarse de la arquitectura de BuilderNet.

BuilderNet en L2

Un aspecto destacable de BuilderNet es su potencial aplicabilidad a soluciones de Capa 2.

Las capas 2 de Ethereum están desarrollando activamente sistemas de prueba y arquitecturas de validación descentralizadas para heredar la seguridad de Ethereum. Si bien estos sistemas garantizan la seguridad de los fondos de los usuarios en los puentes, no heredan la resistencia a la censura de Ethereum.

El mecanismo de transacción forzada para transacciones L1 a L2 actualmente demora entre 12 y 24 horas como máximo (según el diseño) para incluir transacciones en L2, lo que no proporciona resistencia a la censura en tiempo real.

Al subcontratar la construcción de bloques a BuilderNet, las L2 podrían lograr una mayor resistencia a la censura que los secuenciadores individuales y, al mismo tiempo, permitir la redistribución de MEV a través de un ordenamiento de transacciones forzado con TEE, similar a arquitecturas como Unichain.

Conclusión

Lo ideal sería que las cadenas de bloques resistieran la censura, y la comunidad Ethereum ha propuesto varias soluciones para abordar los problemas de resistencia a la censura causados por la centralización de los desarrolladores. Entre las soluciones más prometedoras se encuentra FOCIL, donde 16 validadores proponen listas de inclusión para cada bloque, lo que ofrece una resistencia eficiente a la censura y compatibilidad con APS. Se espera que se discuta la inclusión de FOCIL en la actualización de Fusaka programada para fines de 2025 o principios de 2026.

Simultáneamente, se están llevando a cabo debates sobre modelos de creación simultánea de múltiples constructores liderados por Flashbots. La descentralización de los constructores podría mejorar significativamente la resistencia a la censura de Ethereum y podría implementarse independientemente del desarrollo central de Ethereum, lo que permitiría una adopción más rápida.

A través de estas iniciativas, Ethereum avanza de manera constante hacia una capa de ejecución creíblemente neutral, donde ninguna entidad individual tiene una influencia indebida sobre la inclusión de transacciones. Al combinar las listas de inclusión impulsadas por validadores de FOCIL con la posible descentralización de los creadores de bloques, Ethereum puede mejorar su resiliencia contra la censura y, al mismo tiempo, mantener la eficiencia y la equidad en la distribución de MEV. A medida que estas soluciones evolucionan, la red continúa defendiendo sus principios básicos de descentralización, acceso sin permisos y neutralidad, lo que garantiza que Ethereum siga siendo una capa de liquidación sólida y resistente a la censura para el futuro.

Una versión de este artículo fue publicada originalmente aquí .