Ethereum explora FOCIL y FairFIL para mejorar los mecanismos de anti-censura

En el mundo de la blockchain, a menudo escuchamos una palabra: «censura resistente».

Mucha gente, al escucharlo por primera vez, puede pensar que suena como un lema políticamente orientado, incluso con cierto matiz anarquista, pero para una red de liquidación abierta a usuarios globales como Ethereum, la resistencia a la censura no es primero una postura política, sino una capacidad técnica muy específica.

Imagina que inicias una transacción en tu billetera imToken.

La firma es correcta, el saldo de la cuenta es suficiente y los costos de Gas tampoco son bajos, pero la transacción no se está incluyendo en ningún bloque y el estado en la billetera sigue mostrándose como «Pending», mientras que otras transacciones con costos similares o incluso más bajos continúan siendo incluidas en la cadena.

En este punto, la pregunta se convierte en quién tiene realmente el derecho de decidir si una transacción puede ingresar a un bloque. Después de todo, si Ethereum aún requiere que algunos participantes centralizados decidan qué transacciones pueden subirse a la cadena, entonces no hay diferencia esencial con el sistema financiero tradicional.

Por lo tanto, Ethereum ha estado explorando en los últimos años una serie de mecanismos de resistencia a la censura, como FOCIL y FairFIL, intentando responder a una pregunta que parece sencilla pero es realmente fundamental: ¿cómo garantizar que cualquier transacción que cumpla con las reglas del protocolo tenga una oportunidad justa de ingresar a un bloque?

Para entender por qué Ethereum necesita estos mecanismos, primero debes comprender qué sucede después de que una transacción se envía desde una billetera.

Cuando el usuario firma y envía una transacción desde su billetera, esta generalmente entra primero en la piscina pública de transacciones de Ethereum, conocida como mempool, que actúa como una zona de espera que contiene numerosas transacciones pendientes de incluirse en un bloque.

Pero ingresar a la zona de espera no significa que la transacción ya esté en la cadena; aún se necesita que alguien seleccione las transacciones, determine su orden y las agrupe en un bloque completo para luego enviarlo a la red para su confirmación.

El problema surge precisamente en esta etapa.

Tras la actualización de Ethereum a mecanismo PoS (Proof of Stake), para evitar que grandes pools de staking aprovechen el MEV (Maximal Extractable Value) para crear monopolios económicos, Ethereum introdujo el sistema PBS (Proposer-Builder Separation, Separación entre Propositor y Constructor). En esta arquitectura, el proceso de procesamiento de cada transacción de Ethereum se divide entre dos roles:

• Constructor (Builder): se encarga de recopilar transacciones, ordenarlas, buscar oportunidades de arbitraje y liquidación, y construir un bloque que maximice los ingresos;
• Propositor: responsable de seleccionar un bloque candidato presentado por el Builder y enviarlo a la red;

Este reparto de tareas tiene beneficios muy prácticos.

Es bien sabido que, en los últimos años, las estrategias de MEV se han vuelto cada vez más complejas, y exigir que cada validador común realice independientemente la ordenación de transacciones y la optimización de bloques sin duda otorgaría ventaja a los nodos grandes con más capital, datos y capacidad técnica.

Por lo tanto, delegar la compleja tarea de construcción de bloques a builders profesionales permite que los nodos de validación comunes, incluso sin capacidad avanzada de arbitraje, participen en la propuesta de bloques y obtengan beneficios correspondientes, mitigando así el impacto del MEV en la descentralización del staking.

Pero también ha traído involuntariamente otro efecto secundario: la excesiva concentración del derecho a construir bloques. Por ejemplo, actualmente más del 90 % de los bloques de Ethereum en toda la red son producidos únicamente por unos pocos builders profesionales, y dado que estos builders suelen tener antecedentes empresariales claros, son fácilmente sujetos a presiones externas relacionadas con el cumplimiento legal de ciertos países o regiones (por ejemplo, listas de sanciones de OFAC), lo que en realidad constituye un riesgo de centralización.

