Trazando la hoja de ruta de abstracción de cuentas de Ethereum I: EIP-3074, EIP-5806 y EIP-7702

Tras observar los cambios significativos que se introdujeron en Ethereum a través de la actualización de Deneb, hemos comenzado a mirar hacia el futuro para ver qué introducirá la próxima bifurcación dura, Pectra. Para ayudar a dar forma a las discusiones que se avecinan, buscamos describir el panorama actual de abstracción de cuentas que rodea a Ethereum y su ecosistema de acumulación para potencialmente trazar un camino claro hacia el futuro.

Este informe ofrece una descripción general del modelo de cuenta corriente de Ethereum, en particular sus efectos sobre la validez de las transacciones, qué implica exactamente la abstracción de cuentas y un marco para razonar al respecto. Luego nos centraremos en el enfoque de programabilidad de EOA mediante la evaluación de las EIP 5086, 3074 y 7702, y concluiremos con la forma en que todo esto probablemente afecte el futuro de las transacciones en Ethereum.

Si bien existe mucha confusión en torno a qué es y qué no es la abstracción de cuentas, nuestra idea a lo largo de esta serie es que cualquier mecanismo que permita a una cuenta redefinir cualquier parte de sus reglas de validez es un mecanismo de abstracción de cuentas. Además, proporcionamos una clasificación de estos mecanismos, ya que la mayoría de ellos son vagamente similares y se superponen.

Una descripción general de la abstracción de cuentas en Ethereum

La abstracción de cuentas busca mejorar las experiencias de los usuarios y desarrolladores en todo el ecosistema Ethereum. Además de hacer que las experiencias en cadena sean más accesibles y agradables para los usuarios, también permite a los desarrolladores hacer cosas más poderosas en Ethereum y brindar servicios a los usuarios de formas aún más significativas.

Nuestra clasificación de los enfoques de abstracción contable es la siguiente:

1. Mejora/programabilidad de las EOA : esto incluye cambios a nivel de protocolo que permiten que las EOA (cuentas de propiedad externa) redefinan la parte de lógica de ejecución de sus reglas de validez. Como es bien sabido en la comunidad de desarrollo, las EOA son cuentas que suelen estar asociadas a los usuarios finales. Por lo tanto, las soluciones que se enmarcan en este enfoque otorgarán a las cuentas de los usuarios finales un mayor control sobre el tipo de acciones que pueden autorizar, en comparación con la forma en que esto se puede gestionar en la actualidad.

2. Conversión/migración de EOA : este enfoque incluye propuestas que buscan la conversión completa de EOA a CA (cuentas contractuales). La idea integral de este enfoque es que las cuentas contractuales ya ofrecen la mayoría de los beneficios que ofrecen las cuentas inteligentes, por lo que no debería haber necesidad de complicar más las cosas; todos deberían simplemente usar una cuenta contractual como su cuenta principal (a través de billeteras contractuales inteligentes).

Este enfoque incluye mecanismos que permiten que una EOA se transforme en una CA, sin tener que mover sus activos, como EIP 7377 y EIP 5003 (cuando se consideran junto con EIP 3074).

3. Cuentas inteligentes : Este grupo de propuestas incluye diseños que permiten que tanto las EOA como las CA se comporten como “cuentas inteligentes” al permitirles redefinir totalmente sus reglas de validez.

Se han hecho varias propuestas para la creación de cuentas inteligentes y la abstracción de cuentas a nivel de protocolo; EIP-86 y EIP-2938 son algunas de las más citadas. Sin embargo, hubo mucho rechazo debido a la complejidad percibida que introduce este diseño y la opinión mayoritaria de que Ethereum no está listo para tal complejidad.

Tras la recuperación del tema por parte de Vitalik después de The Merge, se propuso ERC-4337 como una versión opcional del estándar de cuentas inteligentes, similar a la infraestructura PBS (separación entre el proponente y el constructor) para MEV (valor máximo extraíble). Por lo tanto, los usuarios que buscan acceder a los beneficios de las cuentas inteligentes podrían simplemente usar el flujo de trabajo ERC-4337 para redefinir la lógica de su cuenta y las reglas de validez de las transacciones en estructuras denominadas UserOperation (o UserOps para abreviar).

ERC 4337 trae los beneficios de las cuentas inteligentes al Ethereum actual sin incorporar ninguna de las complejidades, al funcionar como una alternativa fuera de protocolo a las cuentas inteligentes incorporadas. Sin embargo, esto no significa que la infraestructura sea óptima en su estado actual, ya que su propia complejidad sigue siendo un punto de falla considerable.

Para abordar esta complejidad, se redactó RIP 7560 como una versión consagrada de la infraestructura ERC 4337 en Ethereum y sus L2, de modo que herede los esquemas de resistencia a la sibila de la red en lugar de tener que definir un nuevo conjunto de reglas (como lo hace ERC 4337 con ERC 7562 ).

En este informe, nos centraremos en explorar la programabilidad de EOA, evaluar los distintos EIP que describen soluciones en esta línea y analizar sus ventajas e inconvenientes. En las partes 2 y 3 de esta serie, cubriremos las dos clases restantes de enfoque de abstracción de cuentas que se están explorando en Ethereum.

Una introducción a las cuentas y transacciones de Ethereum

Para poder descubrir qué se puede abstraer, necesitamos una imagen (en cierta medida) completa del diseño actual de las cuentas. Esta sección servirá principalmente como una especie de revisión de lo que son realmente las cuentas en Ethereum y cómo se validan y ejecutan sus transacciones.

Las cuentas de Ethereum son entidades con un saldo en ether (ETH) y la capacidad de enviar transacciones en la cadena de bloques de Ethereum. Se representan como una “dirección” hexadecimal de 42 caracteres, que sirve como indicador único de los activos y transacciones de la cuenta.

Una dirección actúa como una clave para el trie de estado de la cadena de bloques. Los nodos de hoja de este trie son estructuras de datos de cuenta que se pueden descomponer en cuatro campos:

1. nonce : contador lineal que se utiliza para indicar la cantidad de transacciones salientes iniciadas por una cuenta. También es fundamental para prevenir ataques de repetición.
2. balance : la cantidad de ether (ETH) denominada en wei que posee una cuenta.
3. codeHash : un hash del código ejecutable de EVM contenido en una cuenta. La EVM (Máquina Virtual de Ethereum) es el entorno de ejecución a medida de Ethereum responsable de gestionar transiciones de estado complejas más allá de las simples transacciones de "envío". El contenido del código de una cuenta está programado de forma inmutable para llevar a cabo formas específicas de transición de estado en la cadena de bloques de Ethereum, a través de la EVM.
4. storageHash : un hash de la raíz de almacenamiento de una cuenta, que se utiliza para representar el contenido de almacenamiento de una cuenta como un hash de 256 bits del nodo raíz de un trie de Merkle Patricia. En pocas palabras, es un hash de los datos de la variable de estado relacionados con el contenido del código de una cuenta.

