¿Quién decide si una transacción de Ethereum puede ser incluida en la cadena?

La resistencia a la censura a nivel de protocolo permite que cualquier transacción que cumpla con las reglas no pueda ser excluida a largo plazo solo por las preferencias de unos pocos constructores de bloques.

En el mundo de la blockchain, a menudo escuchamos una palabra: "resistencia a la censura".

La primera reacción de muchas personas puede ser que suena como un lema político, incluso con un matiz anarquista. Pero para una red de liquidación como Ethereum, que está abierta a usuarios de todo el mundo, 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 billetera imToken.

La firma es correcta, el saldo de la cuenta es suficiente y las tarifas de Gas no son bajas, pero la transacción no se escribe en el bloque y el estado de la billetera permanece en "Pendiente", mientras que otras transacciones con tarifas similares o incluso más bajas continúan siendo incluidas en la cadena.

En este punto, 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 aún necesita que algunos participantes centralizados decidan qué transacciones pueden ser incluidas en la cadena, entonces no hay una diferencia esencial 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 y FairFIL, que intentan responder a una pregunta que parece simple, pero que es muy crítica: ¿cómo garantizar que cualquier transacción que cumpla con las reglas del protocolo tenga una oportunidad justa de entrar en un bloque?

1. ¿De dónde proviene la "censura"?

---

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

Cuando un usuario firma y envía una transacción desde su billetera, esta generalmente entra primero en el pool de transacciones públicas de Ethereum, conocido como el mempool, que es más como una sala de espera donde se almacenan muchas transacciones que aún no han sido escritas en un bloque.

Pero entrar en la sala de espera no significa que la transacción ya esté en la cadena; aún necesita que alguien seleccione las transacciones, decida su orden y forme un bloque completo para enviarlo a la red para su confirmación.

El problema surge precisamente en esta etapa.

Después de que Ethereum se actualizó al mecanismo PoS (Prueba de Participación), para evitar que grandes pools de staking utilicen MEV (Valor Máximo Extraíble) para formar monopolios económicos, Ethereum introdujo el sistema PBS (Separación de Proponente y Constructor). En esta arquitectura, el proceso de manejo de cada transacción de Ethereum se divide en dos roles:

• Constructor (Builder): responsable de recopilar transacciones, organizar el orden de las transacciones, buscar oportunidades de arbitraje y liquidación, y construir un bloque con el rendimiento más alto posible;
• Proponente (Proposer): responsable de seleccionar uno de los bloques candidatos enviados por el Constructor y enviarlo a la red;

Esta división tiene beneficios muy reales.

Como todos saben, en los últimos años, las estrategias de MEV se han vuelto cada vez más complejas. Si se requiere que cada validador común complete de manera independiente el orden de las transacciones y la optimización de bloques, sin duda permitirá que los nodos grandes con más fondos, datos y capacidades técnicas tengan ventaja.

Por lo tanto, al delegar el trabajo complejo de construcción de bloques a Constructores profesionales, los nodos de validación comunes, incluso si no tienen capacidades avanzadas de arbitraje, pueden participar en la propuesta de bloques y obtener ingresos correspondientes, lo que reduce el impacto de MEV en la descentralización del staking.

Sin embargo, esto también ha traído inadvertidamente otro efecto secundario: la concentración excesiva del derecho de construcción de bloques. Por ejemplo, actualmente más del 90% de los bloques de Ethereum son producidos solo por unos pocos Constructores profesionales, y dado que estos Constructores generalmente tienen antecedentes operativos claros, son fácilmente susceptibles a la presión externa de la conformidad legal de ciertos países o regiones (como las listas de sanciones de OFAC), lo que en realidad ya constituye un riesgo de centralización.

Por lo tanto, si estos Constructores principales eligen filtrar selectivamente ciertas transacciones de contratos sensibles (como Tornado Cash) o de direcciones específicas, estas transacciones pueden quedar atrapadas en una larga espera para ser empaquetadas, e incluso enfrentarse al riesgo de ser "bloqueadas de manera encubierta".

En resumen, desde la perspectiva de los usuarios comunes, Ethereum es una red abierta donde cualquiera puede conectarse, transferir y llamar a 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 puede tener efecto depende de si es seleccionada, ordenada y escrita en un bloque por algún constructor de bloques.

Por lo tanto, la discusión sobre la "resistencia a la censura" en Ethereum no es solo un concepto grandioso relacionado con la política, la regulación o las sanciones; primero es un problema técnico muy concreto:

Cuando una transacción cumple con las reglas del protocolo, ¿puede la red garantizar que tenga la oportunidad de entrar en un bloque en un tiempo razonable?

2. De FOCIL a FairFIL: ¿Cómo limita Ethereum a los constructores de bloques?

---

De hecho, al llegar a este punto, la cuestión ya está clara: los Constructores pueden mejorar la eficiencia de la construcción de bloques, pero si el derecho de inclusión de transacciones sigue concentrado en unos pocos Constructores, Ethereum volverá a formar un nuevo riesgo de monopolio centralizado.

Por ello, los investigadores de Ethereum han propuesto las Inclusion Lists, comúnmente conocidas como "listas de inclusión".

