La abstracción de cuentas busca mejorar las experiencias de los usuarios y desarrolladores en todo el ecosistema de Ethereum. Además de hacer que las experiencias en cadena sean más accesibles y agradables para los usuarios, también capacita a los desarrolladores para poder hacer cosas más poderosas en Ethereum y servir a los usuarios de manera aún más significativa.

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

1. Mejora/programabilidad de EOA: Esto incluye cambios a nivel de protocolo que permiten a las EOA (Cuentas de Propiedad Externa) redefinir la parte lógica de ejecución de sus reglas de validez. Como es bien conocido dentro de la comunidad de desarrollo, las EOA son cuentas típicamente asociadas con los usuarios finales. Por lo tanto, las soluciones que se encuentran dentro de este enfoque capacitarán a las cuentas de los usuarios finales con un mayor control sobre qué tipo de acciones pueden autorizar, en comparación con cómo se puede gestionar actualmente.
2. Conversión/migración de EOA: Este enfoque incluye propuestas que buscan la conversión completa de EOA a CAs (cuentas de contrato). La idea integral de este enfoque es que las cuentas de contrato ya ofrecen la mayoría de los beneficios ofrecidos por las cuentas inteligentes, por lo que no debería haber necesidad de complicar las cosas aún más; todos deberían simplemente usar una cuenta de contrato como su cuenta principal (a través de billeteras de contratos inteligentes).

Este enfoque presenta mecanismos que permiten a una EOA transicionar a una CA, sin tener que mover sus activos, como EIP 7377yEIP 5003 (cuando se considera junto con EIP 3074).

1. Cuentas Inteligentes: Este grupo de propuestas incluye diseños que permiten tanto a los EOAs como a los CAs comportarse como ‘cuentas inteligentes’ al permitirles redefinir totalmente sus reglas de validez.

Anteriormente se han realizado varias propuestas para la creación de cuentas inteligentes y la consagración de la abstracción de cuentas a nivel de protocolo; EIP-86yEIP-2938son algunos de los más citados. Sin embargo, hubo mucha oposición debido a la complejidad percibida introducida por este diseño y la opinión mayoritaria de que Ethereum no está listo para tanta complejidad.

Siguiendo el resurgimiento de Vitalik del tema después de The Merge, ERC-4337se propuso como una versión optativa del estándar de cuentas inteligentes, similar a la infraestructura PBS (Proposer-Builder Separation) para MEV (Maximal Extractable Value). Así, los usuarios que busquen acceder a los beneficios de las cuentas inteligentes podrían simplemente usar el conducto ERC-4337 para redefinir la lógica de su cuenta y las reglas de validez de las transacciones en estructuras denominadas UserOperation (o UserOps en resumen).

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