El contenido de estos cuatro campos se utiliza para definir el tipo de cuenta y, en última instancia, el alcance de sus funcionalidades. Por lo tanto, los dos tipos de cuentas de Ethereum son:

1. Cuentas de propiedad externa (EOA) , que se inicializan como un par de claves criptográficas:

• Una clave privada que es un carácter hexadecimal de 64 bits cifrable y demostrablemente aleatorio, y su contraparte complementaria;
• Una clave pública que se deriva de la clave privada utilizando el ECDSA (algoritmo de firma digital de curva elíptica).

Las EOA tienen campos codeHash y storageHash vacíos y solo pueden ser controladas por cualquiera que posea las claves privadas. Sus direcciones se pueden obtener de la clave pública correspondiente anteponiendo “0x” a los últimos veinte caracteres del hash keccak-256 de la clave pública de la cuenta.

2. Cuentas de contrato (CA) que solo pueden ser creadas por una EOA preexistente. Se inicializan debido a que una EOA implementa contenido de código ejecutable en la EVM. Este contenido de código (almacenado como codeHash) está consagrado en la EVM y es responsable de controlar la cuenta definiendo su lógica e interacciones.

Las transacciones de una cuenta de contrato se basan completamente en la extracción y se basan en la lógica de su código implementado. Dado que estas cuentas solo se pueden controlar mediante el contenido de su código, no necesitan una clave privada y solo tienen una clave pública. Por lo tanto, cualquier agente que tenga la capacidad de actualizar o cambiar el contenido del código de una cuenta de contrato podría acceder a su saldo. La dirección de una cuenta de contrato se deriva de la dirección de su creador y su nonce hasta el momento de la implementación del contrato.

Actas

Recientemente describimos las cuentas como entidades que poseen la capacidad de enviar transacciones a través de Ethereum. Por lo tanto, podemos entender que un propósito principal de una cuenta es enviar y recibir transacciones, mientras que la cadena de bloques actúa como un libro de contabilidad que registra el historial de transacciones y describe cómo las transacciones alteran los campos de la cuenta según las reglas descritas en la especificación del protocolo de la cadena de bloques.

Entonces, ¿qué son estas “transacciones”?

Las transacciones son operaciones enviadas desde una cuenta que provocan un cambio en el “estado” de la red. Son instrucciones firmadas criptográficamente desde cuentas que, al ejecutarse, dan como resultado una actualización del estado de toda la red.

La falta de permisos conlleva el costo de incentivos perversos; para lidiar con ellos, se deben definir pautas estrictas (o reglas de validez) para las interacciones en dichos entornos. En este contexto, las transacciones deben cumplir ciertas reglas de validez para ser consideradas válidas y ejecutadas. La mayoría de estas reglas de validez se implementan a través de restricciones impuestas a la cuenta que envía la transacción y varían según el tipo de cuenta.

Validez de cuentas y transacciones

En Ethereum, las EOA están optimizadas para su uso, ya que están orientadas al usuario final. Tienen la capacidad de enviar transacciones de una manera específica y funcionan perfectamente de forma autónoma. También se pueden crear de forma local, siendo el método más común el uso de proveedores de billeteras como MetaMask, Rainbow, Rabby, etc.

Por otro lado, las cuentas de contrato solo pueden enviar transacciones permitidas por su lógica, en respuesta a ser “ llamadas ”. Además, solo pueden ser creadas por una EOA que tenga saldo suficiente para pagar su almacenamiento estatal.

Una descripción más detallada sería que las EOA solo pueden tener un saldo, mientras que las CA pueden tener tanto un saldo como una lógica que dicta cómo se puede gastar este saldo. Estas propiedades se deben a los siguientes parámetros lógicos que definen las reglas que deben cumplir las transacciones de una cuenta:

1. Lógica de autenticación : se utiliza para definir cómo una cuenta demuestra su identidad a la red mientras cambia su saldo y/o lógica.
2. Lógica de autorización : se utiliza para definir la política de acceso de una cuenta, es decir, quién puede acceder y realizar cambios en el saldo y/o la lógica de la cuenta.
3. Lógica Nonce : que define el orden en que deben ejecutarse las transacciones de una cuenta.
4. Lógica de pago de gas : se utiliza para definir la parte responsable de liquidar la tarifa de gas de una transacción.
5. Lógica de ejecución : se utiliza para definir qué formas de transacciones puede enviar una cuenta o cómo se ejecutará una transacción.

Estos parámetros están diseñados para ser rígidos para los EOA, por lo tanto:

• La autenticación y autorización se proporciona mediante una clave privada basada en ECDSA, es decir, un usuario que desee enviar una transacción desde su EOA deberá utilizar su clave privada para acceder a la cuenta y así demostrar que tiene derecho a realizar cualquier cambio en el saldo de la misma.
• La lógica nonce implementa un esquema de contador secuencial, que permite que solo se ejecute una transacción por nonce único de forma secuencial por cuenta.
• La lógica de pago de gas especifica que la tarifa de gas para las transacciones debe ser liquidada por la cuenta del remitente/originadora.
• La lógica de ejecución especifica que los EOA solo pueden enviar los siguientes formularios de transacción:

1. Transferencias regulares entre dos EOA.
2. Implementación del contrato.
3. llamadas de contrato que apuntan a la lógica de una cuenta de contrato implementada.

De manera más general, la lógica de ejecución de los EOA los limita a una transacción por firma válida.

Por otro lado, las CA tienen más flexibilidad en torno a estos parámetros:

• La autenticación no es necesaria, ya que sus transacciones son de naturaleza consecuente/basada en extracción.
• La autorización para las CA puede adoptar dos formas:

1. Capacidad de “ llamar ” al código de contenido de la CA (o ejecutar su contrato inteligente), que depende de la lógica del contrato inteligente de la cuenta y sus invariantes.
2. Capacidad de realizar cambios en el código de contenido de las CA, que depende principalmente de si el código de contenido es actualizable o no.

