En el mundo de la cadena de bloques, a menudo escuchamos una palabra: 'resistencia a la censura'.
La primera reacción de muchas personas puede sonar como un eslogan algo politizado, incluso con matices anarquistas, pero para una red de liquidación global y abierta como Ethereum, la resistencia a la censura no es primero una postura política, sino una capacidad técnica muy concreta.
Imagina que inicias una transacción en tu cartera imToken.
La firma es correcta, el saldo de la cuenta es suficiente, la tarifa de gas no es baja, pero la transacción tarda en ser escrita en el bloque, el estado en la cartera permanece en 'Pendiente', mientras que otras transacciones con tarifas similares o incluso más bajas se incluyen continuamente en la cadena.
Entonces, la pregunta se convierte en: ¿quién tiene el derecho de decidir si una transacción puede entrar en un bloque? Después de todo, si Ethereum finalmente aún necesita unos pocos participantes centralizados para decidir qué transacciones se incluyen en la cadena, entonces no hay una diferencia fundamental con el sistema financiero tradicional.
Por lo tanto, en los últimos años Ethereum ha estado explorando una serie de mecanismos de resistencia a la censura como FOCIL, FairFIL, tratando de responder una pregunta que parece simple, pero en realidad es crucial: ¿cómo garantizar que cualquier transacción que cumpla las reglas del protocolo tenga una oportunidad justa de entrar en un bloque?
I. ¿De dónde viene realmente la 'censura'?
Para entender por qué Ethereum necesita estos mecanismos, primero hay que aclarar qué le sucede a una transacción después de ser enviada desde la cartera.
Cuando un usuario firma y envía una transacción en la cartera, esta transacción generalmente ingresa primero al grupo de transacciones pública de Ethereum, también conocido como mempool (pool de memoria), que es más como una zona de espera que contiene una gran cantidad de transacciones aún no escritas en un bloque.
Pero entrar en la zona de espera no significa que la transacción ya esté en la cadena; aún necesita que alguien seleccione las transacciones, decida su orden, forme un bloque completo y luego lo entregue para la confirmación de la red.
El problema surge precisamente en esta etapa.
Después de que Ethereum se actualizó al mecanismo de PoS (Prueba de Participación), para evitar que los grandes pools de staking utilicen el MEV (Valor Máximo Extraíble) para formar un monopolio económico, Ethereum introdujo el sistema PBS (Separación entre Proponente y Constructor). Bajo esta arquitectura, el flujo de procesamiento de cada transacción de Ethereum se divide en realidad en dos roles responsables:
- Constructor (Builder): responsable de recopilar transacciones, ordenarlas, buscar oportunidades de arbitraje y liquidación, y construir un bloque con el mayor rendimiento posible;
- Proponente (Proposer): responsable de seleccionar uno de los bloques candidatos presentados por los Constructores y proponerlo a la red;
Esta división del trabajo tiene beneficios muy prácticos.
Como es sabido, en los últimos años las estrategias de MEV se han vuelto cada vez más complejas. Si se requiriera que cada validador común complete de forma independiente la ordenación de transacciones y la optimización del bloque, sin duda daría una ventaja a los nodos grandes con más capital, datos y capacidades técnicas.
Por lo tanto, al asignar el trabajo complejo de construcción de bloques a Constructores profesionales, los nodos validadores comunes, incluso sin capacidades avanzadas de arbitraje, pueden participar en la propuesta de bloques y obtener los beneficios correspondientes, mitigando así el impacto del MEV en la descentralización del staking.
Solo que también ha traído involuntariamente un efecto secundario: la concentración excesiva del poder de construcción de bloques. Por ejemplo, actualmente más del 90% de los bloques de Ethereum en toda la red son producidos por solo unos pocos Constructores profesionales, y dado que estos Constructores suelen tener antecedentes empresariales con entidades claramente identificables, son extremadamente susceptibles a presiones externas de cumplimiento legal de países o regiones específicas (por ejemplo, las listas de sanciones OFAC), lo que en realidad ya constituye un riesgo de centralización.
También por esta razón, una vez que estos pocos Constructores principales filtran selectivamente transacciones de ciertos contratos sensibles (como Tornado Cash) o direcciones específicas, estas transacciones pueden quedar atrapadas en una situación en la que no se pueden incluir durante mucho tiempo, e incluso enfrentar el riesgo de ser 'prohibidas implícitamente'.
En resumen, desde la perspectiva del usuario común, Ethereum es una red abierta a la que cualquiera puede conectarse, transferir fondos y llamar contratos inteligentes, pero desde el punto de vista del funcionamiento del protocolo, enviar una transacción es solo el primer paso; si la transacción realmente surte efecto depende de si es seleccionada, ordenada e incluida en un bloque por un constructor de bloques.
Por lo tanto, la 'resistencia a la censura' discutida en Ethereum no es solo un concepto grandioso relacionado con la política, la regulación o las sanciones; es primero un problema técnico muy concreto:
Cuando una transacción cumple las reglas del protocolo, ¿puede la red garantizar que tenga la oportunidad de entrar en un bloque dentro de un tiempo razonable?
II. De FOCIL a FairFIL: Cómo Ethereum restringe a los constructores de bloques
De hecho, hablando hasta este punto, el problema ya está muy claro: los Constructores pueden mejorar la eficiencia de la construcción de bloques, pero si el poder de inclusión de transacciones también se concentra a largo plazo en unos pocos Constructores, Ethereum volvería a formar un nuevo riesgo de monopolio centralizado.
Para ello, los investigadores de Ethereum propusieron Inclusion Lists, comúnmente conocidas como 'listas de inclusión'.
Este nombre puede sonar abstracto, pero su lógica central no es complicada: el Constructor sigue siendo responsable de crear el bloque, pero no puede decidir por sí solo el destino de todas las transacciones; los nodos validadores que participan normalmente en el staking de Ethereum también deben conservar una parte del poder, permitiéndoles enumerar algunas transacciones que deben procesarse.
Usando la analogía de una estación de autobuses, se puede entender un bloque como un viaje con asientos limitados.
El Constructor decide cómo hacen cola la mayoría de los pasajeros y en qué asiento se sientan, para así aumentar los ingresos del viaje completo mediante una disposición más eficiente; pero los nodos validadores también pueden presentar una 'lista de pasajeros obligatorios'. Mientras las transacciones en la lista sigan siendo válidas, estén dispuestas a pagar una tarifa razonable y haya suficiente espacio en el bloque, el Constructor no puede rechazarlas indefinidamente basándose únicamente en sus propias preferencias.
Sin embargo, quién elabora exactamente una lista de inclusión y qué hacer si alguien omite intencionalmente transacciones siguen siendo dos problemas que requieren solución.
FOCIL y FairFIL se desarrollan precisamente en estas dos direcciones.
1. FOCIL: Ya no dejar que un solo Proponente elabore la lista de inclusión solo
FOCIL (Listas de Inclusión Impuestas por la Regla de Elección de Bifurcación) traslada el poder de decidir si una transacción debe incluirse obligatoriamente de un único proponente a un 'comité de nodos validadores' compuesto por múltiples partes.
En cada ciclo de creación de bloques, la red selecciona aleatoriamente un grupo de nodos validadores para formar un comité temporal. Cada miembro del comité observa de forma independiente el mempool de la red y presenta su propia lista de inclusión local.
Esto significa que incluso si el 99% de los Constructores y Proponentes de toda la red intentaran censurar una transacción, siempre que exista 1 nodo honesto en el comité que incluya esa transacción en su lista, esta transacción tendrá la oportunidad de entrar en la restricción del protocolo. Si los censores quieren continuar excluyéndola, ya no será solo afectar a una persona, sino que tendrán que eludir a múltiples participantes independientes simultáneamente.
Por lo tanto, su ventaja radica en que no es necesario confiar en que cada persona en el comité mantenga la neutralidad.
Pero tener una lista no es suficiente; si el Constructor, después de recibirla, decide no cumplirla, la lista de inclusión se convertiría en una recomendación sin fuerza vinculante.
Por ello, FOCIL añade un segundo diseño, introduciendo una regla de elección de bifurcación (Fork-Choice Rule) como restricción dura, haciendo que los nodos de toda la red responsables de votar y validar verifiquen estrictamente el bloque presentado por el Constructor. Una vez que se descubre que un Constructor se atreve a violar la lista de inclusión integrada por el comité, toda la red rechazará directamente votar por ese bloque.
Esto significa que el bloque infractor será instantáneamente declarado inválido por el protocolo, y el Constructor pagará un alto precio por el fracaso en la creación del bloque.
2. FairFIL: No solo cubrir omisiones, sino hacer que las omisiones puedan verificarse
Si FOCIL prohíbe duramente la censura desde las reglas de consenso, entonces FairFIL (Listas de Inclusión Justa Adelantada) con su mecanismo de responsabilidad, lo hace desde una perspectiva económica, haciendo que el comportamiento de censura sea extremadamente costoso e insostenible.
En pocas palabras, plantea un requisito aún más avanzado: por ejemplo, debería dejarse, en la medida de lo posible, un registro públicamente verificable de por qué una transacción no entró en un bloque.
En el funcionamiento real de la red, un Constructor puede necesitar un período de amortiguación extremadamente corto para optimizar el orden de las transacciones y el arbitraje de MEV. FairFIL permite al Constructor realizar ajustes flexibles bajo restricciones específicas, pero si intenta prolongar un comportamiento de censura hasta el siguiente bloque, el protocolo iniciará inmediatamente un procedimiento de rendición de cuentas.
Su lógica general se puede entender en tres pasos.
- Primero, el protocolo establecerá un conjunto de reglas de referencia públicas y verificables para juzgar qué transacciones en el grupo de transacciones público cumplen las condiciones para entrar en el bloque actual en circunstancias normales. Si ciertas transacciones que, según las reglas de referencia, originalmente calificaban para entrar en el bloque finalmente no se procesan, el Constructor deberá incluirlas públicamente en la FairFIL;
- Posteriormente, los validadores verificarán si esta lista está completa. Si el Constructor omitió transacciones elegibles y no las incluyó en la lista, entonces este comportamiento puede ser detectado y afectar si los nodos validadores apoyan ese bloque;
- Finalmente, las transacciones válidas que ingresen a la FairFIL se convertirán en tareas prioritarias para los bloques posteriores. El siguiente Constructor aún puede organizar su posición específica dentro del bloque, pero no puede seguir fingiendo no verlas;
Si una transacción se omite continuamente, los bloques relacionados pueden perder el apoyo de los validadores, y el Constructor también puede perder los ingresos de todo el bloque por ello.
En otras palabras, la 'rendición de cuentas' enfatizada por FairFIL es en realidad a través de la introducción de sanciones económicas escalonadas. Un Constructor que continúe censurando transacciones enfrentará el riesgo de perder toda la recompensa del bloque, e incluso de que su depósito de staking sea incautado.
Esta es también la dirección en la que avanzan gradualmente los mecanismos de resistencia a la censura de Ethereum, con el objetivo de establecer un conjunto de restricciones más realistas. Incluso si unos pocos participantes tienen intenciones de censura, será difícil controlar la entrada de transacciones a largo plazo; incluso si alguien omite intencionalmente una transacción, tendrá que dejar un rastro y pagar un precio cada vez más alto por la censura continua.
III. ¿Qué significa esto para el usuario común?
Para el usuario común que realiza transferencias, intercambios o usa DeFi a través de su cartera todos los días, incluso si estos mecanismos subyacentes se implementan en el futuro, no será necesario cambiar los hábitos operativos existentes.
El usuario todavía completará el monto en la cartera, confirmará el gas, finalizará la firma y luego esperará a que la transacción se incluya en la cadena. Pero en la base subyacente del protocolo, que no se ve, la lógica de si una transacción puede entrar en un bloque podría cambiar significativamente.
Lo que realmente mejora es la certeza del proceso de inclusión de transacciones.
- Primero, una transacción que cumpla las reglas ya no dependerá completamente de la elección de un Constructor específico: incluso si el Constructor actual no quiere procesarla, otros validadores pueden, a través de la lista de inclusión, establecer un requisito de inclusión a nivel de protocolo para ella;
- En segundo lugar, el poder de inclusión de transacciones y el poder de ordenación de transacciones podrían separarse gradualmente: el Constructor aún puede usar algoritmos profesionales para organizar el orden de las transacciones y aumentar los ingresos del bloque, y aún puede competir en torno al arbitraje y la liquidación, pero su poder para decidir 'quién califica para entrar al mercado' se verá limitado;
Yendo un paso más allá, la neutralidad confiable de Ethereum también podría pasar gradualmente de ser una propuesta de valor que depende del compromiso de los participantes a convertirse en una regla de protocolo ejecutada automáticamente por el cliente.
El usuario no necesita saber qué Constructor construyó el bloque actual, ni necesita confiar uno por uno en que estos Constructores mantendrán activamente la neutralidad. Los nodos validadores verificarán los bloques de acuerdo con el mismo conjunto de reglas, haciendo que los bloques que violen las obligaciones de inclusión tengan dificultades para obtener el reconocimiento de la red.
En el futuro, las carteras y los exploradores de bloques incluso podrían proporcionar estados de transacción más detallados basados en esto.
Una transacción ya no mostrará simplemente de manera general 'Pendiente', sino que podría informar al usuario si ya ha entrado en una lista de inclusión, si ha obtenido una obligación de inclusión para bloques posteriores, y si la espera continua se debe a gas insuficiente, a que la transacción ya es inválida o a una anomalía en el proceso de construcción del bloque.
Sin embargo, los mecanismos de resistencia a la censura no significan que cada transacción pueda tener éxito inmediatamente.
Las transacciones con saldo insuficiente, conflictos de Nonce, gas demasiado bajo o condiciones de ejecución de contrato ya inválidas aún podrían no entrar en un bloque. Cuando la red esté congestionada y el espacio del bloque sea insuficiente, los usuarios aún tendrán que esperar la confirmación compitiendo con las tarifas.
Pero lo que principalmente mejora es que una transacción originalmente válida, con tarifas razonables y que ya se ha difundido al grupo de transacciones público, no debe ser retrasada indefinidamente debido a la elección subjetiva de unos pocos constructores de bloques.
En cuanto al progreso, hasta agosto de 2026, el EIP-7805 correspondiente a FOCIL aún se encuentra en estado de Borrador, pero ya ha sido seleccionado por los desarrolladores principales de Ethereum como el punto destacado (Headliner) de la capa de consenso para la actualización Hegotá, y ha entrado en la fase de 'Programado para Inclusión', lo que significa que los equipos de clientes han acordado avanzar en su implementación y desarrollo de pruebas de red, pero el tiempo específico de implementación en la red principal aún no se ha determinado finalmente.
FairFIL está en una etapa aún más temprana, actualmente es principalmente una propuesta de investigación publicada en julio de 2026. Si en el futuro se incorporará a la hoja de ruta de Ethereum, aún requerirá una discusión más amplia, implementación y verificación de seguridad.
Para concluir
Hablando objetivamente, Ethereum no puede garantizar que cada Constructor, validador y operador de infraestructura mantenga siempre la neutralidad.
Los participantes pueden estar bajo presión regulatoria, pueden perseguir sus propios intereses o pueden aceptar incentivos externos. Una red verdaderamente descentralizada y resiliente no puede construirse sobre la suposición ideal de que 'todos harán lo correcto'.
La verdadera resistencia a la censura consiste en que, incluso si algunos participantes intentan interferir con las transacciones, otros participantes aún tengan la capacidad de romper ese control; incluso si alguien elige desviarse del principio de neutralidad, el protocolo pueda hacer que ese comportamiento sea visible, costoso y difícil de sostener.
Desde las listas de inclusión iniciales, pasando por FOCIL que restringe a los Constructores mediante un comité distribuido, hasta FairFIL que exige que los comportamientos de omisión puedan verificarse públicamente, desde permitir que cualquiera envíe una transacción, hasta garantizar que la transacción de cualquiera tenga la oportunidad de ser vista.
Desde esta perspectiva, Ethereum ciertamente está intentando escribir este compromiso, paso a paso, desde una declaración de valores hasta el protocolo mismo.
Es digno de esperar.