Para abordar esta complejidad,RIP 7560fue redactado como una versión consagrada de la infraestructura ERC 4337 en Ethereum y sus L2s, para que herede los esquemas de resistencia de síbil de la red en lugar de tener que definir un nuevo conjunto de reglas (como lo hace ERC 4337 conERC 7562.

En este informe, nos centraremos en explorar la programabilidad de EOA, evaluando los diversos EIP que describen soluciones en esta línea y discutiremos sus méritos y desventajas. En la Parte 2 y 3 de esta serie, cubriremos las otras dos clases de enfoque para la abstracción de cuentas que se están explorando dentro de Ethereum.

Una introducción a las cuentas y transacciones de Ethereum

Para buscar lo que se puede abstraer, necesitamos una imagen (algo) completa del diseño de la cuenta actual. Esta sección servirá principalmente como una revisión de lo que son en realidad las cuentas en Ethereum, y cómo se validan y ejecutan sus transacciones.

Las cuentas de Ethereum son entidades con un saldo de 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 un indicador único de las tenencias y transacciones de la cuenta.

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

1. nonce: Un contador lineal utilizado para indicar el número de transacciones salientes iniciadas por una cuenta. También es crucial para prevenir ataques de reproducción.
2. balance: La cantidad de ether (ETH) en wei poseída por una cuenta.
3. codeHash: Un hash del código ejecutable por la EVM contenido en una cuenta. La EVM (Máquina Virtual Ethereum) es el entorno de ejecución personalizado de Ethereum responsable de manejar transiciones de estado complejas más allá de simples transacciones de “envío”. El contenido del código de una cuenta está programado de manera 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, utilizado para representar el contenido de almacenamiento de una cuenta como un hash de 256 bits de un nodo raíz del trie patricia de merkle. Simplemente, 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, para definir la extensión de sus funcionalidades. Así, los dos tipos de cuentas de Ethereum son:

1. Cuentas de propietario externo (EOAs) - que se inicializan como un par de claves criptográficas:

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

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

1. Cuentas de Contrato (CAs) - que solo pueden ser creadas por un EOA preexistente. Se inicializan debido a que un EOA despliega contenido de código ejecutable en el EVM. Este contenido de código (almacenado como el codeHash) está consagrado en el EVM, y es responsable de controlar la cuenta al definir su lógica e interacciones.

Sus transacciones son completamente basadas en pull y están basadas en la lógica de su código implementado.

Dado que estas cuentas solo pueden ser controladas por su contenido de 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/cambiar el contenido del código de una cuenta de contrato podría acceder a su saldo.

La dirección de una CA se deriva de la dirección de su creador y su nonce hasta el punto de implementación del contrato.

Transacciones

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 mayor que registra el historial de transacciones y describe cómo las transacciones alteran los campos de la cuenta basándose en 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 causan un cambio en el “estado” de la red. Son instrucciones firmadas criptográficamente de las cuentas, que resultan en una actualización del estado en toda la red cuando se ejecutan.

La falta de permisos conlleva el costo de incentivos perversos, para hacer frente a estos, es necesario definir pautas estrictas (o reglas de validez) para las interacciones en tales entornos.

En este contexto, las transacciones deben seguir ciertas reglas de validez para considerarse válidas y ejecutadas. La mayoría de estas reglas de validez se implementan a través de restricciones colocadas en la cuenta que envía la transacción, y varían según el tipo de cuenta que sea.

Cuentas y validez de transacciones

En Ethereum, las EOAs están optimizadas para la usabilidad ya que están orientadas al usuario final. Tienen la capacidad de enviar transacciones de manera específica y operar perfectamente de forma autónoma. También se pueden crear localmente, siendo el método más común el uso de proveedores de carteras 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 un EOA que tenga un saldo suficiente para pagar su almacenamiento de estado.

Una descripción más avanzada sería que las EOAs solo pueden tener un saldo, mientras que las CAs pueden tener tanto un saldo como 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 a las que deben adherirse las transacciones de una cuenta:

1. Lógica de autenticación: se utiliza para definir cómo una cuenta prueba su identidad ante la red mientras cambia su saldo y/o lógica.
2. Lógica de autorización - Utilizada para definir la política de acceso de una cuenta, es decir, quién puede acceder y realizar cambios en el saldo y/o lógica de la cuenta.
3. Lógica de nonce - que define el orden en el que se deben ejecutar 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: Utilizado para definir qué formas de transacciones puede enviar una cuenta, o cómo se debe ejecutar una transacción.

Estos parámetros están diseñados para ser rígidos para las EOAs así:

• La autenticación y autorización son proporcionadas por una clave privada basada en ECDSA, es decir, un usuario que desea enviar una transacción desde su EOA debe usar su clave privada para acceder a la cuenta y así demostrar que tienen el derecho de realizar cualquier cambio en su saldo.
• La lógica de 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 las EOAs solo pueden enviar los siguientes formularios de transacción:

1. Transferencias regulares entre dos EOAs.
2. Despliegue del contrato.
3. llamadas a contratos que apuntan a la lógica de una cuenta de contrato desplegado.

Más generalmente, la lógica de ejecución de las EOAs las 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 consecuentes/tiradas por naturaleza.
• La autorización para las CA puede tomar dos formas:

1. Capacidad para “llamar” el código de contenido de las CA (o ejecutar su contrato inteligente), que depende de la lógica del contrato inteligente de la cuenta y sus invariantes.
2. Capacidad para realizar cambios en el código de contenido de las CA, que en su mayoría depende 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 firma múltiple que estipula que se requieren M de N firmas válidas (donde M

• Su ordenación de transacciones se basa en gran medida en el nonce. El CA en sí mismo puede enviar tantas transacciones como sea posible a tantos llamadores diversos como sea posible, sin embargo, cada llamador está limitado según sus propias capacidades.
• El pago de gas es comúnmente manejado por el llamante de la lógica del CA.
• La lógica de ejecución de los CA es más diversa para permitir mejoras en la experiencia de usuario, como transacciones multicall 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 EOAs tienen plena autonomía pero una programabilidad limitada; pueden autorizar y enviar transacciones cuando lo deseen, pero estas transacciones deben seguir un formato rígido para considerarse válidas. Las CAs tienen plena programabilidad (limitada solo por el diseño del EVM) pero una autonomía limitada; sus transacciones no tienen que seguir ningún formato rígido, pero solo pueden ser enviadas debido a que su lógica es llamada primero.

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

El dilema de la cuenta de Ethereum

Ahora que tenemos un conocimiento algo sucinto de las funcionalidades de las diferentes cuentas, podemos identificar fácilmente sus puntos de venta, así como los problemas que presentan tanto para los usuarios como para los desarrolladores en Ethereum.

Como mencionamos anteriormente, las EOAs 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 hay complejidad en ellas y, por supuesto, no hay 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 una línea de tiempo optimista de 5 a 10 años para que se logren 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 EOAs elimina la capacidad de los usuarios de expresar sus transacciones de manera más concisa a través de funciones como la atomicidad de transacción y el agrupamiento, y la delegación de transacciones.
3. Auto-sostenibilidad: Todos han tenido su parte justa de momentos de “me quedé sin gas” en medio de una transacción. Esto se debe al requisito de que las EOAs resuelvan el gas para sus transacciones por sí mismas, lo cual no sería mucho pedir si el 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 todos quieren (o podrían) mantener siempre ETH (quiero decir, mira esa acción del precio), así 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”) o…aquí), o permitir que los pagos de gas sean liquidados por otra cuenta que no sea el origen de la transacción.

