Ethereum y Base abandonan el estándar conjunto de abstracción de cuentas

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, tras descubrir que las opciones técnicas disponibles requerirían que Ethereum o Base comprometieran sus requisitos fundamentales.

Ambas propuestas buscan simplificar la interacción de los usuarios con las carteras de criptomonedas, incluyendo permitir transacciones sin que los usuarios tengan ETH para el gas y admitir métodos de autenticación como claves de acceso del teléfono. Los equipos habían estado explorando si un diseño podría servir a la capa 1 de Ethereum y a la capa 2 de Base.

“Aunque identificamos varias soluciones técnicas, todas requerían que una de las partes comprometiera al menos un poco sus objetivos principales”, dijo Chiang. “Así que tomamos caminos separados, dejando a las carteras la carga de lidiar con la fragmentación resultante”.

Los desarrolladores de Ethereum priorizan la resistencia a la censura, la privacidad y la seguridad, mientras que Base se centra en la escalabilidad, la personalización y el cumplimiento normativo, según Chiang. Las diferencias finalmente impidieron que los equipos acordaran 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 carteras ante la posibilidad de soportar dos formatos de transacción nativos si EIP-8141 y EIP-8130 llegan a producción.

Chiang dijo que las carteras aún podrían ofrecer a los usuarios una experiencia consistente a pesar de las diferencias técnicas entre las redes, dependiendo de cómo los desarrolladores manejen los estándares separados.

“Si se ejecutan bien, y si la comunidad de carteras puede superar la fragmentación, 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 unos días antes. Los desarrolladores de EIP-8141 estaban explorando la compatibilidad con EIP-8130 mientras trabajaban en formas de mantener las transacciones programables y hacer 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 alrededor de los frames de EIP-8141. El acuerdo propuesto pretendía preservar la naturaleza programable de los frames, al tiempo que daba a las carteras 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 cartera.

EIP-8141 adopta 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, incluyendo validación, aprobación de gas y ejecución.

Los equipos han abandonado ahora el esfuerzo de convertir esos enfoques en un estándar único.

EIP-8141 se ha convertido en una propuesta obligatoria para Ethereum

Ethereum continúa con EIP-8141, o Transacciones de Frame, como parte de su actualización planificada Hegotá.

El clúster de Protocolo de la Fundación Ethereum colocó la propuesta en su categoría de “obligatoria” a principios de este mes, mientras que el material fuente afirma que la propuesta pretende hacer que la abstracción de cuentas sea nativa de Ethereum y mejorar la seguridad y la preparación poscuántica.

Las Transacciones de Frame dividen una transacción en una secuencia de frames programables. Un frame puede validar al remitente, otro puede autorizar la cuenta responsable del gas, y los frames 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 paga por ella sean diferentes.

Los desarrolladores de Ethereum ya habían programado EIP-8141 para Hegotá el 7 de septiembre. Los desarrolladores principales movieron la propuesta de Considerada para su inclusión a Programada para su inclusión durante la llamada de Ejecución de Todos los Desarrolladores Principales del 27 de agosto, dando a las Transacciones de Frame una posición formal en la actualización planificada 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 hacer 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 tienen stablecoins u otros tokens aún necesitan ETH antes de poder realizar una transacción.

Los frames también se pueden utilizar para la agrupación de transacciones. Las acciones relacionadas podrían agruparse para que todas tengan éxito juntas o se reviertan cuando una falla.

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. Las Transacciones de Frame podrían colocar acciones relacionadas dentro de la misma estructura de transacción programable.

Los frames programables amplían los controles de cuenta de Ethereum

EIP-8141 está diseñado 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 uno 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 un “ómnibus que envuelve y resuelve todos los problemas restantes que la AA pretendía abordar”.

El 5 de septiembre, Buterin dijo que la propuesta había logrado “muchos avances importantes” en los meses anteriores y se estaba acercando a lo “óptimo”.

Posteriormente, los desarrolladores descubrieron que varias características de transacción podían expresarse a través de frames programables EIP-8141 en lugar de expandir repetidamente la envoltura de transacción de Ethereum.

El enfoque podría manejar la caducidad de transacciones, la agregación de firmas, las pruebas de privacidad y las aserciones posteriores a la transacción como llamadas de contrato programables. Las Transacciones de Frame 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 frame 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ñado para admitir características que incluyen sistemas de firma alternativos, pagos de gas patrocinados, agrupación 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 firma 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 Frame para Hegotá antes de que la propuesta se programara formalmente. En agosto, los desarrolladores comparaban 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 formaban parte de un proceso de selección más amplio de Hegotá que cubría la resistencia a la censura, la privacidad, el precio del gas, la economía de los validadores y el escalado de la capa 1.

Los investigadores de Ethereum habían examinado por separado cómo las Transacciones de Frame podrían apoyar aplicaciones centradas en la privacidad. Una propuesta de agosto discutía privacy pools autofinanciados en los que los pagos de tarifas programables podrían permitir que un privacy pool cubriera su propio gas en lugar de depender de un relayer externo.

Ese trabajo emparejaba las Transacciones de Frame con otros cambios propuestos, incluyendo Nonces con clave, Recent Roots y Aserciones de transacción. La propuesta de privacy pool 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 procederá ahora por separado de la propuesta de Transacciones de Frame de Ethereum.

El diseño de Base combina un nuevo tipo de transacción con un “Keystore” en cadena que registra los 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 dan 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 de 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 el escalado continuo de la capa 1.

Con el esfuerzo conjunto ahora terminado, 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 almacén de claves en cadena.