En la mayoría de los casos prácticos, la lógica utilizada en este caso es un esquema de múltiples firmas que estipula que se requiere una M de N firmas válidas (donde M < N) de cuentas específicas (comúnmente EOA) para que un cambio en la lógica de la CA sea válido.

• Su orden de transacciones se basa en el nonce. La propia CA puede enviar tantas transacciones a tantos interlocutores diferentes como sea posible, sin embargo, cada interlocutor está limitado en función de sus propias capacidades.
• El pago del gas normalmente lo gestiona el llamador de la lógica de la CA.
• La lógica de ejecución de las CA es más diversa para permitir mejoras en la experiencia del usuario, como transacciones de múltiples llamadas y transacciones atómicas.

Al evaluar estas características, observamos que cada tipo de cuenta está diseñado para tener un equilibrio entre autonomía y programabilidad.

Las EOA tienen plena autonomía pero una capacidad de programación limitada; pueden autorizar y enviar transacciones cuando quieran, pero estas transacciones deben seguir un formato rígido para ser consideradas válidas. Las cuentas de contrato tienen plena capacidad de programación (limitada únicamente por el diseño de la EVM) pero una autonomía limitada: sus transacciones no tienen que seguir ningún formato rígido, pero solo pueden enviarse debido a que su lógica se llama primero.

En la siguiente subsección, estudiaremos ahora las implicaciones de estas opciones de diseño, con el fin de comprender plenamente la propuesta de cada EIP analizado a lo largo de esta serie.

El dilema de la cuenta de Ethereum

Ahora que tenemos un conocimiento un tanto sucinto de las funcionalidades de las diferentes cuentas, podemos identificar fácilmente sus puntos de venta, así como los problemas que presentan tanto para la experiencia del usuario como para la del desarrollador en Ethereum. Como mencionamos anteriormente, las EOA están diseñadas como cuentas de primera clase dirigidas a los usuarios finales. Las aplicaciones están diseñadas para interactuar fácilmente con ellas, casi no tienen complejidad y, por supuesto, no hay ningún costo por crear una. Sin embargo, su simplicidad conlleva una pérdida significativa de novedad, ya que están diseñadas para ser estrictamente deterministas.

Algunas de las preocupaciones en torno a ellos son:

1. Susceptibilidad a ataques cuánticos : el esquema de firma ECDSA utilizado por su par de claves no es resistente a los ataques cuánticos, y con un cronograma optimista de 5 a 10 años para que se logren los sistemas cuánticos industriales, esto representa una amenaza significativa para Ethereum y sus aplicaciones que dependen en gran medida del esquema ECDSA para pruebas criptográficas y seguridad.
2. Falta de expresión : el formato rígido de las reglas de validez de las EOA elimina la capacidad de los usuarios de expresar sus transacciones de manera más sucinta a través de características como la atomicidad y el agrupamiento de las transacciones, y la delegación de transacciones.
3. Autosostenibilidad : todos hemos tenido nuestra cuota de momentos en los que nos hemos quedado sin gas en medio de una transacción. Esto se debe al requisito de que las EOA liquiden el gas de sus transacciones por sí mismas, lo que no sería una gran tarea si ether (ETH) no fuera la única moneda de gas aceptable. Si bien este es un problema general con las máquinas de estado basadas en cuentas (e incluso las basadas en UTXO), Ethereum siempre tuvo la intención de ser diferente.

No todo el mundo quiere (o podría) tener siempre ETH (quiero decir, mire la acción del precio), por lo que las soluciones viables serían permitir múltiples monedas de gas (demasiado difícil, rompe demasiadas invariantes como se describe en la sección "Moneda" aquí ), o permitir que los pagos de gas se liquiden mediante otra cuenta que no sea el origen de la transacción.

En el otro extremo del espectro de cuentas, las CA están dirigidas a desarrolladores y a una base de usuarios más técnicos. Sirven como vehículos para los contratos inteligentes (es decir, consideramos que los contratos inteligentes son su lógica o contenido de código) y, por lo tanto, pueden implementar formatos de transacción novedosos, tal como lo permite la EVM.

Sin embargo, a pesar de todas estas características, son cuentas de segunda clase glorificadas, ya que no tienen autonomía. Algunos de sus inconvenientes son los siguientes:

1. Falta total de autonomía : las CA no pueden iniciar una transacción, solo pueden enviar transacciones en respuesta a ser invocadas de una manera muy particular.
2. Susceptibilidad a errores humanos en su lógica : la falta de rigidez a menudo conduce a una definición incorrecta de invariantes y otras lógicas similares, lo que ha provocado miles de millones de dólares en pérdidas debido a ataques y hackeos a contratos inteligentes. Sin embargo, este es un tema completamente diferente que queda fuera de nuestro alcance aquí.

Después de revisar las opciones de diseño que llevaron a los problemas definidos en esta subsección, ahora podemos proceder a evaluar las soluciones propuestas.

Una cronología de la abstracción de cuentas

Para poder descubrir qué se puede abstraer, necesitamos una imagen (en cierta medida) completa del diseño actual de las cuentas. Esta sección servirá principalmente como una especie de revisión de lo que son realmente las cuentas en Ethereum y cómo se validan y ejecutan sus transacciones.

El concepto de abstracción de cuentas (al menos a través de cuentas inteligentes) siempre ha sido una parte integral de la hoja de ruta de Ethereum. La tradición dice que la complejidad que rodea su implementación amenazó con retrasar aún más el lanzamiento de Ethereum, por lo que se descartó para el diseño actual con diferentes cuentas que ofrecen diferentes funcionalidades. Se retrasó nuevamente por el enfoque de Ethereum en The Merge, y ahora está resurgiendo como una parte principal de la próxima gran actualización de la red: Pectra. Sin embargo, su complejidad todavía se considera un inconveniente significativo que impide su consagración, especialmente ahora que Ethereum ha pivotado hacia una hoja de ruta centrada en la acumulación.

Los requisitos ahora son dobles:

1. Los estándares de contabilidad deben ser más expresivos, pero sin perder autonomía. Un nuevo estándar que cierre la brecha entre los estándares EOA y CA.
2. El nuevo estándar tiene que cerrar la brecha entre las EOA y las CA, y al mismo tiempo seguir siendo totalmente compatible con Ethereum y sus ecosistemas L2.

Intuitivamente, este concepto desempeña un papel más importante en el contexto de la abstracción de la cadena y la interoperabilidad. Sin embargo, nuestro alcance en este informe se limita a las iniciativas técnicas adoptadas para lograr la abstracción de la cuenta en sí.