En el otro extremo del espectro de cuentas, las CAs apuntan a los desarrolladores y a una base de usuarios más técnica. Sirven como vehículos para contratos inteligentes (es decir, consideramos que los contratos inteligentes son su lógica contenida o contenido de código) y por lo tanto pueden implementar nuevos formatos de transacción habilitados por el EVM.

Sin embargo, todas estas características son cuentas de segunda clase glorificadas, ya que no tienen autonomía. Algunas de sus desventajas son las siguientes:

1. Completa falta de autonomía: los CA no pueden iniciar una transacción, solo pueden enviar transacciones en respuesta a ser invocados de una manera muy particular.
2. La susceptibilidad al error humano 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 pérdidas de miles de millones de dólares debido a explotaciones y piraterías de contratos inteligentes. Sin embargo, este es casi un tema completamente diferente que está más allá de nuestro alcance aquí.

Habiendo revisado las decisiones de diseño que llevaron a los problemas definidos en esta subsección, ahora podemos proceder a evaluar las soluciones propuestas.

Una línea de tiempo de la abstracción de cuentas

El concepto de abstracción de cuentas (a través de cuentas inteligentes al menos) siempre ha sido una parte integral del plan de Ethereum. Se 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ó de nuevo por el enfoque de Ethereum en The Merge, y ahora está resurgiendo como parte principal de la próxima gran actualización de la red - Pectra. Sin embargo, su complejidad sigue siendo considerada una desventaja significativa que impide su consagración, especialmente porque Ethereum ha pivotado hacia un plan centrado en Rollup.

Los requisitos ahora son dos veces más.

1. Los estándares de cuenta deben ser más expresivos, pero sin perder autonomía. Un nuevo estándar que sella la división entre los estándares EOA y CA.
2. El nuevo estándar debe cerrar la brecha entre EOAs y CAs, manteniéndose completamente compatible en Ethereum y sus ecosistemas L2.

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

La abstracción de cuentas tiene como objetivo combinar las mejores características de las EOAs y las CAs en un nuevo estándar de cuenta, las cuentas inteligentes, que permiten la separación total o parcial de las reglas de validez de cualquier cuenta en lógica de validación y ejecución; de modo que las cuentas puedan definir sus propias reglas de validez, según lo permitido por el EVM, al igual que las cuentas de contrato, manteniéndose totalmente autónomas al igual que las cuentas propiedad de manera externa.

A menudo hay confusión en torno a las diferencias entre las cuentas inteligentes y las carteras de contratos inteligentes, así que vamos a describir explícitamente cuáles son estas diferencias a continuación:

• Las cuentas inteligentes son cuentas de Ethereum que se conceptualizan para proporcionar una programabilidad y autonomía iguales. La idea es que tanto EOAs como CA pueden 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 consideren adecuado.
• Por otro lado, las billeteras de contratos inteligentes son simplemente proveedores de billeteras que sirven como interfaces para cuentas de contrato (sí, una billetera no es una cuenta).

La comercialización de las carteras de contratos inteligentes facilitó la adopción de las AC por un mercado más amplio, lo que permitió que los usuarios menos técnicos aprovecharan las características que ofrecen. Sin embargo, todavía enfrentan las desventajas asociadas con las AC.

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

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

