$ETH
La disputa sobre la abstracción nativa de cuentas de Ethereum (AA): 8130 se divide en tres EIP
Cómo aterrizar la “abstracción nativa de cuentas (native Account Abstraction)” de Ethereum: la comunidad de desarrolladores lleva un buen tiempo discutiendo el tema. Ahora aparece una solución de compromiso que intenta acercar a ambas partes. Según un hilo en el foro de Ethereum Magicians, la propuesta central original EIP-8130 se está reestructurando y dividiendo en tres nuevos EIP “componibles”: 8398, 8399 y 8400.
¿Qué es la AA nativa? ¿Por qué pelean las facciones 8130 y Frame?
El objetivo de la abstracción de cuentas (AA) es convertir las “cuentas de contratos inteligentes” en ciudadanos de primera clase en Ethereum: que puedan personalizar la lógica de verificación, admitir recuperación social, patrocinar/abonar gas y realizar transacciones por lotes, entre otras funciones. En la actualidad, el enfoque más común es usar bundlers fuera de la cadena con ERC-4337; en cambio, la “AA nativa” busca soporte directo en la capa del protocolo.
La discusión está en “cómo” proporcionar ese soporte. Un bando propone la ruta del “keystore” representada por EIP-8130: usar una lista blanca de validadores confiables para gestionar la verificación de firmas. La ventaja es que el costo de verificación es predecible y está acotado (especialmente amigable para Layer 2). Además, incorpora estándares de cuentas que incluyen policy y session keys, con un enfoque en simplicidad y en reducir la fragmentación. El otro bando, en cambio, propone Frame Transactions (EIP-8141): permite que, en cualquier parte de una transacción, se realice una “verificación no estructurada” mediante cualquier código arbitrario de EVM. Con esto se habilitan juegos nuevos como “cuentas que no tienen ETH pueden obtener fondos a mitad del proceso de ejecución”. A cambio, ofrece la máxima flexibilidad y un espacio de innovación sin necesidad de hard fork, pero también conlleva mayor riesgo de fragmentación, y algunos modos avanzados requieren un private mempool.
En una comparación anterior, Derek Chiang de Ethlabs en el artículo〈8130 vs Frame Transactions〉señaló justo la disyuntiva entre “simplicidad y control” versus “flexibilidad extrema”.
Solución de compromiso: dividir en 8398, 8399 y 8400 tres EIP componibles
Una “abstracción nativa de cuentas componible” propuesta por el desarrollador Pedro UID, el 27 de agosto, descompone la funcionalidad en tres EIP núcleo en capas (correspondientes al mismo día a aperturas de GitHub PR #12248 ):
- EIP-8398 “Keystore de cuentas portables”: define los actores (actor), los validadores, la configuración de la cuenta y la creación, además de la portabilidad entre cadenas.
- EIP-8399, construido sobre 8398: introduce el tipo de transacción 0x79 para la transacción nativa de AA, e incorpora soporte de lotes, transacciones con sponsorship (patrocinio) y nonces ordenados.
- EIP-8400 requiere los dos anteriores y agrega policy, el bloqueo de cuentas, y el uso de una “transacción sin nonce” dentro del mismo tipo de envoltorio de transacción.
El EIP-8130 original se mantiene sin cambios: se reestructura como el antecedente de estas tres especificaciones complementarias.
Significado: modularidad para que cada cadena adopte lo que necesite, pero aún en etapa de propuesta
Dividir una gran propuesta en tres módulos componibles tiene como mayor ventaja la flexibilidad: distintas cadenas o equipos pueden adoptar solo el nivel que necesitan, sin verse obligados a tenerlo todo o no tener nada.
Una interpretación en la comunidad es que la ruta de Frame, que enfatiza la flexibilidad, parece haber ganado “en lo general”, y la idea del keystore para L2 también se incorporó; en otras palabras, ninguna de las dos partes pierde completamente.
No obstante, vale la pena recordar que todo esto todavía se encuentra en la etapa de propuesta de EIP y discusión comunitaria: aún no se ha convertido en la solución final de Ethereum. Habrá que ver cómo los desarrolladores principales van a converger estas tres especificaciones en una ruta de actualización formal.
Este artículo “La disputa sobre la abstracción nativa de cuentas (AA) de Ethereum: 8130 se divide en tres EIP” apareció por primera vez en .
La disputa sobre la abstracción nativa de cuentas de Ethereum (AA): 8130 se divide en tres EIP
Cómo aterrizar la “abstracción nativa de cuentas (native Account Abstraction)” de Ethereum: la comunidad de desarrolladores lleva un buen tiempo discutiendo el tema. Ahora aparece una solución de compromiso que intenta acercar a ambas partes. Según un hilo en el foro de Ethereum Magicians, la propuesta central original EIP-8130 se está reestructurando y dividiendo en tres nuevos EIP “componibles”: 8398, 8399 y 8400.
¿Qué es la AA nativa? ¿Por qué pelean las facciones 8130 y Frame?
El objetivo de la abstracción de cuentas (AA) es convertir las “cuentas de contratos inteligentes” en ciudadanos de primera clase en Ethereum: que puedan personalizar la lógica de verificación, admitir recuperación social, patrocinar/abonar gas y realizar transacciones por lotes, entre otras funciones. En la actualidad, el enfoque más común es usar bundlers fuera de la cadena con ERC-4337; en cambio, la “AA nativa” busca soporte directo en la capa del protocolo.
La discusión está en “cómo” proporcionar ese soporte. Un bando propone la ruta del “keystore” representada por EIP-8130: usar una lista blanca de validadores confiables para gestionar la verificación de firmas. La ventaja es que el costo de verificación es predecible y está acotado (especialmente amigable para Layer 2). Además, incorpora estándares de cuentas que incluyen policy y session keys, con un enfoque en simplicidad y en reducir la fragmentación. El otro bando, en cambio, propone Frame Transactions (EIP-8141): permite que, en cualquier parte de una transacción, se realice una “verificación no estructurada” mediante cualquier código arbitrario de EVM. Con esto se habilitan juegos nuevos como “cuentas que no tienen ETH pueden obtener fondos a mitad del proceso de ejecución”. A cambio, ofrece la máxima flexibilidad y un espacio de innovación sin necesidad de hard fork, pero también conlleva mayor riesgo de fragmentación, y algunos modos avanzados requieren un private mempool.
En una comparación anterior, Derek Chiang de Ethlabs en el artículo〈8130 vs Frame Transactions〉señaló justo la disyuntiva entre “simplicidad y control” versus “flexibilidad extrema”.
Solución de compromiso: dividir en 8398, 8399 y 8400 tres EIP componibles
Una “abstracción nativa de cuentas componible” propuesta por el desarrollador Pedro UID, el 27 de agosto, descompone la funcionalidad en tres EIP núcleo en capas (correspondientes al mismo día a aperturas de GitHub PR #12248 ):
- EIP-8398 “Keystore de cuentas portables”: define los actores (actor), los validadores, la configuración de la cuenta y la creación, además de la portabilidad entre cadenas.
- EIP-8399, construido sobre 8398: introduce el tipo de transacción 0x79 para la transacción nativa de AA, e incorpora soporte de lotes, transacciones con sponsorship (patrocinio) y nonces ordenados.
- EIP-8400 requiere los dos anteriores y agrega policy, el bloqueo de cuentas, y el uso de una “transacción sin nonce” dentro del mismo tipo de envoltorio de transacción.
El EIP-8130 original se mantiene sin cambios: se reestructura como el antecedente de estas tres especificaciones complementarias.
Significado: modularidad para que cada cadena adopte lo que necesite, pero aún en etapa de propuesta
Dividir una gran propuesta en tres módulos componibles tiene como mayor ventaja la flexibilidad: distintas cadenas o equipos pueden adoptar solo el nivel que necesitan, sin verse obligados a tenerlo todo o no tener nada.
Una interpretación en la comunidad es que la ruta de Frame, que enfatiza la flexibilidad, parece haber ganado “en lo general”, y la idea del keystore para L2 también se incorporó; en otras palabras, ninguna de las dos partes pierde completamente.
No obstante, vale la pena recordar que todo esto todavía se encuentra en la etapa de propuesta de EIP y discusión comunitaria: aún no se ha convertido en la solución final de Ethereum. Habrá que ver cómo los desarrolladores principales van a converger estas tres especificaciones en una ruta de actualización formal.
Este artículo “La disputa sobre la abstracción nativa de cuentas (AA) de Ethereum: 8130 se divide en tres EIP” apareció por primera vez en .