Este nombre suena un poco abstracto, pero su lógica central no es complicada: los Constructores siguen siendo responsables de crear bloques, pero no pueden decidir por sí solos la inclusión o exclusión de todas las transacciones; los nodos de validación que participan normalmente en el staking de Ethereum también deben retener parte del poder, permitiéndoles listar algunas transacciones que deben ser procesadas.

Tomemos como ejemplo una estación de autobuses: se puede entender un bloque como un viaje con asientos limitados.

El Constructor decide cómo se alinean la mayoría de los pasajeros y en qué asientos se sientan, aumentando así los ingresos del viaje a través de una organización más eficiente; pero los nodos de validación también pueden presentar una "lista de pasajeros obligatorios", y siempre que las transacciones en la lista sean válidas, estén dispuestas a pagar tarifas razonables y haya suficiente espacio en el bloque, el Constructor no puede simplemente rechazarlas basándose en sus propias preferencias.

Sin embargo, quién debe crear una lista de inclusión y qué hacer si alguien omite deliberadamente transacciones siguen siendo dos problemas que necesitan ser resueltos.

FOCIL y FairFIL se desarrollan precisamente en estas dos direcciones.

1. FOCIL: No permitir que un solo Proponente cree la lista de inclusión

FOCIL (Fork-Choice Enforced Inclusion Lists) transfiere el poder de decidir qué transacciones deben ser incluidas de un solo proponente a un "comité de nodos de validación" compuesto por múltiples partes.

En cada ciclo de creación de bloques, la red selecciona aleatoriamente un grupo de nodos de validación para formar un comité temporal, y cada miembro del comité observa de manera 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 la red intentan censurar una transacción, mientras haya 1 nodo honesto en el comité que incluya esa transacción en su lista, esta tendrá la oportunidad de entrar en la obligación del protocolo; si los censores quieren seguir excluyéndola, no solo tendrán que influir en una persona, sino que deberán eludir a múltiples participantes independientes.

Por lo tanto, su ventaja radica en que no es necesario confiar en que cada persona en el comité se mantenga neutral.

Pero solo tener la lista no es suficiente; si el Constructor recibe la lista y aún elige no ejecutarla, la lista de inclusión se convertirá en una recomendación sin fuerza vinculante.

Por lo tanto, FOCIL también agregó un segundo diseño, introduciendo una regla de elección de bifurcación (Fork-Choice Rule) para imponer restricciones, de modo que los nodos responsables de la votación de validación en toda la red verifiquen estrictamente el bloque presentado por el Constructor; una vez que se descubre que el Constructor se atreve a violar la lista de inclusión integrada por el comité, toda la red se negará a votar por ese bloque.

Esto significa que el bloque en violación será instantáneamente considerado un bloque inválido por el protocolo, y el Constructor pagará un alto costo por el fracaso en la creación de bloques.

2. FairFIL: No solo cubrir omisiones, sino también permitir que las omisiones sean verificables

Si FOCIL prohíbe la censura desde las reglas de consenso, FairFIL (Fair Forward Inclusion Lists) y el mecanismo de responsabilidad hacen que la censura sea extremadamente costosa e insostenible desde un punto de vista económico.

En otras palabras, plantea un requisito más avanzado, como que se debe dejar un registro que pueda ser públicamente verificado sobre por qué una transacción no fue incluida en un bloque.

En la operación real de la red, el Constructor puede necesitar un breve período de amortiguación para optimizar el orden de las transacciones y el arbitraje de MEV; FairFIL permite que el Constructor realice ajustes flexibles bajo ciertas restricciones, pero si el Constructor intenta extender algún comportamiento de censura al siguiente bloque, el protocolo activará inmediatamente un procedimiento de responsabilidad.

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 determinar qué transacciones en el pool de transacciones públicas cumplen, bajo condiciones normales, con los requisitos para entrar en el bloque actual. Si algunas transacciones que originalmente calificarían para entrar en el bloque según las reglas de referencia no son procesadas, el Builder deberá listarlas públicamente en FairFIL;
• Luego, los validadores verificarán si esta lista es completa. Si el Builder omite transacciones que cumplen con los requisitos y no las incluye en la lista, esta acción podría ser detectada y afectar si los nodos validadores apoyan ese bloque;
• Finalmente, las transacciones válidas que entren en FairFIL se convertirán en tareas prioritarias para el procesamiento en bloques posteriores. El siguiente Builder aún puede organizar su posición específica en el bloque, pero no puede actuar como si no las hubiera visto;

