Escrito por: imToken
La semana pasada, en la reunión de desarrolladores principales de Ethereum, se discutió formalmente si incluir EIP-8141 en la actualización Hegotá. El resultado fue sorprendente: esta propuesta, respaldada personalmente por Vitalik, no fue designada como la "función principal" de Hegotá, sino que obtuvo el estado de "Considerado para Inclusión" (CFI).
Y esta semana, el equipo de Quantum AI de Google publicó un nuevo libro blanco, indicando que, bajo sus supuestos de hardware dados, la estimación de bits cuánticos físicos necesarios para romper ECDLP-256 se redujo significativamente en 20 veces en comparación con antes. Aunque esto no significa que un ataque cuántico esté a la vuelta de la esquina, nos recuerda tangiblemente que si el sistema de cuentas no puede cambiar flexiblemente la lógica de verificación en el futuro, muchas de las discusiones actuales sobre la experiencia de la billetera podrían convertirse en problemas de seguridad.
Aunque, desde una perspectiva realista de avance del protocolo, EIP-8141 sigue siendo demasiado pesado, especialmente en la implementación del cliente, la seguridad del pool de transacciones y la complejidad de la verificación, aún no se ha formado un consenso lo suficientemente sólido.
Pero, parados en este momento, parece que hay cada vez más aspectos de EIP-8141 que merecen ser discutidos y examinados seriamente.
一、¿Qué pretende resolver exactamente EIP-8141?
EIP-8141 es impulsado por Vitalik Buterin, timbeiko y otros contribuyentes principales, y su nombre formal es Frame Transactions (Transacciones de Marco).
Si se resume en una frase más fácil de entender, lo que intenta no es añadir una función específica de billetera, sino intentar que, desde la capa de protocolo, ninguna cuenta tenga que estar atada a una única ruta de firma ECDSA, sino que pueda tener una lógica de verificación y ejecución más flexible.
Esto también significa que la multifirma, el patrocinio de Gas, la rotación de claves, la recuperación social, e incluso la futura conexión de esquemas de firma resistentes a lo cuántico, ya no serían solo capacidades externas añadidas a la billetera, sino que tendrían la oportunidad de convertirse en "miembros nativos" del sistema de cuentas de Ethereum.
Si solo se mira superficialmente, EIP-8141 discute un conjunto de capacidades que parecen muy concretas: pagar Gas con stablecoins, combinar operaciones de múltiples pasos en una sola transacción, admitir formas de firma más flexibles, e incluso dejar espacio para futuras firmas resistentes a lo cuántico. Puede decirse que, durante años, muchas mejoras en torno a la experiencia de la billetera, desde ERC-4337 hasta EIP-7702, esencialmente han hecho que una cuenta ya no sea solo una clave privada, sino una entrada con reglas personalizables.
El problema es que estas mejoras sí han hecho que las billeteras se parezcan cada vez más a cuentas inteligentes, pero nunca han tocado realmente el modelo de cuenta predeterminado más fundamental de Ethereum.
Como es bien sabido, en el sistema actual, las cuentas de Ethereum se dividen en dos categorías. Una son las Cuentas de Propiedad Externa (EOA), que son las más conocidas, controladas por una clave privada, pueden iniciar transacciones activamente, pero carecen de capacidad de programación; la otra son las cuentas de contrato, es decir, los propios contratos inteligentes, que pueden ejecutar lógica compleja, pero no pueden iniciar transacciones por sí mismos.
Esto hace que la capacidad de iniciar transacciones haya estado ligada durante mucho tiempo a una única firma de clave privada. Mientras esta premisa no cambie, muchas capacidades que los usuarios dan por sentado hoy en día, como cambiar flexiblemente las reglas de firma, que otro pague el Gas, recuperar el control de la cuenta después de perder la clave privada, o migrar sin problemas a un nuevo sistema criptográfico en el futuro, difícilmente se convertirán en capacidades predeterminadas de la cuenta.
Si has usado imToken u otras billeteras Web3, es probable que también te hayas encontrado con estos puntos problemáticos, como tener un montón de USDC en la billetera pero no poder enviar transacciones porque no tienes ETH (ya que el Gas solo se puede pagar con ETH); perder la frase semilla significa perder el dinero para siempre, sin posibilidad de recuperación; una operación de "autorizar + intercambiar" requiere firmar dos veces, confirmar dos veces, etc.
Estos problemas no se deben a que el producto de la billetera "no sea lo suficientemente bueno", sino que son el resultado del diseño mismo del modelo de cuentas de Ethereum.
Desde esta perspectiva, la evolución de los últimos dos años ha sido muy clara: ERC-4337, sin modificar el protocolo, hizo que la abstracción de cuentas funcionara primero en la capa de aplicación; EIP-7702 demostró además que las EOA no son completamente incapaces de expandirse, al menos pueden obtener temporalmente capacidades cercanas a las de las cuentas inteligentes.
Es decir, Ethereum no es que no quiera hacer la abstracción de cuentas, sino que ha estado utilizando formas más suaves y conservadoras para acercarse gradualmente a ello. Y la aparición de EIP-8141 significa que este camino ha llegado a un nuevo punto. Ya no se conforma con añadir otra capa de capacidad de cuenta inteligente en la periferia del sistema existente, sino que intenta integrar la abstracción de cuentas directamente en el modelo de transacción itself, haciendo que las cuentas, desde la capa de protocolo, tengan una lógica de verificación y ejecución programable.
Esta es también la razón por la que EIP-8141 está cobrando nuevo impulso hoy. Por un lado, la experiencia de las billeteras de capa superior ya se acerca cada vez más a la abstracción de cuentas nativa, y la capa de protocolo tarde o temprano necesita ponerse al día; por otro lado, la presión a largo plazo que trae la computación cuántica también está convirtiendo "si una cuenta puede cambiar flexiblemente su método de firma" de un tema técnico lejano en un problema real que debe considerarse seriamente.
二、¿Cómo funciona EIP-8141?
En resumen, EIP-8141 introduce un tipo de transacción completamente nuevo: la Transacción de Marco (Frame Transaction), con el número de tipo de transacción 0x06.
Si la lógica básica de una transacción tradicional de Ethereum es que una transacción corresponde a una llamada, lo que EIP-8141 intenta hacer es descomponer una transacción en un conjunto de "marcos" que pueden ejecutarse secuencialmente según reglas, separando así las tres cosas que estaban捆绑 juntas: verificación, pago y ejecución.
Cada "marco" tiene tres modos de ejecución:
- VERIFY (Marco de Verificación): Se encarga de verificar si la transacción es legal, ejecuta la lógica de verificación personalizada de la cuenta y, si pasa, llama al nuevo código de operación APPROVE para autorizar la ejecución y especificar el límite de Gas.
- SENDER (Marco de Envío): Ejecuta la operación real, como transferencias, llamadas a contratos, etc. La dirección del llamante es el propio remitente de la transacción.
- DEFAULT (Marco de Entrada): Utiliza la dirección de entrada del sistema como llamante, para escenarios como implementar contratos, verificar Paymaster, etc.;
El significado de este mecanismo no es que las transacciones puedan hacerse más complejas, sino que por primera vez desglosa las tres cosas "verificación, pago, ejecución" de la acción de la cuenta y las delega a la programación nativa del protocolo.
Después de todo, en el pasado, quién verificaba la transacción, quién pagaba el Gas y quién ejecutaba la operación real, estaban基本 atados en la misma acción de cuenta. Bajo el diseño de EIP-8141, estas cosas pueden dividirse en diferentes marcos, ejecutados secuencialmente por el protocolo en un orden claro. Precisamente por esto, las cuentas ya no dependen únicamente de una única clave privada para "firmar en conjunto", sino que comienzan a tener una forma más cercana a la de un sujeto de ejecución programable.
Pongamos un ejemplo concreto: supongamos que quieres usar USDC para pagar el Gas y realizar un Swap. Bajo el framework de EIP-8141, esto teóricamente podría organizarse en un flujo completo de marcos: primero, la cuenta verifica la firma y los permisos de ejecución; luego, el pagador o Paymaster verifica las condiciones bajo las cuales está dispuesto asumir el coste; posteriormente, se completa el pago de la tarifa del activo correspondiente; y finalmente, se ejecuta la operación de swap real.
De esta manera, el pago del Gas y la transacción principal pueden incorporarse en el mismo flujo atómico: o bien tiene éxito por completo, o bien se revierte por completo.
Para el usuario, el cambio más intuitivo es que muchas operaciones que antes tenían que dividirse en dos o tres pasos, y que conllevaban un riesgo de fallo intermedio, en el futuro podrían parecerse más a una acción completa. Por lo tanto, esta atomicidad es también una de las claves con las que EIP-8141 pretende resolver el problema de la fragmentación de la experiencia del usuario.
¿Y qué significa esto para los usuarios de billeteras? En términos de resultados, los cambios más直观 al menos son cuatro capas:
- El pago de Gas se abstrae: Tener stablecoins en la billetera ya no significa que debas preparar adicionalmente algo de ETH para operar; en el futuro, que una DApp, Paymaster u otro patrocinador pague el Gas por ti se volverá más nativo;
- Las operaciones de múltiples pasos se combinan: Flujos como "autorizar + Swap" o "autorizar + staking", que ahora a menudo requieren múltiples firmas, tienen la oportunidad de empaquetarse en una operación más completa;
- Las reglas de seguridad de la cuenta se abren: La multifirma, la recuperación social, los límites diarios, los time-locks, la rotación de claves, ya no son solo funciones avanzadas adicionales proporcionadas por un producto de billetera, sino que comienzan a tener la oportunidad de construirse sobre una lógica de cuenta más nativa;
- El esquema de firma ya no está necesariamente bloqueado por la única ruta ECDSA: Esto da a las cuentas, por primera vez, la posibilidad a nivel de capa de protocolo de migrar en el futuro a diferentes sistemas criptográficos, incluidos los esquemas de firma post-cuánticos;
三、¿Por qué no se convirtió en la estrella principal de Hegotá?
Un punto que es fácil pasar por alto pero crucial para los usuarios de billeteras es: incluso si EIP-8141 se implementa finalmente, el sistema de cuentas existente no será derribado por completo.
Incluso si actualmente usas billeteras Web3 existentes como imToken, no necesitarás migrar, porque es compatible con versiones anteriores. Las direcciones EOA existentes pueden seguir usándose, solo necesitan "actualizar" la lógica de verificación de la cuenta en el momento adecuado.
Pero, mirándolo al revés, es precisamente porque cambia las cosas lo suficientemente en profundidad por lo que no se convirtió directamente en la función principal de Hegotá en la última ronda de discusiones. Sin embargo, según el proceso EIP champion de 2026, CFI (Considered for Inclusion) no significa que sea rechazado, sino que entra en una fase de consideración seria, pero aún no ha llegado el momento de la decisión final de implementación.
En otras palabras, los desarrolladores principales no desaprueban la dirección de EIP-8141, sino que, al reconocer su valor, también consideran que actualmente sigue siendo demasiado "pesado".
Después de todo, la abstracción de cuentas nativa no es como ERC-4337, que primero puede ser impulsada gradualmente por unas pocas billeteras, infraestructuras y aplicaciones. Una vez que entra en la capa de protocolo, significa que todos los clientes de la capa de ejecución deben implementar, probar y coordinar seriamente, lo que天然 aumenta el listón para su avance y hace que los desarrolladores principales prefieran ser más cautelosos en la planificación del fork.
¿Y qué pasará después? Se puede dividir en dos líneas:
- Dado que EIP-8141 está en estado CFI, significa que sigue siendo evaluado continuamente. Los autores de la propuesta seguirán completando los detalles clave en torno a la seguridad del pool de transacciones, las reglas de verificación y la implementación del cliente, y las futuras reuniones de ACD (All Core Devs) también reconsiderarán si cumple las condiciones para avanzar más;
- Si estas incertidumbres pueden comprimirse continuamente, tendrá la oportunidad de entrar en una fase de inclusión más sustancial en actualizaciones posteriores; si no, bien podría posponerse a ciclos de actualización más tardíos;
Siendo realistas, EIP-8141 tampoco es la única propuesta de abstracción de cuentas nativa, y en sí mismo no es un esquema de firma post-cuántico listo para usar, por lo que no puede resolver directamente los problemas de la computación cuántica. Pero su importancia radica en que, por primera vez, proporciona una salida a nivel de capa de protocolo para que las cuentas se liberen de la única ruta ECDSA.
Desde esta perspectiva, el verdadero valor de EIP-8141 no reside en si es la única respuesta correcta, sino en que plantea por primera vez, de manera muy completa, la pregunta de "cómo debería ser realmente el estado final de la abstracción de cuentas nativa" sobre la mesa de discusión del protocolo Ethereum.
No es la única solución, pero es ciertamente una de las más ambiciosas y cercanas al límite superior de la imaginación de la "AA nativa completa".
Independientemente de si EIP-8141 finalmente llega a tiempo para Hegotá, esta discusión en sí misma al menos demuestra una cosa:
Ethereum no se está quedando quieto esperando a que los problemas fermenten, sino que está allanando el camino para el próximo sistema de cuentas avanzando un paso a la vez.