Por eso mismo, una vez que estos principales Builders filtren selectivamente ciertas transacciones de contratos sensibles (como Tornado Cash) o direcciones específicas, estas transacciones quedarán atrapadas en largos períodos sin ser incluidas en bloques, e incluso correrán el riesgo de ser «baneadas implícitamente».

En resumen, para los usuarios comunes, Ethereum es una red abierta donde cualquiera puede conectarse, realizar transferencias y llamar contratos inteligentes, pero desde el punto de vista del funcionamiento del protocolo, enviar una transacción es solo el primer paso; su efectividad real depende de si un constructor de bloques la selecciona, ordena y incluye en un bloque.

Por lo tanto, la discusión sobre la "censura resistente" de Ethereum no es solo un concepto amplio relacionado con la política, la regulación o las sanciones; es primero un problema técnico muy específico:

When a transaction meets the protocol rules, can the network guarantee it an opportunity to be included in a block within a reasonable time?

De hecho, hasta aquí el problema ya está claro: Builder puede mejorar la eficiencia de la construcción de bloques, pero si el derecho a incluir transacciones permanece a largo plazo en manos de unos pocos Builder, Ethereum correrá nuevamente el riesgo de una nueva monopolización centralizada.

For this, Ethereum researchers proposed Inclusion Lists, commonly known as "inclusion lists."

El nombre suena algo abstracto, pero su lógica central no es compleja: el Builder sigue siendo responsable de crear los bloques, pero ya no puede decidir por sí solo el destino de todas las transacciones; los nodos de validación que participan normalmente en el staking de Ethereum también deben conservar cierto poder para poder listar algunas transacciones que deben ser procesadas.

Por ejemplo, tomando una parada de autobús, se puede entender un bloque como un viaje con asientos limitados.

El Builder decide cómo se organizan la mayoría de los pasajeros y en qué asientos se sientan, para aumentar los ingresos del tren mediante una asignación más eficiente; sin embargo, los nodos de validación también pueden presentar una «lista obligatoria de abordaje»: siempre que las transacciones en la lista sigan siendo válidas, estén dispuestas a pagar tarifas razonables y haya suficiente espacio en el bloque, el Builder no puede excluirlas constantemente por preferencias propias.

Sin embargo, aún son dos problemas pendientes de resolver: quién debe elaborar la lista y qué hacer si alguien omite intencionadamente una transacción.

FOCIL y FairFIL, precisamente desarrollados en estas dos direcciones.

1. FOCIL: Ya no permitir que un solo Proposer inicie una lista de inclusión

FOCIL (Fork-Choice Enforced Inclusion Lists) traslada el poder de decidir qué transacciones deben incluirse del propietario individual a un «comité de validadores» compuesto por múltiples partes.

En cada ciclo de bloqueo, la red selecciona aleatoriamente un grupo de nodos de validación para formar un comité temporal, y cada miembro del comité observa independientemente la memoria de la red y presenta su propia lista local.

Esto significa que, incluso si el 99% de los Builders y propuestos en toda la red intentan censurar una transacción, siempre que exista al menos un nodo honesto en el comité que incluya esa transacción en la lista, la transacción tendrá la oportunidad de incorporarse al protocolo. Si los censuradores desean seguir excluyéndola, ya no solo afectan a una sola persona, sino que deben eludir simultáneamente a múltiples participantes independientes.

Entonces, su ventaja es que no necesitas confiar en que cada miembro del comité sea imparcial.

Pero solo tener la lista no es suficiente; si el Builder recibe la lista y aún así elige no actuar, la lista se convierte en una sugerencia sin fuerza vinculante.

