Los desarrolladores de Ethereum y Base han terminado el trabajo sobre un estándar común de abstracción de cuentas después de que los esfuerzos por conciliar EIP-8141 y EIP-8130 fracasaran, dejando a las dos redes para perseguir diseños de transacción separados.
Resumen
- Los desarrolladores de Ethereum y Base han terminado los esfuerzos por alinear EIP 8141 y EIP 8130 después de no lograr un acuerdo sobre un diseño común de abstracción de cuentas.
- Ethereum está priorizando la resistencia a la censura, la privacidad y la seguridad, mientras que Base se centra en la escala, la personalización y el cumplimiento.
- EIP 8141 ha sido etiquetada como una propuesta de implementación obligatoria para la actualización Hegotá de Ethereum, mientras que Base continuará desarrollando EIP 8130 por separado.
- Los desarrolladores de billeteras podrían necesitar admitir dos formatos de transacción nativos si ambas propuestas se implementan finalmente.
El desarrollador de Ethlabs, Derek Chiang, dijo el lunes que los autores de las dos propuestas dejaron de trabajar hacia una especificación compartida la semana pasada después de descubrir que las opciones técnicas disponibles requerirían que Ethereum o Base cedieran en requisitos fundamentales.
Ambas propuestas buscan simplificar cómo los usuarios interactúan con las billeteras cripto, incluido permitir transacciones sin que los usuarios primero tengan ETH para gas y admitir métodos de autenticación como claves de acceso telefónicas. Los equipos habían estado explorando si un diseño podría servir a Ethereum Layer 1 y Base Layer 2.
“Si bien identificamos una serie de soluciones técnicas, todas requerían que una parte u otra cediera al menos un poco en sus objetivos principales”, dijo Chiang. “Así que tomamos caminos separados, poniendo la carga sobre las billeteras para lidiar con la fragmentación que resulta”.
Los desarrolladores de Ethereum están priorizando la resistencia a la censura, la privacidad y la seguridad, mientras que Base se centra en la escala, la personalización y el cumplimiento, según Chiang. Las diferencias finalmente impidieron que los equipos se decidieran por un formato de transacción único.
Los planes de abstracción de cuentas de Ethereum y Base se han dividido
La decisión deja a los desarrolladores de billeteras enfrentando la posibilidad de admitir dos formatos de transacción nativos si EIP-8141 y EIP-8130 llegan ambos a producción.
Chiang dijo que las billeteras aún podrían proporcionar a los usuarios una experiencia consistente a pesar de las diferencias técnicas entre redes, dependiendo de cómo los desarrolladores manejen los estándares separados.
“Si ejecutan bien, y si la comunidad de billeteras puede superar la fragmentación, bien podríamos terminar con la mejor experiencia de usuario posible para los usuarios finales”, dijo.
El resultado cambia la dirección que los desarrolladores estaban discutiendo solo días antes. El 7 de septiembre, crypto.news informó anteriormente que los desarrolladores de EIP-8141 estaban explorando la compatibilidad con EIP-8130 mientras trabajaban en formas de mantener las transacciones programables mientras hacían que sus requisitos de autenticación fueran más fáciles de inspeccionar para los proveedores de infraestructura.
En esa etapa, Chiang dijo que EIP-8130 podría proporcionar estructuras definidas en torno a los frames de EIP-8141. El arreglo propuesto estaba destinado a preservar la naturaleza programable de los frames mientras daba a las billeteras y a las redes de alto rendimiento un formato de transacción más claro.
EIP-8130 utiliza un almacén de claves en cadena donde las cuentas pueden registrar actores aprobados y contratos autenticadores. Las transacciones identifican el método de autenticación que utilizan, lo que permite a una red determinar el proceso de validación requerido antes de ejecutar el código de la billetera.
EIP-8141 toma una ruta diferente al estructurar las transacciones como llamadas de contrato programables llamadas frames. Los frames pueden realizar diferentes funciones dentro de la misma transacción, incluida la validación, la aprobación de gas y la ejecución.
Los equipos ahora han abandonado el esfuerzo de convertir esos enfoques en un solo estándar.
EIP-8141 se ha convertido en una propuesta de Ethereum de obligada implementación
Ethereum continúa con EIP-8141, o Transacciones de Marco, como parte de su planeada actualización Hegotá.
El clúster de Protocolo de la Fundación Ethereum colocó la propuesta en su categoría de “obligada implementación” a principios de este mes, mientras que el material de origen afirma que la propuesta tiene como objetivo hacer que la abstracción de cuentas sea nativa de Ethereum y mejorar la seguridad y la preparación post-cuántica.
Las Transacciones de Marco dividen una transacción en una secuencia de marcos programables. Un marco puede validar al remitente, otro puede autorizar la cuenta responsable del gas, y los marcos posteriores pueden ejecutar las acciones solicitadas por el usuario.
El modelo permitiría que la cuenta que inicia una acción y la cuenta que la paga sean diferentes.
Los desarrolladores de Ethereum ya habían programado EIP-8141 para Hegotá para el 7 de septiembre. Los desarrolladores principales movieron la propuesta de Considerada para Inclusión a Programada para Inclusión durante la llamada de Ejecución de Todos los Desarrolladores Principales del 27 de agosto, dando a las Transacciones de Marco una posición formal en la actualización planeada para 2027 mientras su especificación permanecía en forma de borrador.
Bajo el sistema propuesto, una aplicación podría cubrir la tarifa de transacción de un usuario o arreglar que el usuario pague a través de otro activo mientras los validadores de Ethereum continúan recibiendo la tarifa de red en ETH.
La estructura podría eliminar un requisito común de las carteras según el cual los usuarios que poseen stablecoins u otros tokens aún necesitan ETH antes de poder realizar una transacción.
Los marcos también se pueden utilizar para el agrupamiento de transacciones. Las acciones relacionadas podrían agruparse para que todas tengan éxito juntas o se reviertan cuando una falle.
Un intercambio de tokens, por ejemplo, actualmente puede requerir una aprobación separada que permita a una aplicación gastar tokens antes de que se ejecute el intercambio en sí. Las Transacciones de Marco podrían colocar acciones relacionadas dentro de la misma estructura de transacción programable.
Los marcos programables amplían los controles de las cuentas de Ethereum
EIP-8141 está diseñada para trasladar más lógica de validación de cuentas a código programable en lugar de requerir que las cuentas convencionales de Ethereum dependan de un proceso de autenticación fijo.
La propuesta describe su estado final como aquel en el que “una cuenta simplemente se convierte en una dirección con código”.
Vitalik Buterin, coautor de EIP-8141, describió la propuesta en febrero como una “ómnibus que envuelve y resuelve cada problema restante que la AA pretendía abordar”.
El 5 de septiembre, Buterin dijo que la propuesta había hecho “muchos progresos importantes” durante los meses anteriores y se estaba acercando a ser “casi óptima”.
Los desarrolladores posteriormente descubrieron que varias características de transacción podían expresarse a través de marcos programables de EIP-8141 en lugar de expandir repetidamente el sobre de transacción de Ethereum.
El informe de crypto.news del 7 de septiembre decía que el enfoque podría manejar la expiración de transacciones, la agregación de firmas, las pruebas de privacidad y las aserciones posteriores a la transacción como llamadas a contratos programables. Las Transacciones de Marco aún requerirían cambios en las reglas de consenso de Ethereum, pero las funciones individuales podrían construirse a través de objetivos de marco y patrones de llamada.
La validación programable podría dar a las cuentas más control sobre la autenticación. EIP-8141 está diseñada para admitir características que incluyen sistemas de firma alternativos, pagos de gas patrocinados, agrupamiento de transacciones y rotación de claves.
La misma arquitectura podría ayudar a las cuentas de Ethereum a alejarse de la dependencia del sistema de firmas utilizado por las cuentas de propiedad externa convencionales. Un usuario podría potencialmente cambiar el método de autenticación que controla una cuenta sin transferir los activos a una nueva dirección.
Los investigadores de Ethereum habían estado considerando las Transacciones de Marco para Hegotá antes de que la propuesta se programara formalmente. En agosto, los desarrolladores estaban comparando EIP-8141 con EIP-8130 como enfoques competidores para la abstracción de cuentas nativa mientras reducían el alcance de la actualización de 2027.
En ese momento, las propuestas eran parte de un proceso de selección más amplio de Hegotá que abarcaba resistencia a la censura, privacidad, precios de gas, economía de validadores y escalado de Capa 1.
Los investigadores de Ethereum habían examinado por separado cómo las Transacciones Frame podrían respaldar aplicaciones centradas en la privacidad. Una propuesta de agosto discutió pools de privacidad autofinanciados en los que los pagos de tarifas programables podrían permitir que un pool de privacidad cubra su propio gas en lugar de depender de un relayer externo.
Ese trabajo combinó las Transacciones Frame con otros cambios propuestos, incluidos Keyed Nonces, Recent Roots y Transaction Assertions. La propuesta del pool de privacidad seguía siendo el paquete preferido de un investigador en lugar de una decisión final de los desarrolladores principales de Ethereum en ese momento.
Base continuará con EIP-8130
El EIP-8130 de Base ahora procederá por separado de la propuesta de Transacciones Frame de Ethereum.
El diseño autorado por Base combina un nuevo tipo de transacción con un "Keystore" en cadena que registra firmantes y autenticadores aprobados para una cuenta. Está destinado a admitir autenticación personalizada, agrupación de llamadas y patrocinio de gas.
Aunque las dos propuestas comparten varios objetivos de abstracción de cuentas, sus estructuras técnicas otorgan a sus respectivas redes diferentes niveles de control sobre cómo se autentican y procesan las transacciones.
Antes de que los equipos se separaran, los desarrolladores de Ethereum habían estado tratando de determinar si el sistema de autenticación estructurado de EIP-8130 podría combinarse con los frames programables de EIP-8141 sin obligar a las redes de Capa 1 o Capa 2 a renunciar a sus propiedades preferidas.
Ethlabs había colocado previamente las Transacciones Frame entre sus principales prioridades para la actualización Hegotá, citando la abstracción de cuentas nativa junto con la resistencia a la censura, bloques más rápidos y la continua escalabilidad de Capa 1.
Con el esfuerzo conjunto ahora finalizado, EIP-8141 sigue siendo la ruta planificada de abstracción de cuentas nativa de Ethereum para Hegotá, mientras que Base continuará desarrollando EIP-8130 en torno a su tipo de transacción separado y su keystore en cadena.
