La declaración de Vitalik sobre la «tecnología de refugio»: ¿Cómo incorpora Ethereum la resistencia a la censura en el protocolo?

Si algún día el equipo de desarrolladores principales de Ethereum “desapareciera” colectivamente, o un país soberano exigiera la censura de ciertas transacciones, ¿podría Ethereum seguir siendo una red abierta?

Estas preguntas parecen hipótesis extremas, pero están convirtiéndose en un referente cada vez más realista en el diseño del protocolo de Ethereum.

A principios de marzo, Vitalik Buterin propuso una nueva formulación, diciendo que la comunidad de Ethereum debería entenderse como parte de un ecosistema de “tecnologías de refugio” (sanctuary technologies): estas tecnologías de código abierto y gratuitas permiten a las personas vivir, trabajar, comunicarse, gestionar riesgos, acumular riqueza y colaborar hacia objetivos comunes, al mismo tiempo que maximizan su resistencia a presiones externas.

Esta formulación parece una actualización abstracta de valores, pero si la analizamos en el contexto de la evolución reciente del protocolo de Ethereum, en realidad se refiere a problemas de ingeniería muy concretos:

A medida que la construcción de bloques se vuelve más especializada, el control del orden de las transacciones se concentra cada vez más, y los mempools públicos son más vulnerables a ataques y reordenamientos, ¿cómo puede Ethereum mantener su línea de fondo más importante como red abierta —que las transacciones de los usuarios no sean fácilmente bloqueadas por unos pocos?

1. Vitalik crea un nuevo término: “tecnologías de refugio”

Vitalik parte de una sinceridad poco común.

No usa términos grandilocuentes como “cambiar el mundo”, sino que reconoce que, hasta ahora, las mejoras en la vida cotidiana de las personas a través de Ethereum son limitadas. Por ejemplo, la eficiencia financiera en la cadena puede haber mejorado, y el ecosistema de aplicaciones se ha enriquecido, pero muchos logros siguen en un ciclo interno del mundo cripto.

Por eso, propone una nueva forma de entender a Ethereum: en lugar de considerarlo solo una red financiera, verlo como parte de un ecosistema más amplio de “tecnologías de refugio”.

Según su definición, estas tecnologías comparten varias características: son de código abierto, gratuitas, accesibles a todos; ayudan a las personas a comunicarse, colaborar, gestionar riesgos y riqueza; y lo más importante, pueden seguir funcionando frente a presiones gubernamentales, bloqueos empresariales u otras interferencias externas.

Vitalik incluso usa una metáfora visual: un protocolo verdaderamente descentralizado debería parecer más a un martillo que a un servicio de suscripción. Cuando compras un martillo, es tuyo; no deja de funcionar porque la empresa que lo fabrica cierre, ni te aparece un mensaje diciendo “esta función ya no está disponible en tu región”.

En definitiva, si una tecnología debe cumplir una función de refugio, no puede depender de una organización centralizada que exista indefinidamente, ni dejar a los usuarios en una posición pasiva de recibir servicios.

Fuente: CoinDesk

Esto sin duda recuerda otro estándar que Vitalik ha mencionado para evaluar el valor a largo plazo de Ethereum: la prueba de salida (walkaway test), que plantea una pregunta sencilla pero profunda: si todos los desarrolladores principales de Ethereum desaparecieran mañana, ¿el protocolo seguiría funcionando normalmente?

No es solo un lema, sino un estándar de descentralización extremadamente riguroso, que no busca solo verificar si hay una narrativa descentralizadora en el presente, sino si el sistema puede sostenerse en el peor escenario posible.

Aplicado a la capa de producción de bloques, la respuesta se vuelve muy concreta: una cadena que pase la prueba de salida no puede permitir que el control de las transacciones recaiga en unos pocos, ni que las transacciones públicas sean vulnerables a reordenamientos, ataques o censura.

Este es el contexto en el que entran en discusión FOCIL y los mempools cifrados en Ethereum.

2. Resistencia a la censura en el centro del protocolo: FOCIL + mempools cifrados

Es importante analizar los problemas actuales de los mempools públicos de Ethereum.

En los últimos años, Ethereum ha avanzado hacia una mayor especialización en la construcción de bloques. Para mejorar la eficiencia y la extracción de MEV, el rol de los constructores (builders) se ha vuelto más importante. La producción de bloques ya no es un proceso en el que cada validador construye de forma independiente, lo cual tiene beneficios prácticos, pero también costos claros:

Cuando el control de la construcción de bloques se concentra en unos pocos actores poderosos, la censura deja de ser solo una posibilidad teórica. En la práctica, cualquier constructor principal puede rechazar incluir ciertas transacciones, como transferencias de direcciones sancionadas, por ejemplo Tornado Cash.

Es decir, el problema de Ethereum hoy no es solo sobre tarifas altas o capacidad de transacción, sino sobre si la infraestructura de transacciones públicas sigue siendo confiable para los usuarios comunes.