La abstracción de cuentas tiene como objetivo combinar las mejores características de las EOA y las CA en un nuevo estándar de cuentas: las cuentas inteligentes , que permiten la separación total o parcial de las reglas de validez de cualquier cuenta en una lógica de validación y una de ejecución; de modo que las cuentas puedan definir sus propias reglas de validez (según lo permita el EVM), al igual que las cuentas de contrato, mientras permanecen completamente autónomas como las cuentas de propiedad externa.

A menudo existe confusión en torno a las diferencias entre cuentas inteligentes y billeteras de contratos inteligentes , por lo que describiremos explícitamente cuáles son estas diferencias a continuación:

• Las cuentas inteligentes son cuentas de Ethereum que están diseñadas para ofrecer partes iguales de programabilidad y autonomía. La idea es que tanto las EOA como las CA puedan convertirse en cuentas inteligentes simplemente utilizando algún mecanismo (por ejemplo, ERC 4337) que les permita reemplazar sus reglas de validez impuestas por la red con reglas de validez personalizadas, según lo consideren conveniente.
• Por otro lado, las billeteras de contratos inteligentes son simplemente proveedores de billeteras que sirven como interfaces para las cuentas de contratos (sí, una billetera no es una cuenta).

La comercialización de billeteras de contratos inteligentes facilitó la adopción de las CA por parte de un mercado más amplio, lo que permitió que los usuarios menos técnicos aprovecharan las características que ofrecen. Sin embargo, aún enfrentan los inconvenientes asociados con las CA.

Volviendo a la conversación, ya habíamos discutido anteriormente los parámetros que se utilizan para definir las reglas de validez de las transacciones de las cuentas:

• Autenticación
• Autorización
• Lógica nonce
• Lógica de pago de gas
• Lógica de ejecución

Los valores de los primeros cuatro parámetros pueden denominarse colectivamente lógica de validación de una cuenta, que son comprobaciones que se realizan antes de que comience la ejecución de una transacción. El último parámetro define cómo debe proceder la ejecución de la transacción.

En la introducción, brindamos una descripción general de alto nivel del panorama actual de AA en forma de una clasificación de los diversos diseños propuestos. Ahora nos centraremos en la primera clase de soluciones al dilema de las cuentas de Ethereum: la programabilidad EOA.

EOA programables

El mayor atractivo de Ethereum es su joven pero vibrante ecosistema DeFi, que cuenta con una variedad de aplicaciones descentralizadas que son sus principales sumideros de liquidez. La mayoría de estas DApps están optimizadas para servir a las EOA, por lo que es difícil interactuar con ellas con cuentas de contrato y, eventualmente, con cuentas inteligentes. Si bien las billeteras de contrato inteligentes ayudan a las cuentas de contrato en este caso, tienen sus propias limitaciones y una experiencia de usuario completamente diferente.

Una solución provisional que se está explorando mientras tanto las DApps como los proveedores de billeteras se acostumbran al estándar de cuentas inteligentes es proporcionar mejoras temporales a las EOA que les permitan superar la mayoría de las restricciones impuestas, ya sea su lógica de validación o ejecución. A continuación, repasamos las especificaciones de tres EIP principales que brindan rutas viables para la programabilidad de EOA; desde la menos conocida EIP 5806 , hasta la ambiciosa EIP 3074 y, finalmente, la victoriosa EIP 7702 .

Programabilidad mediante EIP-5806

Esta propuesta busca aportar más funcionalidad al estándar EOA al permitirle realizar llamadas delegadas a la lógica de una cuenta de contrato (su contrato inteligente). Esto hace que el contrato inteligente se ejecute en el contexto del EOA que realiza la llamada, es decir, el EOA mantiene el control de su lógica de validación, mientras que su lógica de ejecución es manejada por la lógica de la cuenta de contrato correspondiente.

Antes de continuar, hagamos un viaje por el camino de la memoria de la evolución de Ethereum hasta EIP-7 . EIP-7 propuso la creación del código de operación 0xf4/DELEGATECALL , que se utiliza para enviar llamadas de mensajes a una cuenta principal con la lógica de una cuenta secundaria, mientras se mantienen los valores de los campos [sender] y [value] de la cuenta principal. En otras palabras, la cuenta principal "hereda" (o toma prestada, si lo prefiere) la lógica de la cuenta secundaria durante un tiempo especificado en la llamada de mensaje, de modo que la lógica de esta última se ejecuta en el contexto de la primera.

Este código de operación permitió a los desarrolladores de dapp dividir la lógica de su aplicación en múltiples contratos inteligentes mientras mantenían la interdependencia, de modo que pudieran sortear fácilmente las barreras del tamaño del código y las barreras del gas. EIP-5806 encuentra un nuevo uso para el código de operación DELEGATECALL más allá de permitir que las cuentas de contrato sean interdependientes. Específicamente, EIP-5806 usa EIP-7 como inspiración para proponer la expansión de la funcionalidad de llamada de delegado también a los EOA; es decir, permitamos que los EOA también sean interdependientes con las cuentas de contrato, porque por qué no.

Especificaciones de EIP-5806

EIP 5806 introduce un nuevo tipo de transacción compatible con EIP-2718 que se presenta de la siguiente manera:

 rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]).

Estas transacciones están diseñadas para que el campo [para], que representa la dirección del destinatario, solo pueda aceptar direcciones como entradas de 20 bytes, lo que impide al remitente utilizar el código de operación CREATE .

La motivación detrás de cada componente del esquema RLP es la siguiente:

• chainID : identificador de la cadena actual que cumple con la norma EIP-115, con un tamaño de relleno de 32 bytes. Este valor proporciona protección contra ataques de repetición, de modo que las transacciones en la cadena original no se repliquen trivialmente en cadenas EVM alternativas con un historial similar y una seguridad económica menor.
• nonce : un identificador único para cada transacción que también proporciona protección contra ataques de repetición.
• max_priority_fee_per_gas y max_fee_per_gas : los valores de la tarifa de gas que una transacción EIP-5806 debe pagar por el pedido y la inclusión respectivamente.
• gas_limit : la cantidad máxima de gas que una sola transacción de tipo 5806 puede consumir.
• destino : El destinatario de la transacción
• datos : El contenido del código ejecutable
• access_list : Agentes que están autorizados condicionalmente para ejecutar transacciones EIP-5806.
• signature_y_parity, signature_r y signature_s : tres valores que juntos representan una firma secp256k1 sobre el mensaje — keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