Por lo tanto, FOCIL añadió un segundo nivel de diseño, introduciendo una regla de selección de bifurcación (Fork-Choice Rule) como restricción obligatoria, para que los nodos responsables de la votación y verificación en toda la red revisen estrictamente los bloques enviados por el Builder. Si se detecta que el Builder viola la lista de inclusión integrada por el comité, toda la red rechazará directamente votar por ese bloque.

Esto significa que los bloques que incumplan las normas serán considerados inválidos instantáneamente por el protocolo, y el Builder enfrentará un gran costo por el fracaso en la generación de bloques.

2. FairFIL: No solo se trata de cubrir las brechas, sino también de garantizar que las omisiones puedan verificarse

Si FOCIL prohíbe censura de forma obligatoria mediante reglas de consenso, FairFIL (Fair Forward Inclusion Lists) y los mecanismos de rendición de cuentas hacen que la censura sea extremadamente costosa e insostenible desde una perspectiva económica.

En otras palabras, plantea requisitos aún más estrictos, como dejar registros accesibles para verificación pública sobre por qué una transacción no ingresó a un bloque.

En la operación real de la red, el Builder puede necesitar un período de buffer extremadamente corto para optimizar la ordenación de transacciones y el arbitraje MEV. FairFIL permite al Builder realizar ajustes de flexibilidad bajo restricciones específicas, pero si el Builder intenta extender cualquier comportamiento de censura al siguiente bloque, el protocolo activará inmediatamente el proceso de rendición de cuentas.

Su lógica general se puede entender en tres pasos.

• En primer lugar, el protocolo establecerá un conjunto de reglas de referencia públicas y verificables para determinar qué transacciones en la piscina pública cumplen las condiciones para incluirse en el bloque actual; si algunas transacciones que, según las reglas de referencia, tendrían derecho a incluirse en el bloque finalmente no se procesan, el Builder deberá publicarlas en FairFIL;
• Luego, el validador verificará si la lista está completa; si el Builder omitió transacciones que cumplen con los criterios y no las incluyó en la lista, esta acción podría detectarse y afectar si el nodo validador apoya o no el bloque;
• Finalmente, las operaciones válidas de FairFIL se convertirán en tareas que deben procesarse con prioridad en los bloques siguientes; el siguiente Builder aún puede determinar su ubicación exacta dentro del bloque, pero ya no puede seguir ignorándolas;

Si una transacción se omite continuamente, el bloque relevante podría perder el apoyo de los validadores, y el Builder también podría perder toda la recompensa del bloque.

En otras palabras, la "rendición de cuentas" que enfatiza FairFIL se logra mediante la introducción de sanciones económicas escalonadas, por lo que los Builders que sean revisados continuamente corren el riesgo de perder toda la recompensa del bloque e incluso su depósito de garantía.

Este también es el rumbo hacia el cual se profundiza el mecanismo de resistencia a la censura de Ethereum, con el objetivo de establecer un conjunto de restricciones más realistas, en las que incluso si unos pocos participantes tienen intención de censurar, les resulte difícil controlar el acceso a las transacciones a largo plazo; incluso si alguien omite intencionalmente transacciones, debe dejar rastros y pagar un costo cada vez mayor por la censura continua.

Para los usuarios comunes que realizan transferencias, intercambios o utilizan DeFi a través de billeteras diariamente, estos mecanismos subyacentes no requerirán cambiar sus hábitos operativos actuales, incluso si se implementan en el futuro.

El usuario aún ingresa el monto en la billetera, confirma el Gas, completa la firma y espera a que la transacción se incluya en la cadena, pero en la capa subyacente del protocolo, que no es visible, la lógica que determina si la transacción puede ingresarse en un bloque podría experimentar cambios importantes.

Lo que realmente mejora es la certeza del proceso de inclusión en la operación.