Los valores de los primeros cuatro parámetros pueden ser referidos colectivamente como la lógica de validación de una cuenta, que son comprobaciones que ocurren 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, proporcionamos 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 para el dilema de cuentas de Ethereum: la programabilidad de EOA.

EOAs programables

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

Una solución provisional que se está explorando mientras tanto que tanto las DApps como los proveedores de carteras se acostumbran al estándar de cuenta inteligente, es proporcionar mejoras temporales a las EOAs 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 proporcionan rutas accionables a la programabilidad de la EOA; desde el menos conocidoEIP 5806, para los ambiciosos EIP 3074y luego finalmente al victoriosoEIP 7702.

Programabilidad a través de EIP-5806

Esta propuesta busca llevar más funcionalidad al estándar EOA al permitirle realizar llamadas delegadas a la lógica de la cuenta del contrato (su contrato inteligente). Esto hace que el contrato inteligente se ejecute efectivamente en el contexto del EOA del llamante, es decir, el EOA sigue controlando su lógica de validación, mientras que su lógica de ejecución es manejada por la lógica correspondiente de la CA.

Antes de seguir adelante, hagamos un viaje por la memoria evolutiva de Ethereum hasta…EIP-7.

El EIP-7 propuso la creación del opcode 0xf4/DELEgateCALL, que se utiliza para enviar llamadas de mensaje a una cuenta primaria con la lógica de una cuenta secundaria, manteniendo los valores de los campos [sender] y [value] de la cuenta primaria.

En otras palabras, la cuenta principal “hereda” (o toma prestada si lo prefiere) la lógica de la cuenta secundaria durante algún tiempo especificado en la llamada al mensaje, de modo que la lógica de esta última se ejecuta en el contexto de la primera.

Este opcode permitió a los desarrolladores de dApp dividir la lógica de su aplicación en múltiples contratos inteligentes manteniendo la interdependencia, de modo que pudieran esquivar fácilmente las barreras de tamaño de código y barreras de gas.

EIP-5806 resumido

Bien, entonces ¿qué llamadas de delegado permiten que los AC sean interdependientes? Bueno, EIP-5806 utiliza EIP-7 como inspiración para proponer la expansión de la funcionalidad de llamada de delegado también a las EOA; es decir, permitamos que las EOA también sean interdependientes con los AC, porque ¿por qué no?

Especificaciones

EIP 5806 introduce una nueva compatible con EIP-2718tipo de transacción que se empaqueta 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 de manera que el campo [to], que representa la dirección del destinatario, solo puede aceptar direcciones como entradas de 20 bytes, lo que impide que el remitente utilice el opcode CREATE.

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

• chainID: El identificador conforme a EIP-115 de la cadena actual rellenado a 32 bytes. Este valor proporciona protección contra ataques de repetición, de modo que las transacciones en la cadena original no se replican fácilmente en cadenas EVM alternativas con una historia similar y menos seguridad económica.
• nonce: Un identificador único para cada transacción que también proporciona protección contra ataques de reproducció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: El máximo de gas que una única 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 permite una gran compatibilidad hacia atrás, las EOAs no son equivalentes a las CAs. Por lo tanto, se deben definir ciertas restricciones en la forma en que una EOA utiliza las llamadas de delegado para evitar la ruptura de invariantes.

Estas restricciones están dirigidas a los siguientes opcodes:

• SSTORE/0x55: Este opcode permite a una cuenta guardar un valor en el almacenamiento. En las transacciones EIP-5806 está restringido para evitar que los EOAs establezcan/accedan al almacenamiento utilizando llamadas delegadas, lo que previene 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 llamador crear una nueva cuenta de forma extensiva. El acceso a estos está restringido para evitar la alteración del nonce de un EOA en un marco de ejecución diferente (creación/destrucción de contratos en este caso) mientras realiza una transacción EIP-5806, con el fin de evitar la invalidación de la expectativa de que las transacciones lleven nonces consecutivos.

Aplicabilidad/Potenciales Casos de Uso

La aplicabilidad principal de EIP 5806 es la abstracción de ejecución para EOAs. Permitir que los EOAs interactúen de manera confiable con contratos inteligentes más allá de simples llamadas a su lógica les otorga funciones como:

• Ejecución condicional de transacciones
• Batching de transacciones
• Transacciones de llamada múltiple (por ejemplo, aprobar y llamar)

Críticas

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

