El inventario de EIP detrás de la abstracción de cuentas

Por Vasa, cofundador de OpenSea Pro; Traducción: Golden Finance Xiaozou

En este artículo, vamos a echar un vistazo rápido a los diferentes EIP que nos llevaron a las abstracciones de cuentas de hoy.

! [IBi1wWpT0680RWZaqv5DB56VCs7bGvDrkaHl3Wky.png] (https://img.jinse.cn/7122936_watermarknone.png “7122936”)

**1. ¿Por qué necesitamos la abstracción de cuentas (AA)? **

A la gente le gusta lanzar preguntas como: “¿Cómo traemos a los próximos mil millones de usuarios a la Web3?” "Hay muchos obstáculos que superar, pero el más importante de ellos es la experiencia del usuario.

El siguiente diagrama es una experiencia de usuario típica para un nuevo usuario. También ten en cuenta que si pierdes tu frase semilla, no hay forma de recuperar tus propios fondos. Este es un gran obstáculo para los nuevos usuarios.

! [vvFxw94g95EIvo2NuFwxQX9g5mTtJo2EvxwLJO2y.png] (https://img.jinse.cn/7122937_watermarknone.png “7122937”)

Estas son algunas de las cosas que podemos hacer para mejorar la experiencia del usuario. Podemos:

• Crea billeteras sin frases mnemotécnicas.

• Use una billetera que no requiera almacenar ETH y pagar tarifas de gas con ETH.

• Usa Social Recovery para recuperar tu billetera.

• Operaciones masivas en una sola transacción.

! [dE8KCPMN0cVxJwYU2lm5yt5B9g3GLhSxilFQWvfW.png] (https://img.jinse.cn/7122938_watermarknone.png “7122938”)

2、Tipo de resumen de cuenta

Hay dos tipos de cuentas: cuentas externas (EOA) y cuentas de contrato. EOA está controlada por la clave privada y la cuenta de contrato está controlada por el código de contrato.

! [64lX5U5G6sNJZBjPvNiC827QJil9Zi8BpTNMeQ8Y.png] (https://img.jinse.cn/7122939_watermarknone.png “7122939”)

Los EOA pueden iniciar transacciones a otras cuentas EOA o de contrato, que luego pueden ejecutar su código. Las cuentas de contrato también pueden enviar operaciones a otras cuentas de contrato, que pueden ejecutar su propio código.

3. Los inicios de Ethereum: ejecución y verificación de transacciones**

Cuando se envía una transacción a la red, pasa por dos pasos: verificación y ejecución. Si bien la ejecución de la lógica de transacción puede ser arbitraria, la parte de validación es fija.

La parte de verificación se realiza mediante un único algoritmo fijo que EOA debe utilizar, es decir, la verificación de la firma ECDSA. Pero, ¿por qué utilizamos un método fijo para verificar la validez de las transacciones? ¿Qué pasa si la verificación de firmas ECDSA ya no es confiable en el futuro debido a la computación cuántica?

Si dejamos abierta la parte de validación, entonces se puede crear una transacción con un algoritmo de validación muy complejo, entonces el minero/validador tendrá que gastar muchos recursos para comprobar si la transacción puede incluirse en el bloque.

Ahora bien, ten en cuenta que a los mineros sólo se les paga por ejecutar e incluir transacciones, no por verificarlas. Por lo tanto, si, después de gastar muchos recursos, los mineros descubren que no pueden agregar transacciones, entonces desperdician recursos y no se les paga nada por ello. Por lo tanto, esto se puede utilizar para llevar a cabo ataques DDoS en la red. Es por eso que Ethereum comenzó con un algoritmo de verificación fijo.

4. Los primeros días de Ethereum: el problema de la adopción de multifirma**

Una billetera multifirma es un contrato con muchos propietarios con umbrales. Si desea enviar una transacción, debe obtener las firmas de todos los propietarios antes de poder enviar la transacción.

Esto es compatible con funciones como la recuperación social, en la que puedes tener muchos amigos que te ayuden a recuperar tu monedero si pierdes tus claves privadas. Desde los primeros días de Ethereum, el valor que pueden proporcionar las billeteras multifirma ha sido evidente. Por lo tanto, el equipo de desarrollo de Ethereum en ese momento quería que los usuarios de Ethereum usaran billeteras multifirma. Sin embargo, esto no sucedió.

Dado que el equipo de desarrollo de Ethereum preveía que los usuarios usaran billeteras multifirma, no agregaron un registro automático para las transferencias de ETH porque esperaban que la billetera multifirma registrara cada transferencia de ETH. Los exchanges en ese momento tenían que analizar las transacciones de transferencia de ETH, no registrarlas.

Cuando alguien intenta usar una billetera multifirma con registros de transferencia de ETH, el intercambio es irreconocible porque el intercambio no analiza los registros. Por lo tanto, esta pequeña suposición en última instancia dificulta la adopción de billeteras multifirma.

EIP 86 y 1014: Primer paso para la abstracción de cuentas**

EIP-86 tiene como objetivo introducir el concepto de billetera de contratos inteligentes llamado “contratos de reenvío”. Estos contratos están diseñados para recibir solo transacciones de direcciones de “punto de entrada”, que deben cumplir con un formato específico.

Ahora, para crear una billetera de contrato inteligente, debe tener algo de ETH de antemano para pagar las tarifas de gas. Puede ir a CEX y obtener algo de ETH, pero debido a que su billetera de contrato inteligente aún no se ha creado, aún no puede enviar ETH a la billetera.

Si de alguna manera podemos saber exactamente la dirección del contrato antes de que se cree el contrato inteligente, podemos enviar ETH a esa dirección y luego crear una billetera de contrato inteligente usando ETH en la dirección.

Eso es lo que presenta EIP-1014. Introduce códigos de operación CREATE2 que le permiten determinar la dirección del contrato antes de crear un contrato inteligente. Este es el primer paso hacia la abstracción de cuentas.

El EIP-86 original requirió cambios significativos en el protocolo porque los cambios en el protocolo requerían la colaboración entre los equipos de desarrollo de nodos y requerían un escrutinio extenso, por lo que nunca se implementó. EIP-1014 se implementó en la bifurcación dura Constantinopla.

Desarrollo comunitario: Gnosis Safe, Argent Wallet, Red de gasolineras**

Al discutir el estudio de la EIP, la comunidad ya se ha propuesto desarrollar sus propias soluciones.

El más notable de ellos fue el lanzamiento de Gnosis Safe en 2018. Safe es una billetera de contrato inteligente que permite a los usuarios crear billeteras multifirma y también permite a los usuarios agrupar múltiples operaciones en una sola transacción. También permite a los usuarios pagar las tarifas de gas utilizando tokens ERC20.

Otra nota notable es el lanzamiento de la billetera Argent en 2019. Argent Smart Wallet permite a los usuarios crear billeteras multifirma y también permite a los usuarios pagar tarifas de gas utilizando tokens ERC20. También permite a los usuarios utilizar la recuperación social para recuperar sus billeteras.

La Red de Gasolineras (GSN), lanzada en 2019, es una red descentralizada que permite a los usuarios pagar las tarifas de gas utilizando tokens ERC20. GSN se puede usar con cualquier billetera de contrato inteligente.

EIP 2938 – Un gran salto adelante

A partir de 2018, el equipo de Ethereum centró su atención en la migración a PoS (proof-of-stake), lo que inadvertidamente llevó a un menor énfasis en la evaluación e implementación de EIP por parte de los equipos de investigación y los equipos de desarrollo de nodos.

Este cambio allanó el camino para la EIP-2938 en 2020, dos años después de que se implementara la EIP-1014.

La idea central detrás de la propuesta es la introducción de billeteras de contratos inteligentes, que están diseñadas para recibir específicamente tipos específicos de transacciones, que pueden programarse para determinar el límite de gas de las transacciones y desarrollar métodos de verificación arbitrarios.

La propuesta introduce dos nuevos códigos de operación para gestionar las transacciones y, como se ha destacado anteriormente, la inclusión de estas actualizaciones principales es un proceso complejo.

Además, hay preguntas abiertas sobre cómo se implementa la protección contra repeticiones y cómo los nodos pueden comprobar la validez de estos nuevos tipos de transacciones. Si bien la propuesta no recibió mucha atención, allanó el camino para la siguiente propuesta (EIP-3074).

EIP-3074 – Solución altamente versátil**

La propuesta introduce dos nuevos códigos de operación: AUTH y AUTHCALL. La diferencia con esta propuesta es que admite cuentas externas (EOA) para delegar el control a los contratos. Estos códigos de operación se especifican para los contratos de “invocador”, que tienen el potencial de mejorar significativamente la funcionalidad de cualquier EOA.

El contrato inicia una estructura de transacciones completamente arbitraria, lo que facilita la implementación de soluciones como la firma múltiple, las compras por lotes y de ayuda, la recuperación de claves y los depósitos CeFi más amigables. Debido a su naturaleza abierta, la propuesta surgió como una solución altamente versátil capaz de satisfacer una amplia gama de casos de uso.

Por otra parte, la posición neutral de la propuesta también plantea algunos retos en materia de seguridad. Un análisis más detallado sugiere un enfoque AUTHCALL más obstinado para mitigar los riesgos asociados. Esta discusión llevó a los investigadores a llegar a una solución más optimizada, lo que resultó en EIP-4337.

EIP-4337 – Abstracción de cuentas de Ethereum sin cambiar el protocolo de la capa de consenso**

! [HQ5SxXOpxJLs0tzXo1IgTdGxAe5XHPNAIJiDKUMM.png] (https://img.jinse.cn/7122940_watermarknone.png “7122940”)

EIP-4337 propone un mecanismo para llevar la abstracción de cuentas a Ethereum sin cambiar el protocolo de la capa de consenso. Bajo este EIP, los usuarios interactúan con la red Ethereum de manera diferente; En lugar de enviar transacciones, el usuario envía el objeto UserOperation a un grupo de memoria independiente. El remitente es el contrato de cuenta que inicia la acción del usuario. El empaquetador recopila estas operaciones y las empaqueta en una transacción que desencadena una llamada handleOps en el contrato de EntryPoint especificado para realizar la operación empaquetada. Paymaster es la entidad que patrocina la transacción, y sus detalles se incluyen en UserOperation para el procesamiento de tarifas.

El agregador verifica las firmas agregadas, lo que mejora la seguridad y la eficiencia. La lista blanca de paquetes o clientes admite puntos de entrada y contratos de agregador, controla las interacciones y garantiza la ejecución adecuada de las acciones del usuario en la red Ethereum, de acuerdo con los objetivos de la abstracción de la cuenta sin cambiar la capa de consenso.

Las billeteras de contratos inteligentes implementadas a través de este proceso administran de forma autónoma valores aleatorios y verificación de firmas, lo que brinda una amplia flexibilidad. Este diseño ayuda a crear billeteras de contratos inteligentes que pueden manejar transacciones multifirma y empaquetadas, recuperación social e incluso pagar tarifas utilizando tokens ERC20.

Alguna forma de abstracción de cuentas como la propuesta en EIP-4337 podría implementarse en el futuro a medio plazo de Ethereum, apareciendo inicialmente en nuevas soluciones L2 y eventualmente entrando en Ethereum L1, ampliando así el alcance de la interacción del usuario con Ethereum.

10、L2 - Nueva Frontera

Las actualizaciones del protocolo central son un obstáculo importante a la hora de introducir cualquier EIP relacionado con la abstracción de cuentas. Los desarrolladores principales han estado ocupados con la hoja de ruta de ETH 2.0, que ha sido una prioridad durante mucho tiempo.

Pero, ¿qué pasa con L2? A diferencia de Ethereum L1, que conlleva deuda técnica, las cadenas L2 recientes tienen una arquitectura que integra abstracciones de cuentas desde el principio.

Por ejemplo, StarkNet es un paquete acumulativo de ZK que crea una abstracción de cuenta única. Además, Argent, conocida por su billetera de contratos inteligentes L1, lanzó ArgentX en StarkNet, incorporando una implementación de abstracción de cuenta personalizada que fue fuertemente influenciada por EIP-4337. Estas iniciativas subrayan la importancia y aplicabilidad de la abstracción de cuentas en la cadena de bloques de Ethereum.