Si bien el empaquetado de transacciones EIP-5806 en sobres EIP-2718 les permite una gran compatibilidad con versiones anteriores, las EOA no son equivalentes a las cuentas de contrato. Por lo tanto, se deben definir ciertas restricciones en la forma en que una EOA utiliza las llamadas de delegados para evitar la ruptura de invariantes.

Estas restricciones están dirigidas a los siguientes códigos de operación:

• SSTORE/0x55 : este código de operación permite que una cuenta guarde un valor en el almacenamiento. Está restringido en las transacciones EIP-5806 para evitar que los EOA configuren o accedan al almacenamiento mediante llamadas de delegados, lo que evita posibles problemas que puedan surgir en el futuro debido a la migración de cuentas.
• CREATE/0xF0 , CREATE2/0xF5 y SELFDESTRUCT/0xFF : estos códigos de operación permiten al autor de la llamada crear una nueva cuenta. El acceso a estos está restringido para evitar la alteración de un nonce de EOA en un marco de ejecución diferente (creación/destrucción de contrato en este caso) mientras se realiza una transacción EIP-5806, con el fin de evitar la invalidación de la expectativa de que las transacciones lleven nonces consecutivos.

Posibles aplicaciones de la EIP-5806

La principal aplicación de EIP-5806 es la abstracción de ejecución para los EOA. Permitir que los EOA interactúen sin confianza con los contratos inteligentes más allá de simples llamadas a su lógica les otorga características como:

• Ejecución condicional de transacciones
• Agrupamiento de transacciones
• Transacciones de múltiples llamadas (por ejemplo, aprobar y llamar)

Críticas a la EIP-5806

Los cambios propuestos por EIP-5806, si bien permiten funciones necesarias, no son particularmente novedosos; su existencia se basa principalmente en una EIP-7 ya funcional. Esto le permite superar muchos obstáculos potenciales para su aceptación.

Una de las principales preocupaciones expresadas en sus inicios fue el riesgo potencial de permitir que las EOA accedieran al almacenamiento y lo modificaran, tal como lo hacen actualmente las CA. Esto rompe muchas de las invariantes consagradas en la red sobre cómo deben realizar transacciones las EOA, por lo que se abordó introduciendo las restricciones mencionadas en la subsección anterior.

Una segunda crítica (que es un arma de doble filo) es la simplicidad de EIP-5806; existe la sensación de que las recompensas por aceptar EIP-5806 podrían no valer la pena, ya que solo permite la abstracción de la ejecución y no mucho más. Todas las demás restricciones de validez siguen estando definidas por la red para las EOA que optan por EIP-5806, a diferencia de otras EIP algo similares que analizamos en las siguientes subsecciones.

Programabilidad mediante EIP-3074

La EIP-3074 propone permitir que las EOA deleguen la mayor parte de su lógica de validación a cuentas de contrato especializadas, denominadas invocadores, superponiendo la lógica de autorización de estos últimos sobre la suya para formas específicas de transacciones. Esto se logra mediante la transferencia de su política de acceso a un contrato de invocador, que luego se vuelve responsable de definir la política de acceso de la EOA.

Este EIP propone la adición de dos nuevos códigos de operación al EVM:

• [AUTH] que establece una cuenta [autorizada] de variable de contexto para actuar en nombre de una segunda cuenta [autoridad], basándose en la firma ECDSA de esta última.
• [AUTHCALL] que envía/implementa llamadas para la cuenta [autoridad] desde/como la cuenta [autorizada].

Estos dos códigos de operación permiten que una EOA delegue el control a una CA preestablecida y, por lo tanto, actúe como una sola a través de ella, sin tener que implementar un contrato e incurrir en los costos y externalidades asociados con ello.

Especificaciones de la EIP-3074

EIP-3074 permite que las transacciones utilicen un formato de firma [MAGIC] para evitar colisiones con otros formatos de firma de transacciones. La cuenta activa a la que se pasan las instrucciones [AUTHCALL] se define como un campo de variable de contexto llamado [authorized], que solo persiste a través de una única transacción y debe redefinirse para cada nuevo [AUTHCALL] .

Antes de abordar las complejidades de cada código de operación, estas son las entidades involucradas en una transacción EIP-3074:

• [autoridad] : La cuenta de firma principal (una EOA) que delega el acceso/control a una segunda cuenta, que normalmente es una cuenta de contrato.
• [authorized] : La cuenta a la que se deben pasar las instrucciones [AUTHCALL] para su ejecución. En otras palabras, es la cuenta en la que se ejecuta la lógica de una [AUTHCALL] , en nombre de la [autoridad], utilizando restricciones definidas por un [invocador].
• [invocador] : contrato subsidiario destinado a gestionar las interacciones entre la cuenta [autorizada] y la lógica de [AUTHCALL] , especialmente en los casos en que la lógica principal del código de contrato de este último es el patrocinio de gas.

Los contratos de invocador reciben mensajes [AUTH] con un valor [COMMIT] de [authority]; este valor define las restricciones que la cuenta desea imponer a la ejecución de las instrucciones [AUTHCALL] por parte de [authorized]. Por lo tanto, los invocadores son responsables de garantizar que el [ contract_code ] definido en una cuenta [authorized] no sea malicioso y tenga la capacidad de satisfacer las invariantes colocadas por la cuenta de firma principal en un valor [COMMIT].

El código de operación [AUTH] tiene tres entradas de elementos de pila; o, dicho de manera más simple, se define mediante tres entradas que calculan una única salida. Estas entradas son:

1. autoridad : que es la dirección de la EOA que genera la firma
2. compensar
3. longitud

Las dos últimas entradas se utilizan para describir un rango de memoria modificable de 0 a 97, donde:

1. [memory(offset : offset+1)] – [yParity]
2. [memory(offset+1 : offset+33] – [r]
3. [memory(offset+33 : offset+65)] – [s]
4. [memory(offset+65 : offset+97)] – [COMMIT]

Las variables [yParity], [r] y [s] se interpretan colectivamente como una firma ECDSA, [magic], en la curva secp256k1 sobre el mensaje:

[keccak256 (MAGIC || chainID || nonce || invoker address || COMMIT)]

dónde:

• [MAGIC] es una firma ECDSA resultante de la combinación de las variables:
• [chainID], que es el identificador compatible con EIP 115 de la cadena actual, que se utiliza para proporcionar protección contra ataques de repetición en cadenas EVM alternativas con un historial similar y menos seguridad económica.
• [nonce] que es el nonce actual de la dirección del firmante de la transacción, rellenado a la izquierda hasta 32 bytes.
• [invokerAddress] que es la dirección del contrato que contiene la lógica para la ejecución de [AUTH] .
• [COMMIT] es un valor de 32 bytes que se utiliza para especificar condiciones de validez de transacción adicionales en la lógica de preprocesamiento del invocador.

Si la firma calculada es válida y la dirección del firmante es [autoridad], el campo [autorizado] se actualiza al valor proporcionado por [autoridad]. Si no se cumple alguno de estos requisitos, el campo [autorizado] permanece sin cambios en su estado anterior o como un valor no definido.

El costo del gas para este código de operación se calcula como la suma de:

1. Una tarifa fija por la precompilación de [ecrecover] y un extra por un hash keccak256 y algo de lógica adicional, valorada en 3100 unidades

2. Una tarifa de expansión de memoria que se calcula de manera similar al código de operación [RETURN] y se aplica cuando la memoria se expande más allá del rango especificado de la asignación actual (97 unidades)

3. Un costo fijo de 100 unidades incurridas para una [autoridad] cálida y 2600 unidades para una fría para prevenir ataques debido a precios incorrectos de códigos de operación de acceso al estado.

   
   

   ( AUTH está implementado para no modificar la memoria y toma el valor de [autoridad] como argumento, de modo que es trivial verificar su valor a partir de la firma proporcionada).

El código de operación [AUTHCALL] tiene siete entradas de elementos de pila que se utilizan para calcular una única salida de elemento de pila.

Tiene la misma lógica que el código de operación [CALL] , es decir, se utiliza para enviar llamadas de mensajes a una cuenta y activar una lógica específica en sus contratos. La única desviación de su lógica es que [AUTHCALL] está diseñado para establecer el valor de [CALLER] antes de proceder con la ejecución.

De esta forma, la [autoridad] utiliza [AUTHCALL] para activar un comportamiento específico del contexto en [autorizado] con comprobaciones lógicas que proceden de la siguiente manera:

1. Compruebe el valor de [authorized]. Si no se establece, la ejecución se considera inválida y se sale del marco inmediatamente. Esto ayuda a evitar cargos injustos debido a fallas sin precedentes.
2. Comprueba el costo del gas del comportamiento previsto de [autorizado].
3. Comprueba el valor compatible con EIP-150 del operando [gas].
4. Verifica la disponibilidad del costo total del gas –[valor]– en el saldo de [autoridad].
5. La ejecución se produce tras la deducción de [valor] del saldo de la cuenta de [autoridad]. Si [valor] es mayor que su saldo, la ejecución queda invalidada.

El costo del gas para [AUTHCALL] se calcula como la suma de:

• Un costo fijo por llamar a [warm_storage_read]
• Un costo de expansión de memoria [memory_expansion_fee] , que se calcula de manera similar al costo del gas para el código de operación [CALL]
• Un coste dinámico [dynamic_gas]
• El costo de ejecución de la subllamada [subcall_gas]

Se accede a los datos devueltos de un [AUTHCALL] a través de:

• [RETURNDATASIZE] – que aumenta el tamaño del búfer de datos de retorno a la pila de salida
• [RETURNDATACOPY] – que copia los datos del búfer de datos de retorno a la memoria.

Para resumir todo esto con menos lenguaje técnico, las transacciones de Ethereum generalmente especifican dos valores:

1. tx.origin – que proporciona autorización para la transacción.
2. msg.sender – en el que realmente ocurre la transacción.

En las EOA, como se mencionó anteriormente, la autorización está estrechamente vinculada a la ejecución, es decir, ( tx.origin == msg.sender ). Esta simple invariante da lugar a la mayoría de los problemas que explicamos en la subsección “Validez de las cuentas y las transacciones” de este informe.

Los mensajes [AUTH] de [authority] le permiten desplazar la función tx.origin a [authorized], mientras sigue siendo el remitente del mensaje. También le permite definir restricciones a este privilegio utilizando un valor [COMMIT]. [AUTHCALL] luego le permite a [authorized] acceder a la lógica de un contrato, utilizando un [invoker] como intermediario para garantizar que el contrato al que desea acceder sea inofensivo. Es decir, para cada [AUTHCALL] , [authorized] debe especificar un [invoker] particular para su [COMMIT].

Posibles aplicaciones de la EIP-3074

La EIP 3074 es la principal responsable de permitir que las EOA deleguen su lógica de autorización a una cuenta diferente; sin embargo, su diseño abierto permite mucho más en diferentes contextos. La lógica de validación completa de una EOA se puede abstraer aplicando varias restricciones/innovaciones al invocador según sea necesario. Algunos de los diseños posibles basados en su lógica de destino incluyen:

• Lógica de nonce : EIP-3074 permite que el nonce de los EOA permanezca intacto después de enviar un mensaje [AUTH] , mientras que su nonce para cada [AUTHCALL] depende de con qué invocador está interactuando. De esta manera, permite el paralelismo de nonce para los EOA, de modo que puedan enviar múltiples [AUTHCALL] que no se superpongan según lo deseen.
• Lógica de pago de gas : como se especifica en el EIP, los invocadores pueden diseñarse para permitir el patrocinio de gas. De esta manera, las tarifas de gas para el [COMMIT] de un usuario podrían deducirse del origen de la transacción o de cualquier cuenta de apoyo, ya sea personal o de un relé basado en servicios (servicios de patrocinio de gas). Además, la lógica de ejecución se abstrae intuitivamente; después de todo, el invocador (que es una CA) ahora es responsable de ejecutar las solicitudes de transacción en nombre de la EOA.

Críticas a la EIP-3074

Centralización de invocadores

Citando a uno de sus autores: “ No esperaría que las billeteras expongan funcionalidad para ceder el acceso a invocadores arbitrarios… ”. Quizás el mayor problema que plantea la iniciativa 3074 es que la innovación que se basa en ella tenderá muy fácilmente a flujos de transacciones con permisos y propietarios; al igual que las iteraciones actuales de los mercados MEV (valor máximo extraíble) y PBS (separación entre proponente y constructor) de Ethereum.

De manera predeterminada, los contratos de invocador deben ser auditados exhaustivamente para evitar ataques aún peores que los que son posibles actualmente. Esto inevitablemente tenderá a un ecosistema en el que solo un puñado de contratos de invocador desarrollados por figuras influyentes serán adoptados como predeterminados por los desarrolladores de billeteras. Por lo tanto, se reduce a una disyuntiva entre:

• Tomar el camino descentralizado y difícil de auditar y respaldar constantemente los contratos de invocador con riesgo de la seguridad de los usuarios.
• Adoptar contratos de invocador de fuentes establecidas y confiables con mejores garantías para la seguridad del usuario y menos supervisión sobre la seguridad del contrato.

Otro aspecto de este punto es la función de costos asociada con el diseño, la auditoría y la comercialización de un invocador funcional y seguro. Los equipos más pequeños casi siempre serán superados por organizaciones más grandes, especialmente en el frente de marketing, que ya tienen cierta reputación establecida, incluso si su producto es mejor.

Problemas de compatibilidad con versiones posteriores

La EIP-3074 consolida el esquema de firma ECDSA, ya que todavía se considera más válido que el esquema de autorización introducido a través del invocador. Si bien existen argumentos de que la resistencia cuántica no es actualmente un problema definitivo (y que hay mucho peor en juego en un futuro en el que ECDSA sea corruptible), el objetivo un tanto tácito de Ethereum es estar siempre por delante de tales problemas. Sacrificar potencialmente la resistencia cuántica y a la censura por mejoras marginales en la experiencia de usuario podría no ser la mejor de las opciones en el futuro cercano.

Otro punto en el argumento de compatibilidad futura es que, si bien los beneficios de 3074 todavía se estaban evaluando, ERC-4337 (que no requiere ningún cambio de protocolo) ahora tiene un gran mercado, por lo que también debe ser compatible con él para evitar la compartimentación de los ecosistemas. Incluso con la hoja de ruta de abstracción de cuentas nativas, los códigos de operación [AUTH] y [AUTHCALL] eventualmente se volverían obsoletos en el EVM, lo que introduciría una gran cantidad de deuda técnica en Ethereum para poder ofrecer una cantidad marginal de mejora en la experiencia del usuario.

Irrevocabilidad del sistema ECDSA

Después de enviar un mensaje [AUTH] y delegar el control, se espera que la EOA evite el esquema habitual de autorización de clave privada, ya que el envío de una transacción “normal” hace que se revoque la autorización que delegó a cada invocador. Por lo tanto, el esquema ECDSA sigue siendo estrictamente superior a cualquier otro esquema de autorización que los contratos asociados puedan habilitar, lo que significa que una pérdida de claves privadas daría como resultado una pérdida total de los activos de la cuenta.

Programabilidad mediante EIP-7702

Esta propuesta se había planteado inicialmente como una variación algo minimalista de la EIP 3074, e incluso se pretendía que fuera una actualización de la misma. Nació para abordar las supuestas ineficiencias de la EIP 3074, especialmente las preocupaciones en torno a su incompatibilidad con el ya floreciente ecosistema 4337 y la propuesta de abstracción de cuentas nativas: RIP 7560.

Su enfoque es la incorporación de un nuevo tipo de transacción compatible con EIP 2718 ( [SET_CODE_TX_TYPE] ), que permite que una EOA se comporte como una cuenta inteligente para transacciones específicas. Este diseño permite las mismas funciones que EIP 5806 y algunas más, al tiempo que sigue siendo compatible con la hoja de ruta de abstracción de cuentas nativas y las iniciativas existentes.

Especificaciones del EIP-7702

EIP-7702 permite que una EOA “importe” el contenido del código de un contrato a través de una transacción compatible con [SET_CODE_TX_TYPE] 2718 del formato:

 rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Esta carga útil es completamente similar a la de EIP 5806, excepto que introduce una “lista de autorización”. Esta lista es una secuencia ordenada de valores con el formato:

[[chain_id, address, nonce, y_parity, r, s], ...]

donde cada tupla define el valor de [dirección].

Antes de continuar, las partes involucradas en un SET_CODE_TX_TYPE son:

• [autoridad] : cuál es la cuenta de firma principal/EOA
• [dirección] : que es la dirección de una cuenta que contiene código delegable.

Cuando [autoridad] firma un SET_CODE_TX_TYPE que especifica [dirección], se crea un designador de delegación. Se trata de un “programa puntero” que hace que todas las solicitudes de recuperación de código debidas a las acciones de [autoridad] en cualquier instante se canalicen al código observable de [dirección].

Para cada tupla [chain_id, address, nonce, y_parity, r, s] , el flujo lógico de una transacción de tipo 7702 es el siguiente:

1. Verificación de la firma de [autoridad] a partir del hash proporcionado usando: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. Prevención de ataques de repetición entre cadenas y otros vectores de ataque mediante la verificación del ID de la cadena.
3. Comprobando si [autoridad] ya tiene contenido de código.
4. Comprobación de nonce para garantizar que el nonce de [autoridad] sea igual al nonce incluido en la tupla.
5. Si la transacción es la primera transacción SET_CODE_TX_TYPE de [autoridad], se le cobra una tarifa PER_EMPTY_ACCOUNT_COST . En caso de que su saldo sea menor al valor de esta tarifa, se abandona la operación.
6. Se produce la designación de delegación, en la que el código de [autoridad] se establece en un puntero de la [dirección].
7. El nonce del firmante –[autoridad]– se incrementa en uno.
8. [autoridad] se agrega a una lista de direcciones a las que se accede, que (simplificando) es un conjunto de direcciones que se crean de tal manera que la reversión de un ámbito de una transacción desde ellas hace que (la dirección) vuelva a su estado anterior, antes de que se ingresara al ámbito revertido. Esto se define en EIP-2929 para permitir el almacenamiento en caché de valores reutilizables y evitar cargos innecesarios.

¡Uf! Para resumir, este EIP permite a los EOA enviar transacciones que establecen un puntero al código de un contrato, lo que les permite implementar esta lógica como propia en transacciones posteriores. De esta manera, es estrictamente más fuerte que el EIP 5806, porque permite a los EOA tener contenido de código durante el tiempo que quieran (a diferencia del EIP 5806, que simplemente permite a los EOA enviar llamadas de delegados).

Posibles aplicaciones de la EIP-7702

Abstracción de ejecución

Si bien se podría argumentar que ya no es una abstracción, ya que el EOA toma activamente la lógica que desea ejecutar, aún no es el "propietario principal" de dicha lógica. Además, no contiene lógica directamente , simplemente especifica un puntero a la lógica (para reducir la complejidad computacional). ¡Así que vamos con la abstracción de ejecución!

Patrocinio de gas

Si bien la invariante require(msg.sender == tx.origin) está rota para permitir el auto-patrocinio, el EIP aún permite la integración de retransmisores de transacciones patrocinadas. Sin embargo, la salvedad es que dichos retransmisores necesitan un sistema basado en la reputación o en la participación para evitar ataques de duelo.

Políticas de acceso condicional

Los EOA solo pueden apuntar a una parte específica del código de la cuenta, de modo que solo la lógica de esa parte sea ejecutable en su contexto.

Esto también permite la existencia de subclaves que permiten la "desescalada de privilegios", de modo que determinadas aplicaciones descentralizadas solo tengan acceso al saldo de una cuenta en determinadas condiciones. Por ejemplo, se podría imaginar un permiso para gastar tokens ERC-20 pero no ETH, o para gastar hasta el 1 % del saldo total por día, o para interactuar solo con aplicaciones específicas.

Implementación de contratos inteligentes entre cadenas

Debido a su naturaleza no restrictiva, una transacción EIP-7702 podría permitir a un usuario acceder al código de operación CREATE2 y usarlo para implementar un código de bytes en una dirección sin ningún otro parámetro restrictivo, como la lógica del mercado de tarifas (por ejemplo, EIP-1559 y EIP-4844). Esto permite recuperar la dirección y usarla en múltiples máquinas de estado, con el mismo código de bytes, donde su cuenta en cada cadena es entonces responsable de definir los otros parámetros de la variable de contexto.

Críticas a la EIP-7702

Falta de compatibilidad con versiones anteriores

Si bien EIP-7702 es muy reciente, ya se han realizado muchos prototipos y pruebas para determinar sus dependencias y posibles desventajas, pero su modelo minimalista le garantiza mucha flexibilidad y, por lo tanto, utilidad en diferentes contextos. Sin embargo, rompe demasiadas invariantes y no es inmediatamente compatible con versiones anteriores. Algunas de las lógicas de EIP-7702 incluyen:

1. Modificación del nonce EOA a mitad de la transacción: EIP-7702 no limita ningún código de operación en un intento por garantizar la coherencia. Esto significa que un EOA puede implementar códigos de operación como CREATE , CREATE2 y SSTORE mientras ejecuta una transacción EIP-7702, lo que permite aumentar su nonce en un contexto diferente.
2. Permitir que las cuentas con un valor codeHash distinto de cero sean originadoras de transacciones: se implementó EIP-3607 para disminuir las posibles consecuencias de una "colisión de direcciones" entre las EOA y las CA. Una colisión de direcciones ocurre cuando el valor de 160 bits de la dirección de una EOA es totalmente equivalente al de la dirección de una CA.

La mayoría de los usuarios no conocen el contenido real de una cuenta (¡ni siquiera la diferencia entre una cuenta y una dirección!), por lo que permitir colisiones de direcciones significa que una EOA podría hacerse pasar por una cuenta de contrato y atraer fondos de los usuarios en un proceso interminable para finalmente robarlos todos. La EIP-3607 abordó este problema al estipular que las cuentas que contienen código no deberían poder gastar su saldo utilizando su propia lógica de autorización. Sin embargo, la EIP 7702 rompe esta invariante para permitir que las EOA sigan siendo autónomas incluso después de obtener cierta capacidad de programación.

Semejanza con EIP-3074

En esencia, transferir la dirección de una cuenta en lugar de su contenido de código es como el esquema de 3074 con invocadores. No ofrece garantías estrictas en cuanto a la coherencia del contenido de código entre cadenas, ya que una dirección podría adoptar un contenido de código diferente en diferentes cadenas. Esto significa que una dirección cuyo contenido de código contenga la misma lógica en una cadena podría ser depredadora o directamente maliciosa en otra cadena, y esto podría provocar la pérdida de fondos de los usuarios.

Conclusión

Las EOA en su forma actual están muy limitadas, ya que no permiten a los usuarios aprovechar las características de programabilidad que ofrece la EVM. Si bien existen varias formas de actualizar las cuentas, como describimos al principio de este informe, la solución elegida debe mantener los principios de autocustodia segura. Además, las actualizaciones de EOA pueden afectar significativamente tanto a la experiencia del usuario como a los desarrolladores de aplicaciones, por lo que se deben tener en cuenta las opiniones de todas las partes interesadas.

Permitir que las EOA ejecuten código de cualquier manera amplía enormemente la funcionalidad de las cuentas, pero esta nueva expresividad conlleva riesgos significativos y posibles inconvenientes. Resolver estos problemas es fundamental para ofrecer una actualización con beneficios indiscutibles en la experiencia del usuario para los usuarios de Ethereum.

La cultura de debate abierto de Ethereum la convierte en un excelente campo de pruebas para este tipo de innovaciones, ya que los expertos en la materia deconstruyen minuciosamente casi todas las implicaciones de cada diseño. Esta consideración exhaustiva debería ayudar a mitigar los riesgos de malversación por parte de los adversarios.

Actualmente, EIP-7702 es el modelo a seguir para los mecanismos que buscan brindar programabilidad EVM a los EOA, y se lo ha marcado como reemplazo de la ranura de EIP 3074 en la actualización de Pectra. Hereda el diseño abierto del mecanismo de 3074 y, al mismo tiempo, reduce en gran medida la superficie de ataque y los riesgos. También permite mucho más al evitar las restricciones de 3074 a ciertas clases de códigos de operación.

Si bien aún se deben realizar algunos ajustes en el diseño de la propuesta, ya ha obtenido mucha buena voluntad y apoyo de los desarrolladores, especialmente porque cuenta con el respaldo directo de Vitalik. Dentro de la comunidad, hay quienes afirman que este enfoque de abstracción de cuentas podría incluso ser mejor que las cuentas inteligentes. Este comentario enfatiza que este camino requiere menos cambios y no es tan complejo, y que las EOA ya están consagradas.

Sin embargo, debemos recordar el futuro hito de seguridad de la resistencia cuántica en todos los niveles de la red Ethereum. Esta seguridad cuántica es inviable con el núcleo del modelo de cuenta corriente debido a la utilización de esquemas de firma basados en ECDSA para la autorización EOA.

Por lo tanto, la programabilidad de EOA debe considerarse un paso en el camino hacia las cuentas inteligentes y no el destino. Potencia las EOA y permite una mejor experiencia para los usuarios y los desarrolladores, al tiempo que sigue siendo compatible con el objetivo final de abstracción de cuentas de las cuentas inteligentes.

En nuestro próximo informe, analizaremos en profundidad los esquemas de migración de EOA para ver qué tan bien encajan en la hoja de ruta de abstracción de cuentas. ¡Esté atento!