• Primero, una transacción que cumpla con las reglas ya no dependerá completamente de la elección de un Builder: incluso si el Builder actual no desea procesarla, otros validadores podrán establecer un requisito de inclusión a nivel de protocolo mediante una lista de inclusión;
• En segundo lugar, el derecho a incluir transacciones y el derecho a ordenarlas podrían separarse gradualmente: el Builder aún podrá utilizar algoritmos profesionales para ordenar transacciones y aumentar los ingresos del bloque, y aún podrá competir en torno al arbitraje y las liquidaciones, pero su poder para decidir «quiénes tienen derecho a acceder al mercado» se verá limitado;

Mirando más allá, la neutralidad confiable de Ethereum también podría pasar de ser una propuesta de valor basada en el compromiso de los participantes a convertirse en reglas de protocolo ejecutadas automáticamente por los clientes.

Los usuarios no necesitan saber qué Builder construyó el bloque actual, ni confiar individualmente en que estos Builder mantengan neutralidad activa; los nodos de validación verificarán los bloques según las mismas reglas, haciendo difícil que los bloques que incumplan las obligaciones de inclusión obtengan reconocimiento de la red.

En el futuro, la billetera y el explorador de bloques incluso podrían proporcionar estados de transacción aún más detallados.

Una transacción ya no solo se muestra genéricamente como «pendiente», sino que también puede informar al usuario si ha ingresado a la lista de inclusión, si ha obtenido la obligación de inclusión en bloques posteriores, y por qué sigue esperando: si es por gas insuficiente, si la transacción ya expiró, o si hubo un error en el proceso de construcción del bloque.

Sin embargo, el mecanismo de resistencia a la censura no significa que cada transacción tenga éxito inmediato.

Las transacciones con saldo insuficiente, conflicto de Nonce, gas demasiado bajo o condiciones de ejecución del contrato ya expiradas aún pueden no incluirse en un bloque; cuando la red está congestionada y hay escasez de espacio en los bloques, los usuarios aún deben esperar confirmación mediante competencia de tarifas.

Pero lo que mejora principalmente es una transacción que originalmente era válida, con tarifas razonables y ya propagada en la piscina de transacciones pública, y no debería verse retrasada indefinidamente por la elección subjetiva de unos pocos constructores de bloques.

En cuanto al progreso, hasta agosto de 2026, el EIP-7805 correspondiente a FOCIL sigue en estado Draft, pero ha sido seleccionado por los desarrolladores principales de Ethereum como Headliner de la capa de consenso para la actualización Hegotá y ha entrado en la fase Scheduled for Inclusion, lo que significa que los equipos de clientes han acordado avanzar con su implementación y pruebas de red, aunque la fecha exacta de lanzamiento en la cadena principal aún no se ha definido.

FairFIL es más temprano y actualmente es principalmente un proyecto de investigación programado para su lanzamiento en julio de 2026; si entrará en la hoja de ruta de Ethereum aún requiere discusiones más amplias, implementación y validación de seguridad.

Objetivamente, Ethereum no puede garantizar que cada builder, validador y operador de infraestructura mantenga neutralidad para siempre.

Los participantes pueden estar sujetos a presión regulatoria, perseguir sus propios intereses o recibir incentivos externos; una red descentralizada verdaderamente resistente no puede basarse en el supuesto ideal de que todos harán lo correcto.

La verdadera censura resistente significa que, incluso si algunos participantes intentan interferir en las transacciones, los demás aún pueden romper ese control; incluso si alguien elige desviarse de los principios de neutralidad, el protocolo hace que dicho comportamiento sea visible, costoso y difícil de mantener.

Desde la lista inicial de inclusión, hasta el FOCIL, donde un comité distribuido colectivamente regula a los Builder, y luego hasta el FairFIL, que exige que las omisiones puedan verificarse públicamente; desde permitir que cualquiera envíe transacciones, hasta garantizar que la transacción de cualquier persona tenga la oportunidad de ser vista.

Desde este punto de vista, Ethereum realmente está intentando convertir este compromiso, paso a paso, en una parte misma del protocolo.

Worth looking forward to.