Una de las principales preocupaciones expresadas en sus primeros días fue el riesgo potencial de permitir que las Cuentas Externas Autónomas (EOAs) accedan al almacenamiento y lo modifiquen, al igual que las Cuentas Contrato Actuales (CAs) lo hacen actualmente. Esto rompe muchos invariantes consagrados en la red sobre cómo deben realizarse las transacciones con las EOAs, y por eso 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 debidas a la aceptación de 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 a través de EIP-3074

EIP-3074 propone permitir que las EOAs 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 firmando su política de acceso a un contrato invoker, que luego se convierte en responsable de definir la política de acceso de la EOA.

Esta EIP propone la adición de dos nuevas opcodes al EVM:

• [AUTH] que establece una cuenta [autorizada] variable de contexto para que actúe en nombre de una segunda cuenta [de autoridad], en función de la firma ECDSA de esta última.
• [AUTHCALL] que envía/implementa llamadas para la cuenta [authority] desde/como la cuenta [authorized].

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 eso.

Especificaciones

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 sola transacción y debe ser redefinido 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 (un EOA) que delega acceso/control a una segunda cuenta, que suele ser una cuenta de contrato.
• [autorizado]: La cuenta a la que se deben pasar las instrucciones de [AUTHCALL] para su ejecución. En otras palabras, es la cuenta en la que se ejecuta la lógica de un [AUTHCALL], en nombre de la [autoridad], utilizando restricciones definidas por un [invocador].
• [invoker]: Un contrato subsidiario destinado a gestionar las interacciones entre la cuenta [autorizada] y la lógica del [AUTHCALL], especialmente en casos donde la lógica principal del código del contrato es el patrocinio de gas.

Los contratos Invoker reciben mensajes [AUTH] con un valor [COMMIT] de [autoridad]; este valor define las restricciones que la cuenta desea imponer en la ejecución de las instrucciones [AUTHCALL] de [autorizado].

Por lo tanto, los invocadores son responsables de garantizar que el [contract_code] definido en una cuenta [autorizada] no sea malicioso y tenga la capacidad de satisfacer los invarianes establecidos por la cuenta de firma principal en un valor de [COMMIT].

El código de operación [AUTH] tiene tres entradas de elementos de pila; o más simplemente, se define por tres entradas que calculan una sola salida. Estos insumos son:

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

Los dos últimos inputs se utilizan para describir un rango de memoria modificable de 0 a 97, donde:

1. [memoria(desplazamiento: desplazamiento+1)] - [yParity]
2. [memoria(offset+1 : offset+33] – [r]
3. [memoria(offset+33 : offset+65)] - [s]
4. [memoria(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 || dirección del invocador || CONFIRMACIÓN)]

dónde:

• [MAGIC] es una firma ECDSA resultante de la combinación de las variables:
  • [chainID] que es el identificador EIP 115 compatible con la cadena actual utilizado para proporcionar protección contra ataques de repetición en cadenas EVM alternativas con una historia similar y menos seguridad económica.
  • [nonce] que es el nonce actual de la dirección del firmante de la transacción, rellenado a 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 utilizado para especificar condiciones adicionales de validez de la transacción en la lógica de preprocesamiento del invocador.

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

El costo de gas para este opcode se calcula como la suma de:

1. Una tarifa fija por la precompilación de [ecrecover] y una adicional por una función hash keccak256 y lógica adicional, valorada en 3100 unidades
2. Una tarifa de expansión de memoria que se calcula de manera similar a la 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. Se incurre en un costo fijo de 100 unidades para una [autoridad] caliente y 2600 unidades para una inactiva para evitar ataques debido a precios incorrectos de los códigos de operación de acceso al estado.

[AUTH] se implementa para no modificar la memoria y toma el valor de [authority] como argumento, por lo que es trivial verificar su valor a partir de la firma proporcionada.

El opcode [AUTHCALL] tiene siete elementos de pila de entrada que se utilizan para calcular un solo elemento de pila de salida.

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

Por lo tanto, [AUTHCALL] es utilizado por la [autoridad] para desencadenar un comportamiento específico del contexto en [autorizado] con comprobaciones lógicas que proceden de la siguiente manera:

1. Compruebe el valor de [autorizado]. Si no se establece, la ejecución se considera inválida y se sale inmediatamente de la trama. Esto ayuda a evitar cargos injustos debido a fallas sin precedentes.
2. Verifica el costo de 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 balance de [autoridad].
5. La ejecución se produce después de la deducción de [valor] del saldo de la cuenta de [autoridad]. Si [value] es mayor que su saldo, la ejecución se invalida.

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

• Un costo fijo para llamar [warm_storage_read]
• Un costo de expansión de memoria [memory_expansion_fee]; que se calcula de manera similar al costo de gas para el opcode [CALL]
• Un costo dinámico [dynamic_gas]
• El costo de ejecución de la subllamada [subcall_gas]

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

• [RETURNDATASIZE] - que empuja 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 unirlo todo con mucho menos de la jerga técnica; Las transacciones de Ethereum suelen especificar dos valores:

1. tx.origin - que proporciona autorización para la transacción.
2. msg.sender: en el que ocurre la transacción en realidad.

En EOAs, como se mencionó anteriormente, la autorización está estrechamente vinculada con la ejecución, es decir, (tx.origin == msg.sender). Esta invariante simple da lugar a la mayoría de los problemas que explicamos en la subsección ‘Cuentas y validez de transacciones’ de este informe.

Los mensajes de [AUTH] de [authority] le permiten compensar la función tx.origin a [authorized], mientras que sigue siendo el msg.sender. También le permite definir restricciones a este privilegio utilizando un valor [COMMIT].

[AUTHCALL] luego permite que [autorizado] acceda a la lógica de un contrato, utilizando un [invocador] como intermediario para asegurar que el contrato al que desea acceder sea inofensivo. Es decir, para cada [AUTHCALL], [autorizado] debe especificar un [invocador] en particular para su [COMMIT].

Potenciales aplicaciones/casos de uso

EIP 3074 es principalmente responsable de permitir que las EOAs deleguen su lógica de autorización a una cuenta diferente, sin embargo su diseño abierto permite mucho más en diferentes contextos.

Toda la lógica de validación de una EOA puede ser abstracta aplicando diversas restricciones/innovaciones al invocador según sea necesario, algunos de los diseños posibles basados en su lógica objetivo incluyen:

• Lógica de nonce: EIP-3074 permite que el nonce de las EOAs 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 las EOAs, para que puedan enviar múltiples [AUTHCALL] sin superposición según deseen.
• Lógica de pago de gas: Según lo especificadoen el EIP, los invocadores pueden ser diseñados para permitir el patrocinio de gas. Como tal, 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 un relé basado en servicio (servicios de patrocinio de gas).

Además, la lógica de ejecución se abstrae de manera intuitiva; después de todo, el invocador (que es una CA) ahora es responsable de ejecutar las solicitudes de transacción en nombre del EOA.

Críticas

• Centralización de Invoker

Cotizandouno de sus autores: “No esperaría que las carteras expongan funcionalidades para firmar sobre invocadores arbitrarios …”. Quizás el mayor problema planteado por la iniciativa 3074 es que la innovación encima de ella tenderá muy fácilmente a flujos de acuerdos con permisos y propietarios; al igual que las iteraciones actuales de los mercados MEV y PBS de Ethereum.

Por defecto, los contratos invoker deben ser ampliamente auditados para evitar ataques aún peores que los que son actualmente posibles. Esto inevitablemente tenderá a un ecosistema donde solo se adoptarán un puñado de contratos invoker desarrollados por figuras influyentes como los predeterminados para los desarrolladores de billeteras. Por lo tanto, se reduce a un compromiso entre tomar el difícil camino descentralizado de auditar y respaldar constantemente los contratos invoker con el riesgo de seguridad de los usuarios; o simplemente adoptar contratos invoker de fuentes establecidas y reputadas con mejores garantías de seguridad para el usuario y menos supervisión sobre la seguridad del contrato.

Otro aspecto de este punto es la función de coste 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 ámbito de la comercialización, que ya tienen cierta reputación establecida, incluso si su producto es mejor.

• Problemas de compatibilidad hacia adelante

EIP-3074 afianza 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 hay argumentos de que la resistencia cuántica no es actualmente un problema definitivo, y que hay mucho peor en juego en un futuro donde ECDSA sea corruptible; el objetivo algo no declarado de Ethereum es siempre estar por delante de tales problemas. Potencialmente sacrificar la resistencia cuántica y a la censura por mejoras marginales en la experiencia de usuario puede que no sea la mejor de las elecciones en un futuro cercano.

Otro punto sobre el argumento de la compatibilidad hacia adelante es que mientras se evaluaban los beneficios de 3074, ERC-4337 (que no requiere cambios en el protocolo) ahora tiene un gran mercado, por lo que también debes ser compatible con él para evitar la compartimentalización de los ecosistemas.

Incluso con la hoja de ruta de abstracción de cuentas nativas, los opcodes [AUTH] y [AUTHCALL] eventualmente se volverían obsoletos en el EVM, introduciendo una gran cantidad de deuda técnica en Ethereum para ofrecer una cantidad marginal de mejora en la experiencia del usuario.

• Irrevocabilidad del esquema ECDSA

Después de enviar un mensaje [AUTH] y delegar el control, se espera que el 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.

Así, el esquema ECDSA sigue siendo estrictamente superior a cualquier otro esquema de autorización que los contratos asociados puedan habilitar, lo que significa que la pérdida de claves privadas resultaría en una pérdida total de los activos de la cuenta.

Programabilidad a través de EIP-7702

Esta propuesta inicialmente se planteó como una variación algo minimalista de EIP 3074, y era incluso significadoser una actualización de ella. Nació para abordar las supuestas ineficiencias de EIP 3074, especialmente las preocupaciones sobre su incompatibilidad con el ecosistema ya próspero 4337 y la propuesta nativa de abstracción de cuentas - RIP 7560.

Su enfoque es la adición de un nuevo tipo de transacción compatible con EIP 2718, [SET_CODE_TX_TYPE], que permite a un EOA comportarse como una cuenta inteligente para transacciones especificadas.

Este diseño permite las mismas características que EIP 5806 y algunas más, al tiempo que es compatible con la hoja de ruta de abstracción de cuentas nativas y las iniciativas existentes.

Especificaciones

EIP-7702 permite a un EOA ‘importar’ el contenido del código de un contrato a través de una transacción compatible con [SET_CODE_TX_TYPE] 2718 del siguiente 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 es completamente similar a la de EIP 5806, excepto que introduce una “lista de autorización”. Esta lista es una secuencia ordenada de valores de formato:

[[chain_id, dirección, nonce, y_parity, r, s], …]

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

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

• [authority]: que es la cuenta de firma EOA/primaria
• [address]: que es la dirección de una cuenta que contiene un código delegable.

Cuando [authority] firma un SET_CODE_TX_TYPE especificando [address], se crea un designador de delegación. Este es un “programa de punteros” que hace que todas las solicitudes de recuperación de código debidas a las acciones del [authority] en cualquier momento se canalicen al código observable de [address].

Para cada tupla [chain_id, dirección, 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] desde el hash proporcionado usando: autoridad = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. Prevención de ataques de reproducción intercadena yotros vectores de ataquemediante la verificación de la identificación de la cadena.
3. Comprobando si [authority] ya tiene contenido de código.
4. Comprobación de nonce para asegurar que el nonce de [authority] 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 que el valor de esta tarifa, la operación se abandona.
6. Ocurre la designación de delegación, donde el código de [autoridad] se establece como 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 (simplificado) es un conjunto de direcciones que se crean de tal manera que la reversión de un alcance de una transacción desde ellas hace que la dirección vuelva a su estado anterior, antes de que se ingresara el alcance revertido. Esto se define en EIP-2929para habilitar el almacenamiento en caché de valores reutilizables y evitar cargos innecesarios.

¡Uf! Para atar todo esto de vuelta; este EIP permite a las EOAs 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 las EOAs tener realmente contenido de código todo el tiempo que deseen (en lugar de EIP 5806 que simplemente permite a las EOAs enviar llamadas delegadas).

Potencial aplicabilidad/casos de uso

• Abstracción de Ejecución

Si bien se podría argumentar que ya no es una abstracción, ya que el EOA recibe activamente la lógica que desea ejecutar, aún no es el “propietario principal” de dicha lógica. Además, no contiene directamente la lógica, 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 se rompe la invariante require (msg.sender == tx.origin) para permitir el patrocinio propio, el EIP todavía permite la integración de relevo de transacciones patrocinadas. Sin embargo, la advertencia es que dichos relevos necesitan un sistema basado en reputación o participación para prevenir ataques de sabotaje.

• Políticas de Acceso Condicional

Las EOAs solo pueden apuntar a una porción específica del código de la cuenta, de modo que solo la lógica de esa porción es ejecutable en su contexto.

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

• Implementación de Contrato Inteligente de Cadena Cruzada

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 el 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 que la dirección se recupere y se utilice en varias máquinas de estado, con el mismo código de bytes, donde su cuenta en cada cadena es responsable de definir los otros parámetros de variables de contexto.

Críticas

• Falta de compatibilidad con versiones anteriores

Si bien EIP-7702 es todavía muy reciente, ya ha habido mucho prototipado y pruebas para sus dependencias y posibles desventajas, pero su modelo minimalista garantiza mucha flexibilidad, y por lo tanto utilidad, en diferentes contextos. Sin embargo, rompe demasiadas invariancias y no es inmediatamente compatible con versiones anteriores.

Parte de su lógica incluye:

1. Alteración de nonce de EOA en medio de la transacción: EIP-7702 no limita ningún opcode en un intento de garantizar la consistencia. Esto significa que un EOA puede implementar opcodes como CREATE, CREATE2 y SSTORE mientras ejecuta una transacción EIP-7702, lo que le permite aumentar su nonce en un contexto diferente.
2. Permitir que las cuentas con un valor de codeHash no nulo sean los originadores de transacciones: EIP-3607 se implementó para disminuir las posibles consecuencias de una ‘colisión de direcciones’ entre EOAs y CAs. Una colisión de direcciones ocurre cuando el valor de 160 bits de la dirección de un EOA es completamente equivalente al de la dirección de un CA.

La mayoría de los usuarios no están al tanto del contenido real de una cuenta (¡ni siquiera de la diferencia entre una cuenta y una dirección!), lo que significa que permitir colisiones de direcciones significa que un EOA podría hacerse pasar por una CA y atraer fondos de usuario en un largo proceso para finalmente robar todo. EIP-3607 aborda esto 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, EIP 7702 rompe esta invariante para permitir que los EOAs sigan siendo autónomos incluso después de adquirir cierta programabilidad.

• Semejanza con EIP-3074

Firmar la dirección de una cuenta en lugar de su contenido de código es básicamente como el esquema 3074 con invocadores. No proporciona garantías estrictas sobre la consistencia del contenido del 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 contiene la misma lógica en una cadena podría ser depredadora o completamente maliciosa en otra cadena, y esto podría llevar a la pérdida de fondos de usuario.

Conclusión

Las EOAs en su forma actual están muy limitadas, ya que no permiten a los usuarios aprovechar las características de programabilidad ofrecidas por el EVM. Si bien hay varios caminos para mejorar las cuentas, como mencionamos al principio de este informe, la solución elegida debe mantener los principios de custodia propia segura y protegida. Además, las actualizaciones de las EOA pueden tener un impacto significativo tanto en la experiencia del usuario como en los desarrolladores de aplicaciones, por lo que se deben considerar todas las opiniones de las partes interesadas.

Permitir que las EOAs 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 compromisos es fundamental para ofrecer una actualización con beneficios de UX indiscutibles para los usuarios de Ethereum.

La cultura de discusión abierta de Ethereum lo convierte en un gran campo de pruebas para tales innovaciones, ya que casi todas las implicaciones de cada diseño son minuciosamente analizadas por expertos en la materia. Esta consideración integral debería ayudar a mitigar los riesgos de mala praxis por parte de adversarios.

EIP-7702 es actualmente el niño mimado de los mecanismos que buscan llevar la programabilidad de EVM a las EOAs, habiendo sido marcado como un reemplazo para el espacio en blanco de EIP 3074 en la actualización Pectra. Hereda el diseño abierto del mecanismo 3074 mientras reduce en gran medida la superficie de ataque/riesgos. También permite mucho más al evitar las restricciones de 3074 a ciertas clases de opcodes.

Si bien todavía se están realizando algunos refinamientos en el diseño de la propuesta, ya ha obtenido mucho apoyo y respaldo de los desarrolladores, especialmente porque Vitalik lo respalda directamente.

Dentro de la comunidad hay afirmaciones de que este enfoque de abstracción de cuentas podría ser incluso mejor que las cuentas inteligentes. Este comentario enfatiza que este enfoque requiere menos cambios y no es tan complejo, y que las EOA ya están consagradas. Sin embargo, debemos recordar el hito de seguridad futura de resistencia cuántica en cada nivel de la red Ethereum. Esta seguridad cuántica es inviable con el modelo de cuenta actual debido a la utilización de esquemas de firma basados en ECDSA para la autorización de EOA.

Así, la programabilidad de las EOA debe considerarse como un paso en el camino hacia las cuentas inteligentes y no como el destino. Potencia las EOA y permite una mejor experiencia para el usuario y el desarrollador, al tiempo que se mantiene compatible con el objetivo último de abstracción de cuentas de las cuentas inteligentes.

En nuestro próximo informe, nos sumergiremos en los esquemas de migración de EOA para ver qué tan bien se ajustan en el camino de la abstracción de cuentas, ¡manténgase atento!

Descargo de responsabilidad：

1. Este artículo es una reproducción de [2077.xyz], Todos los derechos de autor pertenecen al autor original [zhev]. Si hay objeciones a esta reimpresión, por favor contacte al Aprender acerca de Gateequipo y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad por responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.