Si una transacción es omitida repetidamente, el bloque relacionado podría perder el apoyo de los validadores, y el Builder podría perder toda la recompensa del bloque.
En otras palabras, la "responsabilidad" enfatizada por FairFIL, en realidad, es **introducir un sistema de penalización económica escalonada. Los Builders que revisen continuamente las transacciones enfrentarán el riesgo de ser despojados de toda la recompensa del bloque, e incluso de perder su depósito de garantía.**
Esta es también la dirección en la que se profundiza el mecanismo 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 a largo plazo el acceso a las transacciones; incluso si alguien omite deliberadamente transacciones, deberá dejar un rastro y pagar un costo cada vez mayor por la revisión continua.
### ¿Qué significa esto para los usuarios comunes? --------------
Para los usuarios comunes que realizan transferencias, intercambios o utilizan DeFi a través de sus billeteras todos los días, estos mecanismos subyacentes, incluso si se implementan en el futuro, no requerirán cambios en sus hábitos operativos existentes.
Los usuarios seguirán ingresando montos en sus billeteras, confirmando el Gas, completando la firma y luego esperando que la transacción se registre en la cadena. Sin embargo, en el fondo del protocolo invisible, la lógica de si una transacción puede entrar en el bloque podría experimentar cambios importantes.
Lo que realmente mejora es la certeza del proceso de inclusión de transacciones.
* **Primero, una transacción que cumple con las reglas ya no dependerá completamente de la elección de un Builder:** incluso si el Builder actual no desea procesarla, otros validadores pueden establecer un requisito de inclusión a nivel de protocolo a través de la lista de inclusión; * **En segundo lugar, el derecho de inclusión de transacciones y el derecho de ordenación de transacciones podrían separarse gradualmente:** el Builder aún puede utilizar algoritmos especializados para organizar el orden de las transacciones y aumentar los ingresos del bloque, y aún puede competir en torno a la arbitraje y la liquidación, pero su poder para decidir "quién califica para entrar en el mercado" estará limitado;
Más allá de esto, la neutralidad confiable de Ethereum también podría pasar de ser una propuesta de valor que depende del compromiso de los participantes a convertirse en reglas de protocolo ejecutadas automáticamente por el cliente.
Los usuarios no necesitan saber qué Builder construyó el bloque actual, ni necesitan confiar uno a uno en que estos Builders mantendrán la neutralidad. Los nodos validadores verificarán el bloque según un mismo conjunto de reglas, lo que dificultará que los bloques que violen la obligación de inclusión sean reconocidos por la red.
En el futuro, las billeteras y los exploradores de bloques incluso podrían proporcionar un estado de transacción más detallado basado en esto.
Una transacción ya no solo mostrará vagamente "pendiente", sino que podría informar más a los usuarios si ya ha entrado en la lista de inclusión, si ha adquirido la obligación de inclusión en bloques posteriores, y si la espera se debe a falta de Gas, si la transacción ha caducado, o si ha habido una anomalía en la construcción del bloque.
Sin embargo, el mecanismo de resistencia a la censura no significa que cada transacción pueda tener éxito de inmediato.
Transacciones con saldo insuficiente, conflictos de Nonce, Gas demasiado bajo o condiciones de ejecución de contrato que ya han caducado aún pueden no entrar en el bloque. Cuando la red está congestionada y el espacio en el bloque es insuficiente, los usuarios aún necesitarán esperar confirmaciones a través de la competencia de tarifas.
Pero lo que mejora principalmente es que una transacción que originalmente es válida, con tarifas razonables y que ya se ha propagado al pool de transacciones públicas, no debería ser retrasada indefinidamente por la elección subjetiva de unos pocos constructores de bloques.
En términos de progreso, hasta agosto de 2026, el FOCIL correspondiente al EIP-7805 aún está en estado de borrador, pero ya ha sido seleccionado por los desarrolladores centrales de Ethereum como el Headliner de la actualización Hegotá y ha entrado en la fase de Programado para Inclusión, lo que significa que el equipo del cliente ha acordado avanzar en su implementación y desarrollo de pruebas de red, aunque la fecha exacta de lanzamiento en la red principal aún no se ha determinado.
FairFIL es aún más temprana, actualmente es principalmente un plan de investigación lanzado en julio de 2026. Si entrará en la hoja de ruta de Ethereum en el futuro, aún necesita pasar por discusiones más amplias, implementación y verificación de seguridad.
### Para concluir ----
Objetivamente hablando, Ethereum no puede garantizar que cada Builder, validador y operador de infraestructura permanezca neutral para siempre.
Los participantes pueden estar bajo presión regulatoria, pueden perseguir sus propios intereses, y también pueden aceptar incentivos externos. **Una red descentralizada verdaderamente resistente no puede basarse en la suposición ideal de que "todos harán lo correcto".**
La verdadera resistencia a la censura es que, incluso si algunos participantes intentan interferir con las transacciones, otros participantes aún tienen la capacidad de romper ese control; incluso si alguien elige desviarse del principio de neutralidad, el protocolo puede hacer que este comportamiento sea visible, costoso y difícil de mantener.
Desde la lista de inclusión inicial, hasta el FOCIL que restringe a los Builders a través de un comité distribuido, y luego al FairFIL que requiere que las omisiones sean verificables públicamente, desde permitir que cualquiera envíe transacciones, hasta garantizar que las transacciones de cualquiera tengan la oportunidad de ser vistas.
Desde esta perspectiva, Ethereum realmente está intentando llevar esta promesa, de una declaración de valor, a escribirla paso a paso en el propio protocolo.
Es algo que vale la pena esperar.

Este contenido se ofrece únicamente con fines informativos generales y no constituye asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, tradear o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.