64. Ese es el parámetro MAX_FRAMES propuesto en EIP‑8141, un número que convierte una transacción monolítica de Ethereum en una secuencia por la que el protocolo puede ir paso a paso. Señala un modelo post‑EOA: la validación, la aprobación de gas y la ejecución ya no están fusionadas en un único bloque, sino orquestadas fotograma a fotograma. El diseño abre espacio para la abstracción nativa de cuentas, esquemas de firma poco convencionales y pagos de gas flexibles, y es el sustrato sobre el que montarían la próxima generación de la UX de las carteras y la privacidad on‑chain. Sin embargo, aunque el mecanismo existe en el papel, la actualización Hegotá está liderada actualmente por una apuesta diferente: la inclusión obligatoria.
Frame Transactions refactoriza una transacción en hasta 64 marcos
EIP‑8141 define un nuevo tipo FRAME_TX que descompone una acción de usuario en marcos discretos, cada uno con un rol específico: un marco de validación para comprobar la intención y la autorización, un marco de aprobación de gas para resolver quién paga y bajo qué reglas, y un marco de ejecución para aplicar los cambios de estado. La propuesta establece MAX_FRAMES = 64 y adjunta costos explícitos por marco, de modo que flujos de trabajo complejos puedan dividirse en pasos acotados y medidos en lugar de recurrir a soluciones alternativas de contratos a medida.
El beneficio funcional es la abstracción nativa de cuentas. En lugar de fijar de forma rígida el modelo de cuenta de propietario externo y ECDSA, los marcos permiten que los monederos y los contratos especifiquen esquemas de firma personalizados, roten claves o migren a firmas resistentes al post‑cuántico sin depender de una L2 ni de un relayer de terceros. Las abstracciones de pago de gas también se vuelven de primera clase: el usuario puede definir políticas en el protocolo sobre quién paga y cómo, desde modelos de patrocinio hasta reglas multi‑activo, codificadas como un marco y no como un acuerdo fuera de la cadena.
Para las herramientas de privacidad, los marcos importan porque separan la lógica de prueba y autorización de las escrituras que cambian el estado. Un monedero podría validar una prueba de conocimiento cero bajo el esquema que elija en un solo marco, aprobar el gas en otro y luego confirmar la transferencia privada en el marco de ejecución. El protocolo obtiene una coreografía estándar y verificable; los equipos de aplicaciones no están obligados a replicar contratos de envoltorio para cada nuevo caso de uso.
Todo esto sigue dependiendo de la inclusión en una actualización de red. Y aquí, las prioridades de Hegotá sitúan la inclusión antes de la refactorización.
El principal atractivo de Hegotá es la inclusión obligatoria, no la privacidad
En su actualización para desarrolladores del 10 de abril de 2026, la Fundación Ethereum confirmó que FOCIL (EIP‑7805) es el headliner de Hegotá. Las Listas de Inclusión Forzada mediante Fork‑Choice son un mecanismo de consenso y de ejecución destinado a garantizar la inclusión oportuna de transacciones, mitigando la censura a nivel de constructores que puede dejar transacciones varadas silenciosamente fuera de la cadena canónica.
En la misma actualización, la Fundación señaló que Frame Transactions (EIP‑8141) pasó a “Considerado para inclusión” como un no‑headliner. Esa etiqueta compromete a los equipos de protocolo a trabajar en la función, pero sin elevarla al estatus de pieza central. El momento es incierto y, con ello, el calendario para la abstracción nativa de cuentas y las ventajas a nivel de monedero que los marcos desbloquearían.
El orden habla de principios fundamentales. Las garantías de inclusión son un requisito previo para cualquier capa de privacidad seria. Si quienes construyen o quienes producen bloques pueden suprimir o retrasar indefinidamente las transacciones, una escritura privada solo será privada hasta que falle y ni siquiera llegue a la cadena. Al fijar FOCIL, Hegotá busca reforzar la garantía de que las presentaciones privadas, ya sean transferencias blindadas o actualizaciones con muchas pruebas, realmente lleguen a la cadena.
Transferencias blindadas canónicas en L1 para corregir la fragmentación del anonimato
El otro pilar de privacidad en el roadmap de Ethereum es un pool blindado único gestionado por el protocolo, desplegado mediante fork. EIP‑8182 propone un contrato de sistema capaz de transferencias privadas de ETH y compatible con transferencias ERC‑20 usando una arquitectura de pruebas dividida: una prueba de pool para mostrar que una transferencia es consistente con el estado blindado y una prueba de autorización separada para demostrar la autoridad de gasto. El objetivo es construir un único pool canónico en L1 en lugar de depender de un mosaico de mezcladores a nivel de aplicación con conjuntos de anonimato pequeños y fragmentados. El roadmap de privacidad de Ethereum enumera EIP‑8182 como considerado para Hegotá junto con Frame Transactions, y señala que los cambios en el protocolo por sí solos no son suficientes para entregar privacidad de extremo a extremo.
La privacidad depende de una cadena más allá de los cambios en el protocolo
El roadmap se actualizó el 27 de julio de 2026 y descompone el problema en tres resultados: lecturas privadas, escrituras privadas y pruebas privadas. Afirma con claridad que enviar un nuevo tipo de transacción o un pool a nivel de sistema no completa el panorama. Varias capas complementarias deben llegar juntas:
Recuperación de información privada para lecturas privadas, para que los monederos puedan descubrir y obtener los datos relevantes sin revelar intereses a los servidores.
Frame Transactions más FOCIL para un envío resistente a la censura, de modo que las escrituras privadas estén estructuradas y no puedan excluirse indefinidamente.
Pruebas del lado del cliente y zkVMs para una semántica confidencial, de modo que los usuarios puedan generar pruebas localmente sin filtrar detalles sensibles a terceros.
Solo con estos componentes que encajan de forma limpia, el recorrido de un usuario se vuelve realmente privado: descubrir un saldo sin señalizarlo, preparar una transferencia sin externalizar secretos y enviarla bajo un protocolo que no pueda ni cuestionar ni estancar la transacción. Hegotá puede sentar las bases de partes de esta secuencia, pero la capa de acceso y la pila de pruebas tienen que ir a la par.
Esa cadena de dependencia también moldea la experiencia de usuario del monedero. Los marcos prometen normalizar cómo se expresan la autorización y la política de gas, pero los desarrolladores todavía necesitan bibliotecas probadas en batalla para crear pruebas locales y circuitos eficientes, y los usuarios necesitan software cliente que pueda gestionar la generación de pruebas con una latencia y un presupuesto de energía aceptables. Sin eso, un pool canónico corre el riesgo de existir como un primitivo poderoso que pocos usuarios mainstream podrán aprovechar.
Se cierne un precedente regulatorio sobre un pool blindado nativo del protocolo
La compatibilidad normativa es una segunda restricción. El 8 de agosto de 2022, la Oficina de Control de Activos Extranjeros (OFAC) del Tesoro de EE. UU. sancionó el mezclador Tornado Cash, marcando un punto de referencia sobre cómo pueden tratar los reguladores la privacidad y la infraestructura de mezcla. El comunicado de prensa y las posteriores acusaciones subrayaron que las herramientas que habilitan transferencias anonimizadas pueden atraer acciones de cumplimiento.
Un pool L1 gestionado por fork no es equivalente a un servicio de terceros, pero el precedente todavía importa. Las bolsas, los proveedores de monederos y los operadores de infraestructura que deban interpretar riesgos de sanciones podrían moderar o restringir interacciones con un pool nativo aunque sea canónico y auditado. Esto afecta no solo a la imagen, sino también al alcance práctico de las transferencias privadas, e introduce decisiones operativas para entidades que intermedian el acceso de los usuarios a Ethereum.
La secuenciación de Hegotá es clara: la inclusión obligatoria queda asegurada, mientras que la refactorización de transacciones basada en marcos se mantiene en “Considerado para inclusión”. Ethereum probablemente pueda garantizar que las escrituras privadas no se censuren antes de poder descomponerlas y autorizarlas de forma nativa bajo un nuevo tipo de transacción. Si un pool blindado gestionado por fork ofrece una privacidad práctica depende de ese orden, y también de componentes no‑protocolo como PIR y la prueba del lado del cliente que lleguen a tiempo.
Aviso: este artículo se proporciona solo con fines informativos. No se ofrece ni se pretende utilizarse como asesoramiento legal, fiscal, de inversión, financiero u otro.