Por eso, FOCIL (Fork-Choice Enforced Inclusion Lists, listas de inclusión forzadas por la elección de bifurcación) es una respuesta positiva del protocolo a la censura. Su idea central no es complicada: mediante la introducción de un mecanismo de listas de inclusión, la decisión de si una transacción puede ser incluida en un bloque ya no dependerá únicamente de la voluntad del proponente o constructor.

Cada slot selecciona un comité de la lista de inclusión (Inclusion List Committee) entre los validadores, quienes, según lo que vean en el mempool, generan una lista de transacciones a incluir y la difunden; el proponente del siguiente slot debe construir un bloque que cumpla con esas listas, y los validadores solo votarán por bloques que las respeten.

En otras palabras, FOCIL no elimina a los constructores, sino que, mediante reglas de bifurcación, proporciona una mayor garantía de inclusión para las transacciones válidas en el mempool público. Esto permite que los constructores sigan optimizando el orden y maximizando MEV, pero sin tener la última palabra sobre qué transacciones son legítimas para entrar en un bloque.

Aunque controvertido, FOCIL ha sido confirmado como una propuesta central en la próxima gran actualización Hegotá (Estado de especificación congelada para la inclusión), prevista para después de la actualización Glamsterdam, en la segunda mitad de 2026.

Sin embargo, FOCIL no resuelve otro problema igualmente importante: antes de que una transacción entre en un bloque, ¿ya ha sido vista por todo el mercado? Los buscadores de MEV pueden hacer frontrunning, sandwich attacks y reordenamientos, especialmente en transacciones DeFi, lo que significa que, incluso sin censura, los usuarios pueden ser víctimas de ataques previos a la inclusión en el bloque.

Este es el origen de los ataques de tipo sandwich (sandwich attack).

Las principales soluciones en discusión actualmente son LUCID (propuesta por investigadores de la Fundación Ethereum, Anders Elowsson, Julian Ma y Justin Florentine) y EIP-8105 (Mempool cifrado universal). El equipo de EIP-8105 anunció recientemente su apoyo total a LUCID, y ambos grupos colaboran en ello.

El núcleo de los mempools cifrados es:

• Cuando un usuario envía una transacción, su contenido se cifra;
• La transacción solo se descifra cuando se incluye en un bloque y alcanza cierta confirmación;
• Hasta entonces, los buscadores no pueden ver la intención de la transacción, evitando ataques de sandwich o frontrunning;
• Así, el mempool público vuelve a ser “seguro y usable”.

Como dicen los investigadores, ePBS (propuesta de separación entre ejecutores y constructores) + FOCIL + mempools cifrados conforman la “Trinidad Santa contra la censura”, un esquema completo de defensa sistémica en toda la cadena de suministro de transacciones.

Actualmente, FOCIL ha sido confirmado para Hegotá; la propuesta de mempool cifrado (LUCID) está en proceso de ser incluida como otra propuesta destacada en Hegotá.

3. ¿Qué significa todo esto?

Si ampliamos la perspectiva, FOCIL y los mempools cifrados no son solo términos en una lista de mejoras técnicas de Ethereum, sino una señal:

Ethereum está reorientando la “resistencia a la censura” al centro del diseño del protocolo.

Aunque en la industria blockchain se habla mucho de “descentralización”, cuando una transacción es realmente censurada, bloqueada o desaparece de la red, la mayoría de los usuarios se dan cuenta de que la descentralización nunca fue un estado predeterminado, sino algo que se debe luchar mediante el código del protocolo.

Ya el 20 de febrero, Vitalik escribió que el mecanismo FOCIL tiene una sinergia importante con la propuesta de abstracción de cuentas de Ethereum, EIP-8141 (basada en EIP-7701). Esta propuesta eleva las cuentas inteligentes (multisig, firmas resistentes a la computación cuántica, cambios de clave, patrocinio de gas, etc.) a “ciudadanos de primera clase”, permitiendo que sus operaciones se empaqueten directamente como transacciones en la cadena, sin necesidad de envoltorios adicionales.

Algunos podrían cuestionar: ¿vale la pena que FOCIL aumente la complejidad del protocolo y que los mempools cifrados puedan reducir la eficiencia?

Aquí radica la verdadera importancia de las “tecnologías de refugio”: el valor único de blockchain no solo está en poner activos en la cadena o acelerar transacciones, sino en si puede seguir ofreciendo una salida digital sin permisos, difícil de cerrar o de quitar, en entornos de alta presión.

Desde esta perspectiva, el significado de FOCIL y los mempools cifrados es claro: transformar elementos que dependían de la buena voluntad, del equilibrio del mercado y de la esperanza de que “no pase nada”, en reglas de protocolo más sólidas.

Cuando millones de usuarios puedan vivir, trabajar, comunicarse, gestionar riesgos y acumular riqueza en esta “isla digital estable”, sin temor a ser expulsados o censurados por entidades centralizadas, entonces Ethereum habrá pasado verdaderamente la “Prueba de salida”.

Y esa, precisamente, es la máxima finalidad de las tecnologías de refugio.