El desarrollador de Ethereum, Derek Chiang, dijo el 7 de septiembre que los autores de EIP-8141 habían encontrado una manera de expresar varias características de transacción como llamadas de contrato programables en lugar de agregarlas por separado al sobre de transacción de Ethereum.
Resumen
- Los desarrolladores de Ethereum dicen que EIP-8141 puede expresar características de transacción a través de llamadas de contrato conocidas como marcos programables.
- Los marcos podrían soportar caducidad, agregación de firmas, pruebas de privacidad y aserciones posteriores a la transacción sin nuevos campos de sobre.
- EIP-8141 está programado para Hegotá, aunque su especificación sigue siendo un borrador y las fechas de activación siguen sin establecerse.
- Los desarrolladores están coordinando EIP-8141 con EIP-8130 para preservar la estructura y mejorar la legibilidad de las transacciones para la infraestructura.
- Vitalik Buterin argumenta que separar las acciones y dependencias de las transacciones podría permitir la validación en paralelo y reducir costos.
Chiang, coautor de EIP-8141 y colaborador de Ethlabs, describió el desarrollo como un "avance de diseño" en una publicación que discute el trabajo reciente de los autores de la propuesta. El enfoque trata la caducidad de transacciones, firmas agregadas, raíces de Merkle de grupos de privacidad y aserciones posteriores a la transacción como llamadas llamadas "marcos".
La especificación de borrador oficial define una Transacción de Marco como una secuencia de llamadas de contrato. Diferentes marcos pueden validar una transacción, aprobar su pago de gas o ejecutar operaciones de usuario. La propuesta actualmente proporciona tres modos: DEFAULT, VERIFY y SENDER.
Un marco VERIFY puede verificar si se cumple una condición requerida. Un marco SENDER ejecuta una operación desde la cuenta identificada como el remitente de la transacción. Los marcos también se pueden agrupar en lotes atómicos, lo que significa que cada operación en un lote tiene éxito junto o todo el grupo se revierte.
La propuesta todavía define un sobre de transacción base que contiene campos como el identificador de cadena, nonce, remitente, tarifas, firmas y lista de marcos. El punto de Chiang es más limitado: los desarrolladores pueden introducir más funcionalidad a través de nuevos objetivos de marco y patrones de llamada sin crear otro formato de sobre para cada característica.
Un sobre estable podría reducir el trabajo de coordinación
Cambiar el sobre de transacción de Ethereum afecta a más que los clientes de ejecución. Las billeteras, las redes de Capa 2, los exploradores de bloques, los dispositivos de firma, las bibliotecas de software y los proveedores de infraestructura deben comprender el nuevo formato.
Chiang dijo que las actualizaciones de Ethereum ocurren aproximadamente cada nueve meses, lo que hace que los cambios repetidos de sobre sean lentos y requieran mucha coordinación. Un formato de marco suficientemente general podría servir como una interfaz estable mientras que los contratos o componentes de protocolo designados proporcionan nuevos métodos de validación.
Eso no significa que la funcionalidad futura nunca requiera una actualización de red. EIP-8141 en sí mismo cambia las reglas de consenso de Ethereum y requiere implementación de clientes. Nuevos opcodes, precompilados o reglas de gas también podrían requerir bifurcaciones duras. El beneficio propuesto es que los desarrolladores no necesariamente tendrían que rediseñar el contenedor de transacciones cada vez.
La especificación EIP-8141 enumera la abstracción de cuenta nativa entre sus objetivos principales. Podría soportar rotación de claves, sistemas de firma alternativos, pagos de gas patrocinados y agrupación de transacciones. También tiene como objetivo reducir la dependencia de las cuentas de Ethereum en el sistema de firma secp256k1 utilizado por las cuentas de propiedad externa convencionales.
Como informó crypto.news en su cobertura del rediseño de transacciones de Ethereum propuesto por Vitalik Buterin, la validación programable podría eventualmente ayudar a Ethereum a adoptar nuevos sistemas de autenticación sin reemplazar un esquema de firma fijo por otro.
EIP-8130 podría facilitar la inspección de los frames
Chiang también reconoció una desventaja. Las transacciones altamente abstractas pueden volverse difíciles de analizar para las billeteras, secuenciadores y otra infraestructura antes de su ejecución. Un secuenciador de capa 2 podría, por ejemplo, querer aceptar solo métodos de firma específicos porque sus costos computacionales son predecibles.
Por lo tanto, los desarrolladores están explorando cómo los frames podrían funcionar con EIP-8130, otra propuesta de abstracción de cuentas en borrador. EIP-8130 crea un almacén de claves en cadena donde las cuentas registran actores y contratos autenticadores. Las transacciones identifican explícitamente su método de autenticación.
Esa estructura permite que un nodo determine qué proceso de validación requiere una transacción antes de ejecutar código arbitrario de la billetera. Según el perfil de capa 2 propuesto por EIP-8130, una cadena podría restringir su ruta de transacción a un conjunto canónico de autenticadores de costo fijo, dejando otros métodos de autenticación disponibles a través de la ejecución ordinaria de EVM.
Chiang dijo que EIP-8130 podría imponer estructuras definidas sobre los frames de EIP-8141. La colaboración podría preservar la flexibilidad de los frames mientras brinda a las billeteras y cadenas de alto rendimiento un formato de transacción más legible. El diseño combinado no se ha finalizado, y ambas especificaciones siguen abiertas a revisión.
La cobertura anterior de crypto.news examinó la competencia entre EIP-8141 y EIP-8130 durante el proceso inicial de alcance de Hegotá. Los últimos comentarios sugieren que los desarrolladores ahora buscan elementos compatibles en lugar de tratar las propuestas solo como alternativas mutuamente excluyentes.
Buterin conecta los frames con la validación paralela
Vitalik Buterin amplió la dirección técnica en una publicación separada, distinguiendo entre "acciones" y "dependencias" de las transacciones. Una acción cambia el estado de Ethereum, como transferir ETH. Una dependencia es una condición que debe cumplirse, como una firma, prueba de Merkle o prueba de conocimiento cero.
Buterin argumentó que las dependencias independientes podrían verificarse en paralelo. Las condiciones que no acceden al estado de Ethereum podrían procesarse una vez en el mempool en lugar de repetirse durante la ejecución. Múltiples verificaciones podrían eventualmente representarse mediante una prueba STARK recursiva, aunque eso sigue siendo una dirección de investigación en lugar de una característica aprobada.
La distinción también podría ayudar a los clientes a separar transacciones predecibles de operaciones que requieren el entorno de ejecución dinámico completo de Ethereum. Buterin dijo que la actividad más analizable estáticamente podría recibir costos de gas más bajos y escalar más. No se ha aprobado ningún calendario de tarifas de este tipo.
El modelo de frames proporciona una interfaz potencial para ese enfoque porque la validación y la ejecución aparecen como llamadas identificables. Ethereum conservaría la ejecución flexible de contratos mientras permite que las transacciones más simples declaren más información sobre sus requisitos.
EIP-8141 está programado, pero las fechas siguen abiertas
El Meta EIP de Hegotá oficial ahora enumera Frame Transactions y FOCIL como programados para su inclusión en la actualización Hegotá de Ethereum. Eso representa un estado más sólido que la consideración anterior, pero no congela el diseño técnico actual de EIP-8141.
EIP-8141 sigue marcado como una propuesta de Núcleo en borrador. Sus autores pueden revisar los modos de frame, el manejo de firmas, la contabilidad de gas y la relación con EIP-8130 a medida que continúa el trabajo de implementación. El documento de Hegotá también deja en blanco los campos de activación de Sepolia, Hoodi y mainnet.
Los próximos pasos medibles incluyen especificaciones actualizadas, implementaciones de clientes de ejecución, redes de desarrollo y pruebas de interoperabilidad con billeteras y sistemas de capa 2. Los desarrolladores también deben examinar los riesgos de denegación de servicio en el mempool porque la validación programable puede hacer que rechazar transacciones inválidas sea computacionalmente más costoso.
Las pruebas determinarán si la combinación propuesta de marcos flexibles y autenticadores estructurados puede satisfacer las necesidades de la capa base de Ethereum y de las cadenas EVM más rápidas. Hasta que se publiquen los parámetros de activación, EIP-8141 sigue siendo una parte programada pero inacabada de Hegotá.
